Add new tutorial dialog for gesture navigation in order to teach
users how to use the gesture
Fixes: 133650388
Test: Manual
Change-Id: I7cc6a950af49044b27cf7ca41e3bcf67ef40b5fd
Merged-In: I7cc6a950af49044b27cf7ca41e3bcf67ef40b5fd
We initially landed support for erasing an eSIM subscription in
ag/7208624 for b/124254555 using our own confirmation/progress UI, and
calling the EuiccManager.deleteSubscription method to do the
deletion. It turns out this is a low-level API which doesn't handle some
important cases such as subscription grouping or the eSIM slot not being
active.
This CL changes Settings to just launch an intent to begin an eSIM
Manager flow to delete a subscription that provides its own
confirmation/progress UI, and should properly handle subscription
grouping and making the eSIM slot active as needed.
Bug: 132114333
Test: make RunSettingsRoboTests
Change-Id: Ie59fea37fa73c5e6573e1181e271ffb5d453bd08
Set doucmentLaunchMode to always for WifiDialogActivity. Always
create new task when launching wifi dialog activity so it won't
try to open the existing one.
Test: Manual
Fixes: 133206261
Change-Id: If35f0ea8f6d2f6b94ff58b4508f73f265ca4b5dd
The feature failed after the CL "Force the adapter to rebind cards with
a toggle".
Because toggle slices have been forced to rebind after starting another
activity and when any slice is updating. This unpins Wi-Fi slice and
stops WifiScanWorker and then clears the saved clicked network.
Solution:
1. Change ConnectToWifiHandler from activity to receiver and send
broadcasts to it with FLAG_RECEIVER_FOREGROUND, so Wi-Fi slice won't
be forced to rebind.
2. Seperate Wi-Fi scan worker and contextual Wi-Fi scan worker. Keep the
original logic for the generic one, and then add the logic below to
the contextual one.
3. Do not clear the saved clicked network when slice is unppined because
it happens frequently in contextual homepage.
4. Introduce a static long in ContextualWifiScanWorker that updates once
in every visible UI session. A session is when the screen is visible
to user.
5. Use session token to determine whether auto-starting captive portal
is needed.
Fixes: 128056349
Test: robotest, visual in homepage and network panel
Change-Id: I9e03c379806e124fa7253b2a635574b2433f6afc
Set panel launch mode to singleInstance to avoid panel can show up
infinite time when user keep launching panels (Easy repro by
pressing volume hard key > settings again and again).
After changing launch mode to singleInstance, we will need to do
some refactors, to avoid weirdness when adding/changing/closing
panels:
1. Move and refactor logic in SettingsPanelActivity#onCreate.
We will need onNewIntent here to handle Panel launching, since
we only have one instance of SettingsPanelActivity now.
Also do refactor here to reuse the PanelFragment instead of
creating one every single time, to better handle the exit
animation, avoid janky exit behavior from the old PanelFragment
2. Move logic from PanelFragment#onCreateView, to reuse it when
updating panel content.
Also add exiting animation when we are transitioning the panel
from one to another. Also add alpha animation to make it move
more smoothly.
3. Adding flags to launch see more intent in settings.
Fixes: 131225920
Fixes: 131254399
Test: manual
Change-Id: I93d3708bd02a2d736e38685475f2d9988ef62d31
Also added extra to the existing wallpaper suggestion so it opens
directly to that tab instead of the style tab
Test: atest com.android.settings.wallpaper.StyleSuggestionActivityTest
Fixes: 126230901
Change-Id: I50ca588627063194900dca8a9273baff4a44ca67
A follow up CL will clean up and separate the DeviceAdminAdd and
ProfileOwnerAdd logic (see b/131713071)
Bug: 124066840
Test: manual (overlay config_defaultSupervisionProfileOwnerComponent and
confirm only that component can be set as profile owner after setup is
complete)
Test: manual (install CtsVerifier, adb shell am start -n "com.android.cts.verifier/.admin.tapjacking.OverlayingActivity", user should not be able to click the "Allow" button)
Change-Id: Iccd931801145719110ce75421c35db80ea651779
Creating an no-op backup agent in settings. This ensures that
we get onRestoreFinished callback after restore is finished where we
can update all pinned shortcuts.
Bug: 110016648
Test: Verified backup->clear-data->restore path on device
Change-Id: Id14d0792d60ba08d97078a31a81d2b63ab8ce109
This adds a preference to the mobile network details page that lets a
user delete an eSIM profile.
Bug: 124254555
Test: make RunSettingsRoboTests
Change-Id: I1e266566afc36ff39bf1b1c6d1db674c7c6e8648
Adding a notification in SimSelectNotification that will be triggered
when receiving a enable MMS request. Tapping on the notificaiton will
lead to the subscription setting page.
Bug: 130222866
Test: manual -- have a test app that sends the intent when mobile
data is turned off. And verify that the heads-up notificaiton is shown
and that it will lead to subscription setting page.
Change-Id: Ia80e8e5ab20adf78a31647a23cb2ba8dac690e41
Remove the entry point for SimSettings and redirect any intents to the new UI.
Filed b/131324863 to track deleting the code.
Fixes: 128859223
Bug: 131324863
Test: adb shell am start -a com.android.settings.sim.SIM_SUB_INFO_SETTINGS
shows main connectivity screens
Change-Id: I4a4ed5c34d231eaab929a923c7fcbbfc1e0ed6f3
Fixes: 130696835
Test: Manually test as following stpes
1. Tap "BYOD Managed Provisioning" under "Managed Provisioning" section
2. Tap "START BYOD PROVISIONING FLOW"
3. Tap "Cross profile intent filters are set"
4. adb logcat -s 'android.settings.PRIVACY_SETTINGS'
-> No error about android.settings.PRIVACY_SETTINGS
Change-Id: I8fa3b61f14ca2da577493643cda4d7d0c66b8b0b
The SimDialogActivity is used to ask the user questions about which SIM
card to use for various services like calls, SMS, and data. In some
cases of SIM changes (eg when a SIM is added or removed), the telephony
stack sends a broadcast that SimSelectNotification listens for so it can
pop up a general "SIM cards changed" notification, and we additionally
want to bring up an interruptive dialog to ask the user a specific
question. This might happen for instance when we want to ask the user's
permission to turn on data on a SIM.
Recent DSDS changes in the telephony stack have meant that we
accidentally create several stacked copies of this dialog, because they
send several broadcast updates as information about SIMs asynchronously
changes. For instance, we might initially detect a SIM with a generic
name of "CARD 1", and shortly after discover the actual carrier name. So
what we really want is to put up the dialog, and update it as
information changes.
This CL makes SimDialogActivity use launchMode="singleTop" so that
additional copies of the activity won't be launched. Then it internally
enforces only showing one dialog per type of request (calls, SMS, data,
or preferred sim). If we get a request for a dialog that already exists,
we just update it instead of creating a new one for that type. So there
can still be a stack of more than one dialog, but each one will be
asking a different question.
This also refactors the monolithic, somewhat confusing code for showing
the various types of dialogs into a more clearly separated class
hierarchy, and switches to using DialogFragment for the dialog.
Fixes: 126596081
Test: manual (start with device in DSDS mode with 2 subs, remove SIM
card and re-insert it)
Change-Id: I0dbc41dc3b15015389823a24df10bbff08ec6615
