We already make sure to use a copy of the Intent, but now we do so
earlier. See bug.
Bug: 353680402
Flag: EXEMPT bugfix
Test: manual
Test: atest com.android.settings.users.UserSettingsTest
com.android.settings.users.UserDetailsSettingsTest
Change-Id: I860e9e606de6b8d3c99fa52a63b72ba7a99ce179
Merged-In: I860e9e606de6b8d3c99fa52a63b72ba7a99ce179
(cherry picked from commit b7240e2f0c50455a1c8f3ae1fc4f27d55b86e89b)
Activity.getCallingPackage() does not always return the package
name of the actual calling app. getLaunchedFromPackage() should
be used instead.
Bug: 389681530
Test: manual
Flag: EXEMPT bugfix
Merged-In: Ibdbc45e53f4aa46fae79fa234705b3735bfda4cd
Change-Id: Ibdbc45e53f4aa46fae79fa234705b3735bfda4cd
(cherry picked from commit 70bd3efe0674bccb0d454845d86fb2402779a7bf)
- if the user is locked
- and the user has chosen to hide sensistive content when locked
Test: manual with a work profile with a different pin
Bug: 378088320
Flag: EXEMPT bug fix
Change-Id: Ia70454d9859fb788ffa1f48f88760f88c354cdff
(cherry picked from commit 9df37c3f8be2dedd2e44e52da4de45fba33c6a6e)
After vetting the intent, use the component we used for the vetting.
Bug: 353680402
Bug: 365739560
Test: manual
Flag: EXEMPT bugfix
Change-Id: Iff0d820c1261c29eb6703bf89194339cba700688
(cherry picked from commit d3e34060803c97ae05719fe9301026e5c54892c8)
The function that sends the special code is sending intents to all
users, which is creating an activity for both the work profile and the
system user. Whichever intent is received last will be the activity on
top and displayed to the user, and since the work profile's hidden menu does not include the 'Phone
information' option it creates this 'randomness' observed with opening the menu.
This change ag/29101523 started sending the broadcast as UserHandle.ALL, instead of just from the current user causing the reception of more than one intent.
This fix checks for the work profile and returns out of the function without starting another TestingSettings activity.
Flag: EXEMPT bug fix
Bug: 406016005
Test: manual test opening hidden menu, and opening after reboots
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:170fcaf31628d3faf689ce1b525bfba33052d877)
Merged-In: I5a7937ba484afd3ba81c55e66bc53c217a778d18
Change-Id: I5a7937ba484afd3ba81c55e66bc53c217a778d18
- SatelliteManager#requestIsSupported only can be used in Manual
conneciton type. Hence add a type check with this API for the
condition check
Flag: EXEMPT bug fix
Fix: b/395811260
Test: atest pass
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:d033f603b819c5b1264d116648c9f6f00b061320)
Merged-In: Ia9fed86a63dd8fa87cc20a83888b3cabbf28ddd8
Change-Id: Ia9fed86a63dd8fa87cc20a83888b3cabbf28ddd8
Provide an interface for ODM/OEM to override fingerprint enrollment
findSensor page
Bug: 394232846
Flag: EXEMPT interface change
Test: adb shell am start -a android.settings.FINGERPRINT_ENROLL
--ez skip_intro true
Change-Id: Iff61f0be49faf3581fa2b26e364ac8c8d61bdbf3
As of Android 15, devices with FRP active will throw an exception when loading developer options attempts to update the OEM unlock state, which causes the app to crash. This CL just catches the exception and reports that OEM unlock is not, in fact, settable.
A full fix should probably tell the user that OEM unlock may not be set because FRP is active, rather than just quietly failing and logging the situation, but because GMS Core is soon going to begin blocking access to the Android UI when FRP is active, meaning that developer options won't even be reachable and the user will be informed about FRP state by GMS Core, the effort that would require isn't justified.
Note that this CL does not add a test for this change because it is not possible for CTS to put the device in FRP-active state to test the relevant case. Manual testing is required.
Test: SettingsUnitTests
Flag: EXEMPT bugfix
Bug: 405023810
Change-Id: Ic43de93a4208bbc17f2e287d52f9baf281cd678c
- Updates default icon to outlined version
- Makes availability conditional on existence of supervising credential
- Does not disable entry point when the main switch is disabled
Bug: 405159398
Test: atest SupervisionPinManagementScreenTest
Test: atest SupervisionDashboardScreenTest
Flag: android.app.supervision.flags.enable_supervision_settings_screen
Change-Id: I764a6b767019007a93aacf29ecf47677e16cb058
