In general the mobile network details page has several preference
controllers that don't listen to carrier config changes, so instead of
having each one add a listener, we instead just have one listener and
refresh the entire page when we see the broadcast.
Fixes: 135587885
Test: make RunSettingsRoboTests
Change-Id: Iff5b28dbfe12d94c901b442b23cece8e68218983
updateState was invoked in loader callback. But the
package was uninstalled at the callback time caused
null pointer exception. Add null check to prevent
null pointer access.
Fixes: 136170218
Fixes: 133771724
Test: make RunSettingsRoboTests, manual
Change-Id: I2715e77f6e32af42a4bce70c9f409b0311eb36c4
(cherry picked from commit 790a822526)
Use the "July 13, 2019" or similar to display if the value is a valid
date data.
Bug: 137089104
Test: visual test & robotest
Change-Id: Ie4bab2617c1cd6fd956bf6d1a22ce96e6b0b58d0
Merged-In: Ie4bab2617c1cd6fd956bf6d1a22ce96e6b0b58d0
(cherry picked from commit 162e88c262)
Bug: 137197916
Test: Manual test with setting a 3P launcher as default
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SystemNavigationGestureSettingsTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SystemNavigationPreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=RadioButtonPreferenceWithExtraWidgetTest
Change-Id: Id397cfa1c2439222aa21a7b7fe5f69818bf1fe97
The launchMode for MobileNetworkActivity specified in the android
manifest is "singleTask", which means that when an intent to it is
launched, if there is an existing instance we will reuse that instead of
creating a new one. But to handle this properly we need to know when it
happens by implementing onNewIntent, which we weren't doing.
Implementing this fixes a bug we noticed that if you have multiple SIMs
and recently visit the details page for SIM 1 but then click on a SIM
selection notification that should bring you to the details for SIM 2,
we'd just bring up the details page for SIM 1 again.
Fixes: 133447239
Test: make RunSettingsRoboTests
Change-Id: Ia9106b15ffde437f6dd6fd2da23336ec5b28f75e
Follow up to http://ag/8222583
- Replace references to Secure.NOTIFICATION_BUBBLES with
Global.NOTIFICATION_BUBBLES
Fixes: 136034310
Bug: 129158983
Test: m RunSettingsRoboTests
Test: atest SystemUITests
Test: manual - work profile bubbles show up
Change-Id: Ifa71206353237b837cfcda6d23ea6a6ec2c146d0
Follow up to http://ag/8222583
- Replace references to Secure.NOTIFICATION_BUBBLES with
Global.NOTIFICATION_BUBBLES
Fixes: 136034310
Bug: 129158983
Test: atest SystemUITests
Test: manual - work profile bubbles show up
Change-Id: I03ffd7f1126f2c20d819f741cd4f7dcced81a405
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
- Use tint instead of custom fillColor to be consistent with overlays.
- Standardize on using @android:color/white as fill color
- Update list of overlayed icons.
Bug: 131346125
Test: make
Change-Id: I4bc88e5842ba2f149356929a77b81459ce5042c5
- Use tint instead of custom fillColor to be consistent with overlays.
- Update list of overlayed icons.
Bug: 131346125
Test: make
Change-Id: Ib548c0b47db0064bcb1536c9b7a650912f28273f
Merged-In: Ib548c0b47db0064bcb1536c9b7a650912f28273f
Bug: 132292477
Test: View all related screens.
(cherry picked from commit 1e7c172ad5)
This should have been submitted with ag/8109287
Bug: 136012133
Test: Clicked through permission screens on cuttlefish
Change-Id: I2663aa365baf78ccc6f0a3d585b09da0dd387970
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
Fixes: 134965754
Test: Verified slice appears when not enrolled.
Test: Verified slice does not appear when enrolled.
Test: Verified slice disappears after clicking on icon and going back
to settings page.
Change-Id: Id1c4458742ab622df8d5881e926fe54684b36843
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)
