4579c0aea2 changed the method signature
of the constructor of ResourcesKey, which is marked
UnsupportedappUsage. Restore the previous signature and provide a new
constructor that is hidden.
Bug: 147359613
Test: none
Change-Id: I391167e9064b1d88f4ad75200a190e5e3b0968cf
Settings.Global.ENHANCED_CONNECTIVITY_ENABLED was not added to the
SettingsBackupTest. Adding to test to fix android.provider.SettingsBackupTest#globalSettingsBackedUpOrBlacklisted
Bug: 150207643
Test: atest SettingsProviderTest
Test Result:
[1/107] android.provider.SettingsBackupTest#systemSettingsBackedUpOrBlacklisted: PASSED (26ms)
[2/107] android.provider.SettingsBackupTest#globalSettingsBackedUpOrBlacklisted: PASSED (0ms)
Change-Id: Ia5c225919c54594d17cbdfa4d8268be0aeb995b9
Created a SurfaceFreezer class which lives in WindowContainer
and manages/will-manage per-container freezing (snapshots).
This replaces the one-off change transition code.
Change Transitions used to create its own temporary leash
on initialization and that leash would be replaced/cleaned-up
as soon as the animation leash was created.
Now, the SurfaceFreezer creates the animation leash immediately
and SurfaceAnimator can take a SurfaceFreezer instance when it
starts an animation. At this point it will take the leash that
was already created by the freezer and use that. This removes
the messy reparenting/cleanup.
To deal with this, though, leash callbacks into Animatable
needed an extra stage: onLeashAnimationStarting. This is called
when SurfaceAnimatior is actually starting to animate the leash.
Next, DC.mChangingApps was converted to list of WindowContainers
rather than ActivityRecords. Some of the existing change code was
cleaned up (ie. there was some visibility stuff that doesn't make
sense because changing apps are visible->visible) and some of the
Activity-specific functions were generalized. For now, there are
a couple things that use the top-activity for changing Tasks.
The result of this means that windowing-mode change transition can
now fully live at the Task level. This also should allow freezing
at any hierarchy level which enables app-freezes that don't freeze
the whole screen and potentially mixed seamless/snapshot-based
rotations.
Bug: 149490428
Test: existing tests pass. Manually open app in freeform and
maximize/restore it.
Change-Id: Ib32524ebbbb084a98442d3d035897306a11ee6c2
(cherry picked from commit e55b9e0f9d)
Any exception here (e.g., NPE) will crash the entire system process.
Bug: 150217444
Test: atest AppIntegrityManagerServiceImplTest
Change-Id: I86eaa0bf7cb9d39fb23ee6aa71e80547bb95cc7e
(cherry picked from commit 1787f31065)
Due to the switch to Async HotspotControllerImpl, if the controller is
created with the tile it will think that tethering is not available
(because it hasn't received callbacks saying otherwise yet) and the tile
will be preemptively destroyed. This was observable on OTAs (or when
doing a full flash).
With this change, HotspotControllerImpl will assume that tethering is
available by default and will signal callbacks if it learns that it's
not.
There are currently no other consumers of
HotspotControllerImpl#isHotspotSupported.
Fixes: 149492796
Test: atest HotspotControllerImplTest
Test: manual full flash
Change-Id: Id1461b7fbe973b732bc69c7ad77a30e0f66247d8
statsd logs when an sensitive appop is accessed while a foreground
service is held. These appops include
OP_FINE_LOCATION
OP_COARSE_LOCATION
OP_RECORD_AUDIO
OP_CAMERA
It logs the number of times each of these appops is requested per session
during which the uid holds any foreground service.
Appops requested while the app's process state is TOP are ignored.
Also, the pre-existing ForegroundServiceStateChanged atom has an
additional field that logs whether the fgs is considered 'in-use' in the
context of being allowed while-in-use permissions.
Bug: 149497535
Test: atest UidAtomTests#testForegroundServiceState UidAtomTests#testForegroundServiceAccessAppOp
Test: manually monitor: adb shell cmd stats print-logs && adb logcat -v uid -s statsd | grep "statsd : {" | egrep '\((60|256)\)'
Change-Id: I991a427dc2ab00399188b10b266ab2d9aa92696d
Merged-In: I991a427dc2ab00399188b10b266ab2d9aa92696d
(cherry picked from commit 0c8637c067)
This flag will now be used to show different ui if the permission has
been previously set as one-time
Test: Reboot and verify ui is consistent
Bug: 144389816
Change-Id: I86fb595b79819a604aaed613d9edf30c883d1440
When permission is granted to another app via URI, we implicitly grant
visibility to that app of the app ID that that URI resolves to.
Test: atest AppSecurityTests
Fixes: 149781706
Fixes: 145677500
Exempt-From-Owner-Approval: Owner approved prior to cherry-pick
Change-Id: I7c8967a4464fd821e4f95d8eb6c0bcfadadb912e
From this CL onwards, the default for controls is enabled (still not a
Setting).
The controls section in power menu and the new layout will only be used
if there's at least one app that can provide controls.
Test: manual
Bug: 149992619
Change-Id: I4e78735d642d24fe0080a0f0f4cbc58ffa2d5a94
- Draw a background pill instead of frame on the keyguard
for the currently active user.
- Set a different text style for the user switcher
Bug: 146426568
Test: Manual inspection
Change-Id: I5cfefbe375bb0f3b7df8729c473867b97578f81f
(cherry picked from commit d457eef32c)
