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
Added a module licenses option that lives in Legal information settings.
Clicking that option opens module licenses page, which displays every
module by name, filtered to exclude modules without license files.
Clicking a module in the list opens HTMLViewer.
Created ModuleLicensesProvider, a new ContentProvider that serves as a
redirect for the Uris sent to HTMLViewer so that they open asset files.
In order to provide the redirect, the provider will write the license file
to a file in Settings' cache directory when the license does not exist
in the cache or is outdated. The provider then opens that cached file.
Fixes: 135183006
Test: robotests
Change-Id: I7d69da34780c8c4efb150d0c0411078c12bc80d8
On the SIM details page, the preference leading to a page for
configuring wifi calling will appear based on the results of the
MobileNetworkUtils#isWifiCallingEnabled helper function. That helper
uses the ImsManager to check several conditions, among them both
isWfcEnabledByPlatform and isWfcProvisionedOnDevice.
The page for configuring wifi calling has a tabbed UX, with one tab for
each active subscription that supports it. The WifiCallingSettings class
gets a list of the active subscriptions to determine which tabs to show,
and removes any that don't support wifi calling, but was only using the
isWfcEnabledByPlatform test to do so. This is a problem because the code
for showing the contents inside the tab, in WifiCallingSettingsForSub,
includes a sanity check of isWfcProvisionedOnDevice and calls finish()
if that returns false.
What this meant in practice is that if you happened to have 2
subscriptions where one returns true for both isWfcEnabledByPlatform and
isWfcProvisionedOnDevice, but the other only returned true for
isWfcEnabledByPlatform, then you'd never be able to succesfully use the
wifi calling page at all because the tab for the subscription you
*aren't* trying to configure would always call finish() early.
The right long term solution to this problem is probably to remove the
tabbed UX entirely from this page, since we probably don't need it given
the overall new multi-SIM UX. But there may still be legacy uses and
that is likely a bigger change than we want to make right now.
As a stopgap, this CL just adds a check of isWfcProvisionedOnDevice to
the code for filtering out ineligible subscriptions from the tabbed
interface, which we should have always had anyway.
Fixes: 135591718
Test: make RunSettingsRoboTests
Change-Id: I656c3d3fb30cb6fabcb86685eae38c5f0cd0c6f2
This reverts commit 43374eabb8.
Reason for revert: No longer needed because we are using whitelist for
SMS permission
Fixes: 135213238
Test: presubmit
Change-Id: I182be4a1136521f325866e70e875439c17816ef2
For some kinds of telephony changes that might happen while we're
already showing one of these dialogs, we already get sent a new intent
for the dialog which we internally convert into a refresh of the dialog
contents instead of stacking a new copy on top of the old one.
But it turns out there are some other cases where the telephony stack
doesn't send a new intent for the dialog but *does* send a change event
through the SubscriptionManager, and we want to respond to those as
well. This CL adds a listener for those events.
Fixes: 135276696
Test: make RunSettingsRoboTests
Change-Id: Ifb93ae95f45fda5831e112306dd9361ccaa5119c
(cherry picked from commit 6a1d7e60ac)
This fixes an exception in startActivity() call:
"android.util.AndroidRuntimeException: Calling startActivity() from outside of
an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really
what you want?"
Bug: 132904820
Test: manual
Change-Id: I0c687ea76068778554b072b6cc8274352de6fa28
That is caused by layout xml changes. The radio button was clickable
in old xml resource. But it is not clickable in new xml resource.
Therefore we can't receive click callback. Fixed by changing
Radio button state when preference is clicked.
Fixes: 135285101
Test: manual, make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.tts"
Change-Id: Idd7bf37d9ccbc1b56d41978d19dc05c8a81cc49a
After a user uses Wi-Fi QR code scanner to scan a QR code of an unreachable
Wi-Fi network, the scanner does not recognize any QR code until the scanner is
restarted or back from a screen off state.
To restart QrCamera after a Wi-Fi QR code recognition, we should stop it before
start, otherwise the DecodeTask will not work.
Bug: 135225856
Test: Scan a Wi-Fi QR code of unreachable Wi-Fi network and
scan a Wi-Fi QR code of reachable Wi-Fi network, check
if the scanner recognizes QR code.
Change-Id: I0063c867d8e4046f184d02134bda842887c003a1
