- Check the deep link activity instance before redirecting to the
internal activity for the managed profile invocation, so the caller
can't bypass the permission check.
- Get the referrer as the caller so that onNewIntent can recognize the
new caller and check if it has a permission to open the target page.
Test: robotest & manual
Bug: 268193384
Change-Id: Ie69742983fb74ee2316b7aad16461db95ed927c2
Merged-In: Ie69742983fb74ee2316b7aad16461db95ed927c2
Examine whether the packages is allowed to display app locales list when creating the AppLocalePickerActivity, and examine whether the target user is the same as the calling user.
Bug: 257954050
Test: Follows the test step listed in b/257954050#comment14
Change-Id: I2e25a308bcba6ea0edee89c7a78465f766bdbeac
Merged-In: I2e25a308bcba6ea0edee89c7a78465f766bdbeac
Test: I solemnly swear I tested this conflict resolution.
Bug: b/264918004
Change-Id: I6125be25233ffb33e10cc98444017b3d3a99f1f9
Merged-In: I2cfda684059520f6ddd1e72c55f1ab1ec9c99e8b
Settings app must not start an deep link Activity if
1. The deep link Activity is not exported.
or
2. Calling package does not have the permission to
start the deep link Activity.
Bug: 250589026
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SettingsHomepageActivityTest
Change-Id: I9a3bddfa5d9d1d2e924dd6f3e5e07dca6c11664f
Merged-In: I9a3bddfa5d9d1d2e924dd6f3e5e07dca6c11664f
Bug: 244423101
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothSwitchPreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothDashboardFragmentTest
Test: manual test by test apk
Change-Id: I13562d227e06627fac33239a9d21fd405a18d012
To guard against the arbitrary Intent injection through Selector.
Bug: 246300272
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SettingsActivityTest
Change-Id: I76fbf3ff7a6611ebb3d07f73845a64efe1771769
Merged-In: I8b3b936de490f09f4be960fdafc6e66a1d858ee2
Prevent ChooseLockPassword and ChooseLockPatten being projected to
remote views, add FLAG_SECURE for these screens.
Bug: 179725730
Test: Check these 2 screens not projected to chromecast
Test: robo test for SetupChooseLockPatternTest ChooseLockPatternTest
SetupChooseLockPasswordTest ChooseLockPasswordTest
Change-Id: I7449a24427c966c1aa4280a7b7e7e70b60997cca
Merged-In: I7449a24427c966c1aa4280a7b7e7e70b60997cca
(cherry picked from commit 98239c0da6)
Prevent ChooseLockPassword and ChooseLockPatten being projected to
remote views, add FLAG_SECURE for these screens.
Bug: 179725730
Test: Check these 2 screens not projected to chromecast
Test: robo test for SetupChooseLockPatternTest ChooseLockPatternTest
SetupChooseLockPasswordTest ChooseLockPasswordTest
Change-Id: I7449a24427c966c1aa4280a7b7e7e70b60997cca
Merged-In: I7449a24427c966c1aa4280a7b7e7e70b60997cca
(cherry picked from commit 98239c0da6)
When not allowing APN to add, user may not be able to recover easily
when delete it.
Therefore, avoid from APN to be deleted when adding is not allowed.
Bug: 243664439
Bug: 200875858
Test: local, robolectric
Change-Id: I5cf984000244b4ad901c6a4977a1368279323e0a
Prior to this cl, we use #getPackagesForUid()
to get a list of calling package names and
pick up 1st package name in the list as target
calling package. And then go to check the
Wi-Fi permission.
This implementation is ok for most apps without
sharing system uid. However, this may not work
if the package is set with sharing system ui.
In this case, we get a list of packages
and we don't know which one is caller. So, if we
decide to choose the 1st package as our
calling package, then it could fail to pass
permission check since that package could be not
a correct calling package.
In this cl, we skip permission check for those
packages running with system uid. So, it can resolve
Wi-Fi Panel problem since Wi-Fi panel runs
on settings process(with system uid).
Test: 1. adb shell am start -a android.settings.panel.action.WIFI
2. Verify on assistant app and system ui launcher and search app.
Bug: 240531998
Change-Id: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Prior to this cl, we use #getPackagesForUid()
to get a list of calling package names and
pick up 1st package name in the list as target
calling package. And then go to check the
Wi-Fi permission.
This implementation is ok for most apps without
sharing system uid. However, this may not work
if the package is set with sharing system ui.
In this case, we get a list of packages
and we don't know which one is caller. So, if we
decide to choose the 1st package as our
calling package, then it could fail to pass
permission check since that package could be not
a correct calling package.
In this cl, we skip permission check for those
packages running with system uid. So, it can resolve
Wi-Fi Panel problem since Wi-Fi panel runs
on settings process(with system uid).
Test: 1. adb shell am start -a android.settings.panel.action.WIFI
2. Verify on assistant app and system ui launcher and search app.
Bug: 240531998
Change-Id: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Define a setting string for putting data for suez/settingstats.
Bug: 234035619
Test: Manually check ScreenResolution ap in Settings can work normally.
Merged-In: Ib4622490b0f63139b47f242ebcae916edf291cea
Change-Id: Ib4622490b0f63139b47f242ebcae916edf291cea
Test: Verified that Unicorn SUW flows can now
enroll a face.
Test: Verified normal SUW flow works as expected.
Fixes: 237088482
Fixes: 234663447
Change-Id: I9c4100f61b5e7d40fc9ed67c6918ec7bf31fc30a
The BluetoothDeviceUdater added the checking whether the item is in the
list. It caused this testcase failed.
Add more mocks for this testcase.
Bug: 237223797
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothDevicesSliceTest
Change-Id: Idb746e42480f99846efb5d1e4d4a411a5a9ca296
The API of Settings app get changed in order to support large screen.
This is a fix to adopt the change related to this work.
A short brief:
1. Accept ACTION_MAIN for launching MobileNetworkActivity.
2. Support deep-link intent while MobileNetworkActivity in foreground.
3. Avoid from binding MobileNetworkActivity as a single instance.
Bug: 230047450
Bug: 234406562
Bug: 229371407
Test: local & unittest
Change-Id: Ifcb9d4c564839199d998bd503f390f021c6bf3ad
At the media device, it only shows the active LE device which is
connected.
Bug: 232892046
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AvailableMediaBluetoothDeviceUpdaterTest
make RunSettingsRoboTests ROBOTEST_FILTER=ConnectedBluetoothDeviceUpdaterTest
make RunSettingsRoboTests ROBOTEST_FILTER=SavedBluetoothDeviceUpdaterTest
Change-Id: Iac661206def4d43bc40ab9bb1938f084926899c2
Add a switcher to enable/disable LE audio feature. The switcher could be
enabled by setprop ro.bluetooth.leaudio_offload.supported=true
screenshot: https://screenshot.googleplex.com/6aGP664S9PX5EMS
Bug: 233018305
Bug: 233005340
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothLeAudioPreferenceControllerTest
Test: switch LE audio feature, and check LE audio functionality status
Change-Id: I8adcf27edd1438df445d32fca93f35ff5020a3b3
Merged-In: I8adcf27edd1438df445d32fca93f35ff5020a3b3
(cherry picked from commit 0d11fd07e7)
When the user enable the removable esim, the settings select wrong
slot(esim slot). The slot shold be the removable + esim slot and the
UiccCardInfo's cardId is the same as the removable esim's cardId.
Bug: 233170453
Bug: 233338345
Test: atest UiccSlotUtilTest
Change-Id: Ibd324b781c84318c994e3742bb82e1d1393b94e4
Use correct user id context to query the type,
so we won't get empty result unexpectedly.
If we get the null result, then we won't set sound sucessfully.
Bug: 233580016
Bug: 221041256
Test: Manual test and set work profile sound works.
Change-Id: I7f8fb737a7c6f77a380f3f075a5c89a1970e39ad
Merged-In: I7f8fb737a7c6f77a380f3f075a5c89a1970e39ad
Currently, when schedule sets to "Turns on at bedtime", the footer will
show a slid up animation when entering the page, this is because the
"Start time" & "End time" preferences are hidden in onResume().
This is because these 2 preferences always return AVAILABLE in
getAvailabilityStatus(), and manually update visibility in
refreshSummary(), which is called each time updateState() is called.
Usually the controller not set the visibility explicitly, but return
CONDITIONALLY_UNAVAILABLE in getAvailabilityStatus() when they want to
hide the preference.
Because getAvailabilityStatus() is called in onCreate(), by using this,
we can fix the flicker.
Fix: 234399017
Test: visual & robo test
Change-Id: I4cb7dd95d2985bd1ca4c8cb30aaebdc21a5415f8
The usage of this dialog is removed in
Change Ie2cf147de53385ae0c626c8472306f1b85317686
But this dialog is created (but not show) in DarkUIPreferenceController
each time dark mode toggle is turned on by user.
So clean this up.
Fix: 234419979
Test: make Settings
Change-Id: Icdc9d7a4fb77dc8b2a3f1a9d8e3f40fc0af4917d
Uri.toSafeString strips out paths and shouldn't be used
for situations other than logging.
Bug: 232694281
Test: PtsPowerTestCases
Change-Id: Iec835b738c3e928e922bd6a14573106f2ce4f526
Use correct user id context to query the type,
so we won't get empty result unexpectedly.
If we get the null result, then we won't set sound sucessfully.
Fix: 233580016
Test: Manual test and set work profile sound works.
Change-Id: I7f8fb737a7c6f77a380f3f075a5c89a1970e39ad
