- 3rd party developers can define himself-authenticator
and use the accountPreferences attribute to load the
predefined preference UI.
- If a developer defines an action intent to launch the
other activity in xml and it would return true due
to the true exported attribute and no permission.
- To avoid launching arbitrary activity. Here allows
to launch only authenticator owned activities.
Bug: 150946634
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.accounts
Test: PoC app
Change-Id: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
Merged-In: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
(cherry picked from commit d6d8f98844)
- 3rd party developers can define himself-authenticator
and use the accountPreferences attribute to load the
predefined preference UI.
- If a developer defines an action intent to launch the
other activity in xml and it would return true due
to the true exported attribute and no permission.
- To avoid launching arbitrary activity. Here allows
to launch only authenticator owned activities.
Bug: 150946634
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.accounts
Test: PoC app
Change-Id: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
Merged-In: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
(cherry picked from commit d6d8f98844)
- 3rd party developers can define himself-authenticator
and use the accountPreferences attribute to load the
predefined preference UI.
- If a developer defines an action intent to launch the
other activity in xml and it would return true due
to the true exported attribute and no permission.
- To avoid launching arbitrary activity. Here allows
to launch only authenticator owned activities.
Bug: 150946634
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.accounts
Test: PoC app
Change-Id: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
Merged-In: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
(cherry picked from commit d6d8f98844)
- 3rd party developers can define himself-authenticator
and use the accountPreferences attribute to load the
predefined preference UI.
- If a developer defines an action intent to launch the
other activity in xml and it would return true due
to the true exported attribute and no permission.
- To avoid launching arbitrary activity. Here allows
to launch only authenticator owned activities.
Bug: 150946634
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.accounts
Test: PoC app
Change-Id: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
Merged-In: I5ce1a0b3838db7b3fbe48c6ea23d5f093d625cdb
(cherry picked from commit d6d8f98844)
Allow LockScreenPattern to be launched in the pinning screen
If work profile lock is enabled and work app is pinned, users will get a
black/white screen on the phone. That's because Settings is prevented
from other apps launch any pages of Settings in the pinning mode.
In order to launch some pages of Settings from other apps, we add a
condition to the preventive mechanism and allow the activity inherited
from SettingsBaseActivity to override the condition to have the activity
to be launched from other apps in the pinning mode.
Bug: 137015265
Bug: 135604684
Test: manual test
Change-Id: I8070de79a83350d1658efcb19e983669dad0e673
Merged-In: I8070de79a83350d1658efcb19e983669dad0e673
Allow LockScreenPattern to be launched in the pinning screen
If work profile lock is enabled and work app is pinned, users will get a
black/white screen on the phone. That's because Settings is prevented
from other apps launch any pages of Settings in the pinning mode.
In order to launch some pages of Settings from other apps, we add a
condition to the preventive mechanism and allow the activity inherited
from SettingsBaseActivity to override the condition to have the activity
to be launched from other apps in the pinning mode.
Bug: 137015265
Bug: 135604684
Test: manual test
Change-Id: I8070de79a83350d1658efcb19e983669dad0e673
Merged-In: I8070de79a83350d1658efcb19e983669dad0e673
Allow LockScreenPattern to be launched in the pinning screen
If work profile lock is enabled and work app is pinned, users will get a
black/white screen on the phone. That's because Settings is prevented
from other apps launch any pages of Settings in the pinning mode.
In order to launch some pages of Settings from other apps, we add a
condition to the preventive mechanism and allow the activity inherited
from SettingsBaseActivity to override the condition to have the activity
to be launched from other apps in the pinning mode.
Bug: 137015265
Bug: 135604684
Test: manual test
Change-Id: I8070de79a83350d1658efcb19e983669dad0e673
Merged-In: I8070de79a83350d1658efcb19e983669dad0e673
Allow LockScreenPattern to be launched in the pinning screen
If work profile lock is enabled and work app is pinned, users will get a
black/white screen on the phone. That's because Settings is prevented
from other apps launch any pages of Settings in the pinning mode.
In order to launch some pages of Settings from other apps, we add a
condition to the preventive mechanism and allow the activity inherited
from SettingsBaseActivity to override the condition to have the activity
to be launched from other apps in the pinning mode.
Bug: 137015265
Bug: 135604684
Test: manual test
Change-Id: I8070de79a83350d1658efcb19e983669dad0e673
am skip reason: Change-Id If26eda408a9ef6fa03ad82e5bee51bb7185950d6 with SHA-1 ad2502a91a is in history
Change-Id: I80eb8a460114a01a025a7512112c022e2568b64e
am skip reason: Change-Id If26eda408a9ef6fa03ad82e5bee51bb7185950d6 with SHA-1 a545a85f9d is in history
Change-Id: I20f8b8521a7ada8e0f05edcee4df1e3ab87650b0
am skip reason: Change-Id If26eda408a9ef6fa03ad82e5bee51bb7185950d6 with SHA-1 ad2502a91a is in history
Change-Id: I4203109df4dcbd952e0ee09bc70ccd5d38ccc159
In Settings there is no auth mechanism to prevent accounts page being
opened in screen pinning mode. This CL makes it so that when users are
trying to navigate to any pages in Settings from other apps in screen
pinning mode, Settings app will directly close its page.
Bug: 137015265
Bug: 135604684
Test: manual
Change-Id: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
Merged-In: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
(cherry picked from commit f3242dab35)
In Settings there is no auth mechanism to prevent accounts page being
opened in screen pinning mode. This CL makes it so that when users are
trying to navigate to any pages in Settings from other apps in screen
pinning mode, Settings app will directly close its page.
Bug: 137015265
Bug: 135604684
Test: manual
Change-Id: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
Merged-In: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
(cherry picked from commit f3242dab35)
In Settings there is no auth mechanism to prevent accounts page being
opened in screen pinning mode. This CL makes it so that when users are
trying to navigate to any pages in Settings from other apps in screen
pinning mode, Settings app will directly close its page.
Bug: 137015265
Bug: 135604684
Test: manual
Change-Id: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
Merged-In: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
(cherry picked from commit f3242dab35)
In Settings there is no auth mechanism to prevent accounts page being
opened in screen pinning mode. This CL makes it so that when users are
trying to navigate to any pages in Settings from other apps in screen
pinning mode, Settings app will directly close its page.
Bug: 137015265
Bug: 135604684
Test: manual
Change-Id: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
Merged-In: If26eda408a9ef6fa03ad82e5bee51bb7185950d6
(cherry picked from commit f3242dab35)
Currently we always send cancel() if ConfirmDeviceCredentialActivity
goes into the background. However, if the biometric state is no longer
authenticating, requesting cancel() in this state will result in an
inconsistent state between BiometricService/client and
ConfirmDeviceCredentials.
BiometricService/client will receive the ERROR_CANCELED message incorrectly,
while ConfirmDeviceCredential is showing / pending user password. When
the password is entered, its result is ignored.
The correct behavior is for ConfirmDeviceCredentialActivity to invoke
cancel() only if it's still authenticating. Otherwise BiometricService
and its client will receive ERROR_CANCELED, instead of the actual password
auth result.
Bug: 138279856
Test: BiometricPromptDemo, enable device credential fallback, get into
lockout state, successfully enter password. API result is
success instead of "canceled" now.
Change-Id: I6521e896d0402fe856dc85476f51149c9b3084a8
Merged-In: I6521e896d0402fe856dc85476f51149c9b3084a8
Doing a factory data reset used to always erase eSIMs. Then a few months
ago we added a default-on checkbox to let users opt out of erasing the
eSIM during this process, but only had it show for some devices (ones
which support the "fastboot oem esim_erase" command) by adding a system
property named masterclear.allow_retain_esim_profiles_after_fdr.
When recently updating the strings shown in the factory data reset
screen and the confirmation dialog, we changed the code so that if that
the checkbox is hidden we'll pass false for the ERASE_ESIMS_EXTRA
parameter sent to the factory data reset confirmation dialog. This had
the unintended side effect of making devices that don't specify true for
masterclear.allow_retain_esim_profiles_after_fdr skip erasing the eSIM.
This CL fixes that by removing the "is the checkbox hidden" check, going
back to the previous behavior of just using the checkbox value, which is
on by default even if hidden.
Fixes: 135284765
Test: make RunSettingsRoboTests
Change-Id: Ia9f335920e4e3c4a90f0a6a49d1722a0c19ea83d
From traces analysis, we found getFreeBytes
was taking a long time to return.
getFreeBytes was used when storage controller
tried to get storage information.
In order to prevent this case, we put the action
which takes too much time in background thread.
Test: I can't reproduce it locally. From code view,
this is a reasonable root cause.
Fixes: 136268875
Change-Id: I78e42cde88553c003f198cffb5747b352055f59a
(cherry picked from commit 0c37f019f6)
Settings activities were launched and resided on home task
which was originally started by FallbackHome. Adding a
unique task affinity for FallbackHome activity in order to
prevent the task being reused by other Settings activities.
Bug: 135696366
Test: starting Settings activity before FallbackHome finishes
Change-Id: I3fe41dd3b77e37236b11006dbf08727783b6a2ec
