Create a mechanism to allow OEM config posture guidance with
'config_face_enroll_guidance_page', and customize the config
'config_face_enroll_supported_posture' with standard postures
0 : DEVICE_POSTURE_UNKNOWN
1 : DEVICE_POSTURE_CLOSED
2 : DEVICE_POSTURE_HALF_OPENED
3 : DEVICE_POSTURE_OPENED
4 : DEVICE_POSTURE_FLIPPED
For example, if we set 1 for the device, then device only
allow to enroll face in closed(folded) state, if device do
not in the allow state, we will prompt specific guidance
page activity defined in config_face_enroll_guidance_page.
At this stage , we only integrate 2 states OPENED/CLOSED through
ScreenSizeFoldProvider and register for onFoldUpdated() callback
- isFold(DEVICE_POSTURE_CLOSED): finish posture guidance
- !isFold(DEVICE_POSTURE_OPENED): launch posture guidance
- onActivityResult : reset mOnGuidanceShown false
1. Fix A11y lottie animation bug
2. Impl FoldProvider.FoldCallback
3. Register callback to ScreenSizeFoldProvider
4. Integrate back stack, skip, cancel events
- Back key : RESULT_CANCELED
- Skip btn : RESULT_SKIP
- Posture changed : RESULT_FINISHED
5. Set single instance for relative activities
6. FaceEnrollFoldPage listen for onConfigurationChanged()
7. Add empty face_posture_guidance_lottie.json for overlay
Test: atest SettingsGoogleUnitTests
Test: m -j SettingsGoogleRoboTests RunSettingsGoogleRoboTests
Test: m RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.biometrics.face.FaceEnrollEducationTest"
Test: m RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.biometrics.face.FaceEnrollIntroductionTest"
Test: Manual launch security settings face enroll, unfold device
and observe posture guidance showing fullscreen on top
Test: Fold device ensure the posture guidance activity finish
Bug: 261141826
Fixes: 231908496
Change-Id: Ib9f43f82f7d19f3f187c2f6f8984e76cd843afbc
Merged-In: Ib9f43f82f7d19f3f187c2f6f8984e76cd843afbc
1. Add config_suw_support_face_enroll default is TRUE
2. Impl FaceFeatureProvider to obtain the config
3. Overlay config_suw_support_face_enroll by requirements
Test: Flash build and manual check if device go through face enroll in SUW
Bug: 262469686
Change-Id: I61aa5c818bedfb490f2172a7481f59fda7295c1a
Merged-In: I61aa5c818bedfb490f2172a7481f59fda7295c1a
When requestGatekeeperHat() throws exception in FaceEnrollIntroduction
page, remove gk_pw_handle and recreate activity to trigger confirmLock.
Test: robotest for FaceEnrollIntroductionTest
Bug: 234437174
Change-Id: Ie1dd6f36e4deb3f776e3b39acd165fc47d04f526
Merged-In: Ie1dd6f36e4deb3f776e3b39acd165fc47d04f526
Since the SetupChooseLockPattern include header icon
header title, header sub-title, pattern state description,
LockPatternView and FooterBar, there was a limited room
for LockPatternView especially in the confirm steps which
both header title and pattern description occupy 2 lines space.
Hance the PatternView size used to inconsistence in-between
1st draw and 2nd confirm draw, besides it's visual looks
jumping and small on some device which have smaller display.
This solution includes 3 changes:
1. Organized the pattern view message to leverage
header sub-title view, then we can resever more space.
(Set minHeight=2 for sub-title)
2. Set screen_lock_options button visibilty to GONE when
the stage in 2nd confirmation.(Previously it's INVISIBLE
and reserve additional space)
3. Let LockPatternView align bottom of FrameLayout to prevent
the view juming and flicker.
4. Clean up unused forAnyBiometric flag and code.
5. GlifLayout.getDescriptionTextView() == mHeaderView
Need setDescriptionText() to make the view from GONE -> VISIBLE
6. Polish the stage flow and ensure IntroductionStage show
correct message
7. Add ChooseLockPattern into embeded activity white list
Force show ChooseLockPattern in fullscreen in case the Pattern
view truncated in `NeedToConfirmStage` where the title showing
2 lines and push pattern view down, and get bad UX in the
device which integrate a shorter display.
8. Add test cases for all stage and polish legacy test code.
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.SetupChooseLockPatternTest"
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.ChooseLockPatternTest"
Bug: 249974175
Bug: 260027850
Change-Id: I868af9b14ba99af5d78a05f6c2a570ccc07aea15
Temporary remove the redundant padding from ChooseLockPattern and
ConfirmLockPattern as a workaround solution.
Bug: 243008023
Test: make and check visual on foldable
Test: make RunSettingsRoboTests
Change-Id: I0baa2be65b797ca70f9de43bc8c5e3187a2d28ad
Merged-In: I0baa2be65b797ca70f9de43bc8c5e3187a2d28ad
Bug: 243902048
Test: manual - check that the illustration on tablet is shown
- check that switching between dark and light theme
updates the illustration
- do above on phone
Change-Id: Idcc3660be287ed26a231813001de0517481ef514
When users enable Winscope tracing, ViewCapture tracing will also be enabled. Winscope tracing is currently enabled via a quicksettings tile hidden in the developer options menu.
Bug: 224595733
Test: Verified that the new QuickSettings tile doesn't crash via normal interactions (pressing, long-pressing, etc.). Also verified that ViewCapture is turned on when the QuickSettings tile is in the enabled state and is turned off when it is in the disabled state.
Change-Id: Ie43d307806dece5748e22ed2af12ed3514c1148a
For devices that don't support wallet, don't even show the setting in
a disabled state, which can cause confusion and lead the user to
believe they can enable it somehow.
Fixes: 251089510
Test: WalletPrivacyPreferenceControllerTest
Change-Id: I5d60957f24712bb4d75e72fa5f64cab35b6d6a5f
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Settings App info page supports a "Uninstall for all users" function
when multiple users are enabled. It bypasses the restriction of
DISALLOW_APPS_CONTROL which breaks the user isolation guideline.
To fix this vulnerability, we should check the DISALLOW_APPS_CONTROL
restriction to provide the "Uninstall for all users" function.
Bug: 258653813
Test: manual & robotests
Change-Id: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
Merged-In: I5d3bbcbaac439c4f7a1e6a9ade7775ff4f2f2ec6
When ring volume is separated from notification, a new xml preferece and
controller is needed for it, so that the settings search can show/hide
the slice correctly.
1. Use a separate preference and controller for ring volume (vs ring &
notification combined)
2. Notification slice in settings no longer grays out when ringer mode
is set to mute or vibrate.
3. Introduce an abstract RingerModeAffected preference controller class
to factor out duplicate code among ring, notification, and separate-ring
controller classes.
Bug: b/259084354
Test: make ROBOTEST_FILTER=RingVolumePreferenceControllerTest
RunSettingsRoboTests -j40
make ROBOTEST_FILTER=SeparateRingVolumePreferenceControllerTest
RunSettingsRoboTests -j40
make ROBOTEST_FILTER=NotificationVolumePreferenceControllerTest
RunSettingsRoboTests -j40
make ROBOTEST_FILTER=VolumePanelTest RunSettingsRoboTests -j40
make
ROBOTEST_FILTER=RingerModeAffectedVolumePreferenceControllerTest -j40
Known Issue:
1. When streams are separate and ring volume set to mute/vibrate,
notification is set to zero, but not disabled. So it can be turned on
by user (and in settings the icon will stay mute/vibrate instead of
changing to the normal notification icon).
2. In the above scenario after notification is unmuted in settings,
the notification icon continues to stay vibrate/mute -- should change
to the normal notification icon.
Note: This feature is controlled using a boolean DeviceConfig flag:
systemui/"volume_separate_ring". The default value is 'false', which is
meant to keep the experience the same as before. It will be set to
'true' for teamfood and dogfood. Eventually the flag will be removed and
the code in the 'true' branch will prevail.
Change-Id: Ibec871eafeef4081e96c5e0dd04535565d50a077
KeyguardQuickAffordanceProvider has started to be used for more than
just lock screen shortcuts. This collection of CLs updates its name,
authority, and table schema to become more generically about "system UI
customization".
Fix: 262879277
Test: manually verified Settings > Display > Lock screen shows the
"shortcuts" item
Test: manually verified that the Wallpaper picker properly renders the
preview and can change the quick affordances
Test: manually verified that system UI displays the right lock screen
shortcuts
Change-Id: Idc0765a8c3fe50c82689d2ca7f9d19b41a62baf2
Merged-In: Idc0765a8c3fe50c82689d2ca7f9d19b41a62baf2
WFC toggle's state(EXTRA_TOGGLE_STATE) is set to the newValue after each notifyChange.
However, WFC slice gets the same newValue from EXTRA_TOGGLE_STATE when users change the toggle state
before the EXTRA_TOGGLE_STATE is updated.
Need to get the "correct" new value to set the WFC
Follow the original logic(ag/3820815), 1. don't turn on WFC and only can turn off WFC if activationApp is not null. 2. turn on/off if no activationApp.
Bug: 261922170
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=WifiCallingSliceHelperTest
Change-Id: I823f00029c24f1901f40757ba13e7c0f90d6c0bc
This change adds a new top-level setting, of which the availability is
controlled by a build time config value. It also registers the new
communal category so that prebuilt packages can inject preferences into
it.
Bug: 261641080
Test: verified on device that communal settings show up on top level
Test: atest ScreenSaverPreferenceControllerTest
Change-Id: Idf79ae5b89ecc3498373de56a677b4876fb121c3
If an Activity is not exported, the Activity still can be
launched by components of the same application, applications
with the same user ID, or privileged system components.
Bug: 261678674
Bug: 250589026
Change-Id: I89b2ae49b3b13f29b0a02cd54291937241f61696
Merged-In: I662df6cb287361b135e2c596abe946ddeb03bda4
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
This change makes it that the ScreenSaverPreferenceController extends
BasePreferenceController so that it can be readily used and pointed to
from an xml file.
Bug: 261627295
Test: atest ScreenSaverPreferenceControllerTest
Change-Id: I95487f2f49a23422fff46f30b0cfa287582a547b
- Due to unclear root cause of optimization mode being reset after
reboot, update the setup logic from deferred background thread to
main thread, to avoid any possible background task unexecuted case.
Bug: 241735485
Test: make SettingsRoboTests
Change-Id: I2de2181321712f89fadc04bf5000aea91a01485a
Merged-In: I2de2181321712f89fadc04bf5000aea91a01485a
(cherry picked from commit 7423f4390c)
To improve security, calling app must be granted Uri permission
if it sets FLAG_GRANT_READ/WRITE_URI_PERMISSION in the Intent of
ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY.
Bug: 250589026
Test: manual
Change-Id: I48f88c662b843212b1066369badff84cf98935a8
Merged-In: I48f88c662b843212b1066369badff84cf98935a8
To improve security, calling app must be granted Uri permission
if it sets FLAG_GRANT_READ/WRITE_URI_PERMISSION in the Intent of
ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY.
Bug: 250589026
Test: manual
Change-Id: I48f88c662b843212b1066369badff84cf98935a8
Merged-In: I48f88c662b843212b1066369badff84cf98935a8
To improve security, calling app must be granted Uri permission
if it sets FLAG_GRANT_READ/WRITE_URI_PERMISSION in the Intent of
ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY.
Bug: 250589026
Test: manual
Change-Id: I48f88c662b843212b1066369badff84cf98935a8
Merged-In: I48f88c662b843212b1066369badff84cf98935a8
While resolveActivity is used to determine whether an Intent can be handled by something, this doesn't catch the case of explicit intents whose activity class doesn't exist. Here we check for it through PackageManager.queryIntentActivities instead for existing zen rules (if they were added when the activity exists, but it no longer does).
For new rules, check the validity of the activity for external rules before adding them to the list.
Bug: 238144390
Test: manual via DND app
Change-Id: Ia920ca792f9c17a5d684baf877c882ce7fadffd6
