Makes it less likely we'll launch the next app too quickly after
restarting iorapd.
Bug: 152322429
Test: am instrument
Change-Id: I4fc35665f03ae7d9fe073accfcb1e04842c737dd
Ensure that both local wipe dialogs are shown by the BiometricPrompt
credential view as appropriate:
- A "last attempt" warning dialog when the user is one failure from a wipe
- The "now wiping" dialog shows before the prompt is dismissed
Test: Manual:
1. Create a work profile via TestDPC (go/testdpc)
2. Set a work profile lock pattern/PIN/password via Settings > Security
3. Launch the work profile instance of TestDPC
4. Scroll down to "Lock screen"
5. Tap "Lock screen restrictions"
6. Select the "Work profile" tab
7. Set "Max password failures for local wipe" to 3
8. Lock & unlock the screen
9. Launch work profile app
10. Enter the wrong pattern/PIN/password three times
Fixes: 152016710
Change-Id: I3771d222aaaacef5fa70c1246432a6fd1afdcd42
Background
* If the device is an organization-owned managed
profile device and a FRP policy is set, the
factory reset protection data is no longer
erased from factory reset in Settings.
Changes
* Added isNotEmpty method to FRP policy.
* Allow Settings to call
getFactoryResetProtectionPolicy
by checking for the MASTER_CLEAR permission.
Bug: 148847767
Test: manual testing
atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I04f178255dd215579087c33b675b40eed7a6eac7
The package installer v2 APIs were marked as @SystemApi merely as
a convenience for development. These APIs may change in the next
version of Android and their usage must be strictly controlled.
Bug: 151716357
Test: Manual. Use old Shell and see that incremental installation fails with a SecurityException
Test: Manual. Request INSTALLER_V2 permission for shell and see that incremental installation succeeds
Change-Id: I9612dc145eadda20083bcc43e7a35ef3cd90aa40
Reset the INTERACT_ACROSS_PROFILES app-op for all apps on the device
when creating a new work profile. This ensures that user grants for
previous work profiles (perhaps with a different admin) are not saved
and also not restored with backup-and-restore.
Also, clear the shared preference storing which oem-whitelisted apps the
user has granted. This ensures that the user sees them all again
during work profile provisioning.
Fixes: 151145623
Test: atest com.android.managedprovisioning.task.CreateManagedProfileTaskRoboTest
Change-Id: I5f5c5aea1c36bd17a74c02e1b6fa9b4047f15003
The benefit is that icon colors and icon scaling can be performed on a
background thread and then all of the views updated on the main thread.
Bug: 150454272
Test: atest KeyguardMediaPlayerTest.kt
Test: manual - play music and look at lock screen controls
Change-Id: I2423233f1ddeb081ab420053964c2b1cb2185514
Currently CameraService calls isUidActive() before allowing the camera
access.
When start/resume activity, WindowManagerService start/resume the
activity, then post a runnable to DiaplayThread and
ActivityManagerService to update UidRecord's
proc state, because the thread switch, the latency before proc
state update is undetermined.
When CameraService calls ActivityManagerService.isUidActive(), the proc
state may not have been updated and camera access is denied.
isUidActiveOrForeground() check isUidActive() first, if false,
check isUidForeground() which is actually to check with WindowManagerService if
the uid is foreground, which is equivalent to ActivityManagerService's uid
active, just updated earlier.
Bug: 151185692, 151777097, 109950150
Test: manual test.
Change-Id: Iffed63293dbdb466e7955fe765ad2aa23a20b3ed
When enabling Live Caption, remote submix device will be set as fixed
and full volume device in audio service. In that case, volume control
for remote submix will not be forwarded anymore. However, it is expected
to have volume control when the device is on chromecast mirror mode.
To solve the problem, tracking legacy remote submix device is active or
not in RecordingActivityMonitor. When legacy remote submix device is
active, remote submix will not be treated as fixed/full volume device.
In audio policy manager, the remote submix that is used by dynamic
policy will still be fixed volume device.
Bug: 144063329
Test: repo steps in bug
Change-Id: I1cb83c17f34e636763bb989e37ac8e021217cc39
Merged-In: I1cb83c17f34e636763bb989e37ac8e021217cc39
This CL fixes VolumeGroup CTS by preventing to set the volume per
stream for group associated to a non public stream type.
Bug: 136121584
Test: run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioProductStrategyTest
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioVolumeGroupTest
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioVolumeGroupChangeHandlerTest
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testPermissionsForVolumePerAttributes
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testGetAndValidateProductStrategies
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testGetAndValidateVolumeGroups
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testSetGetVolumePerAttributesWithInvalidAttributes
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testSetGetVolumePerAttributes
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testVolumeGroupCallback
Change-Id: I53d9d2d4d7591300bf364d591412b548356cd118
Wi-Fi icon was removed from status bar if it doesn't have internet
access. Rationale was that it gives users incorrect impression that
wi-Fi is enabled whereas in reality cellular is used.
However, in cases where there is no cellular Wi-Fi may be the default
network even if it has no internet access. In such cases, Wi-Fi is the
default network, always show it in the status bar.
Bug: 136473125
Test: atest NetworkControllerWifiTest
Test: visual inspection
Change-Id: I0ec189e2340d3280165cafd8747a7456f7e950f5
We now pass 2 booleans from AM to zygote about:
- If CE and DE data dirs need to be mounted
- If storage data and obb dirs need to be mounted
And also, separate whitelisted package from same uid packages, as same
uid packages do not need to be mounted in storage data and obb dir case,
it's needed to be mounted for CE and DE data dirs only. Otherwise
whtelisted packages will also be mounted in storage data and obb dirs,
which apps should not have access to it.
Bug: 151218156
Test: atest AdoptableHostTest
Change-Id: If7c20a7ed3b845d8657c937469161cb7ed3da07f
- Skip multi-window mode tasks with the exclude-from-recents flag from
the visible recent tasks list
- Expose a method in LauncherApps to be able to start a shortcut with
additional intent flags (to add the exclude-from-recents flag)
- Remove unused ActMan path (only ActTaskMan call is used now)
- Refactor the call to get the running tasks, there are currently only
two usages of getFilteredTasks(), one is to get all the tasks, the
other is really to get tasks that we will end up using for transitioning
into the task in recents.
As such, we can remove the individual ignore flags (it would get more
complicated if we wanted to filter based on logic like MW mode +
excluded recents only), and instead have a boolean that filters the
running tasks based on whether they would ever show in recents at all,
with the exception of the home and recent tasks.
Bug: 152133859
Test: atest WmTests:RunningTasksTest
Test: atest WmTests:RecentTasksTest
Change-Id: Ia4f5fd37228c72ce449490f948e923afba821bb2
Signed-off-by: Winson Chung <winsonc@google.com>
- When the task org binder died, it previously did not remove from
the mTaskOrganizersForWindowingMode list and handle replacements
the same way as unregistering. Likewise when unregistering,
the code to handle replacements could override the existing
state since it only checks if the previous state was not disposed
before setting it.
Alternatively, we can keep the list of TaskOrganizerStates for a
windowing mode in a list. The last item in the list is the current
task org for that windowing mode. When a task org is removed or
its binder dies, we simply remove from that list.
Bug: 152134222
Test: atest WmTests:TaskOrganizerTests
Change-Id: I1c7fd8907c7f025da25d62b0fa939edbb789e0cb
shareTitle and shareDescription is passed by the caller of the
bugreport. Show these in the finished bugreport notification.
Pre-set shareTitle takes precedence over user modified title.
shareDescription and description are not related/dependant on each other
in any way.
Bug: 150333444
Test: Manual (by passing EXTRA_TITLE and EXTRA_DESCRIPTION from
ActivityManagerService when trigerring a bugreport)
Change-Id: I2bfd080aeee677cdc8d0af339d7ad4a29451c3e0
Most of this was previously hidden; these last stragglers were missed.
Test: make update-api ; verify hidden
Fixes: 152394802
Change-Id: I41bda5b8ad368e1c88e4dd9e45d978a111a22e53
