Before this CL, there is a possible phishing attack allowing a malicious
BT device to acquire permissions based on insufficient information
presented to the user in the consent dialog. This could lead to local
escalation of privilege with no additional execution privileges needed.
User interaction is needed for exploitation.
This CL add more prompts presented for users to avoid phishing attacks.
Merge Conflict Notes:
There were a number of entries in strings.xml that did not exist on this
branch. However, as the CL only adds new entries rather than modifying
old ones this should not cause a problem. There were no merge conflicts
in the java files.
Bug: 167403112
Test: send intent to test right prompts message is pop up. make -j42 RunSettingsRoboTests
Change-Id: Idc6ef558b692115bb82ea58cf223f5919b618633
Limit the component that may resolve this intent to the
bluetooth package.
Bug: 158219161
Test: Security Fix
Tag: #security
Change-Id: If732f940a7aa256f5975349118e8eb6cf5584676
Prevent non-system overlays from showing over notification listener consent dialog
Bug: 170731783
Test: use a visible overlay, ensure it's gone when notification consent is open
Change-Id: I58e017982f385ffc0d0ba2174512490b1d83dd36
Prevent non-system overlays from showing over notification listener consent dialog
Bug: 170731783
Test: use a visible overlay, ensure it's gone when notification consent is open
Change-Id: I58e017982f385ffc0d0ba2174512490b1d83dd36
Prevent non-system overlays from showing over notification listener consent dialog
Bug: 170731783
Test: use a visible overlay, ensure it's gone when notification consent is open
Change-Id: I58e017982f385ffc0d0ba2174512490b1d83dd36
- Enable the filterTouchesWhenObscured attribute on all toggle
switches in all pages of the special app access
Bug: 155288585
Test: make RunSettingsRoboTests
Merged-In: I011cfe4b7e4e624a8338332ac47a353f7f3ab661
Change-Id: I85842db3faa558ea61bc878ca76ff6d8ce1a4b03
- Enable the filterTouchesWhenObscured attribute on all toggle
switches in all pages of the special app access
Bug: 155288585
Test: make RunSettingsRoboTests
Merged-In: I011cfe4b7e4e624a8338332ac47a353f7f3ab661
Merged-In: I0731057ec6e77c6a0867784c729c3f5812ef6170
Change-Id: I02c372423287366d0706bcdf7cdecff48db2e22a
- Enable the filterTouchesWhenObscured attribute on all toggle
switches in all pages of the special app access
Bug: 155288585
Test: make RunSettingsRoboTests
Merged-In: I011cfe4b7e4e624a8338332ac47a353f7f3ab661
Merged-In: I0731057ec6e77c6a0867784c729c3f5812ef6170
Change-Id: I0731057ec6e77c6a0867784c729c3f5812ef6170
- 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
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)
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
