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)
Cached call values are kept in ChangeIdStateCache (per-process cache).
Use "cache_key.is_compat_change_enabled" system property to
invalidate the cache (i.e. any value different from the last observed
will trigger an invalidation).
Any process can read that property, but only system server can change it.
Rolling forward the original caching with invalidating the cache upon
package install/update.
Tested fix locally by using the API in SoftRestrictedPermissionPolicy.java,
and running android.permission2.cts.RestrictedStoragePermissionSharedUidTest
which installs some apps with the same uid, which modifies the result of
isChangeEnabled. With the additional cache invalidation the test passes.
ToDo: add CTS test for the caching.
Bug: 140441727
Test: atest PlatformCompatTest
Test: atest CompatConfigTest
Test: atest CompatChangesTest
Test: atest PlatformCompatGating
Change-Id: I0265df1c427b43592e4f4d32fe9cfeb8fbc1bfa9
Currently, the DreamService uses a floating Window to display the
content of the dream on the screen. This introduces difficulties in the
interactions with the Assistant application, which is an activity.
By design, if the Assistant is invoked while the device is dreaming, the
Assistant should be shown on top. However, since floating windows are
always drawn on top of all activities, the Assistant can't be shown on
top of the Dream.
Here, we migrate the implementation of the DreamService to use an
Activity (DreamActivity). Since the screensaver application is not part
of the framework, we can't declare the activity in their AndroidManifest.xml.
Therefore, we start the dream activity with a dedicated method in
ActivityTaskManagerService.
Bug: 133216167
Test: 1. m && ./vendor/google/tools/flashall
2. Go to Settings > Device Preferences > Screensaver > Start now
3. Verify dream appears
4. Click any key to wake up the dream
5. Verify that dream disappears
Merged-In: I8dff0a124cd1b41fb925a73528305431b49ee06d
Change-Id: I8dff0a124cd1b41fb925a73528305431b49ee06d
(cherry picked from commit 148478a85e)
ApplicationInfo now automatically tries to "squash" the same instances in a
Parcel.
NOTE: This CL still does *not* optimize the package manager APIs that return a
list. e.g. PM.queryContentProviders() still return duplicate AppInfo's.
We can optimize them by making ParcelableListSlice call "allowSquashing",
but that *could* have negative side effects, so I'm not doing it in this CL.
I think we can do that for S.
Bug: 148588589
Test: atest CtsContentTestCases # except for two preexsiting failures:
- android.content.pm.cts.PackageManagerTest#testGetIcon
- android.content.pm.cts.PackageManagerTest#testGetPreferredActivities
Test: Use the debugger and make sure bindApplication() is not receiving
duplicate AppInfo's in the provider list.
Change-Id: I3ba2c047a469169340c0f75c36bdfd394bc5d627
(cherry picked from commit 7d09275d70)
The bounds animation is cleaned up within window manager and it's now
the SysUI component listening on callbacks from TaskOrganizer for
entering to and exiting from PiP mode.
Additionally, the expand and move of the PiP window is now part of SysUI
as well.
Known issues:
- Black background when in transition from PiP to fullscreen. The
wallpaper gets into hidden state too early
- App gets into PiP mode too early when entering PiP, need to defer the
configuration change sent to app in this case
Bug: 146594635
Bug: 148198539
Bug: 138144750
Bug: 149569903
Test: atest PinnedStackTests
Test: atest PipAnimationControllerTest
Test: atest RecentsAnimationTest
Test: atest RecentTasksTest
Test: atest com.android.server.wm.ActivityStarterTests
Merged-In: Id0c8ce03fa26952daf5e3687b18b2eb2375b7d20
Change-Id: Id0c8ce03fa26952daf5e3687b18b2eb2375b7d20
Change reduced scale implementation to toggle on/off based on
config_lowResTaskSnapshotScale=0 instead of ro.config.low_ram=true
Also, only use _reduced.jpg if reduced scale is enabled. Previously,
for task snapshots, [0-9]+_reduced.jpg would be used if reduced scale
was disabled, and [0-9]+.jpg would never be used. This patch swaps that
behavior to make the underlying system more intuitive. Now, if reduced
snapshots are disabled, store the task snapshot in [0-9]+.jpg and never
use [0-9]+_reduced.jpg.
Also, store low-res snapshots at config_lowResTaskSnapshotScale.
Prevously, low-res snapshots were stored at lowResScale * highResScale
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148099851
Bug: 142063079
Change-Id: I5a0d58766347d875eaec138820323063aa1c2988
Store the original task snapshot size instead of the scale from which
the bitmap was saved. This simplifies the logic around restoring and
saving from the proto, as both the reduced scale and full scale
snapshots make use and share the same state.
Also remove scale from TaskSnapshot, and remove and reducedScale from
TaskSnapshot.Builder.
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148491788
Bug: 148617404
Bug: 142063079
Change-Id: I1dccaba87c3d8b95bf4156f41f9fd5d40019f675
destroy() removes callbacks from AppPredictionManagerService but not
from mRegisteredCallbacks.
Bug: 149388856
Test: manual
Change-Id: Id08d6b20362486bd1640310c64da35e0382d9b5e
Bug: 148240416
Test: Manually tested by installing two apps running in a shared process
and starting their shared process activities in various orders. The
value of usesCleartextTraffic gets set as expected.
Change-Id: Ib350c09c42d5524734fb259a2ab787790f2d8e30
Rename:
config_fullTaskSnapshotScale -> config_highResTaskSnapshotScale
config_reducedTaskSnapshotScale -> config_lowResTaskSnapshotScale
Both full and reduced scale can be "reduced" from 100%, so name them
more clearly.
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148617404
Bug: 142063079
Change-Id: Ie8073d5a3048c19450308b2af22d363deaa51b6a
Reason for revert: cache needs to be cleared on package install.
This is much simpler to do in internal master with recent changes
(ag/10172190) so I'm reverting the cache from aosp to keep it correct,
and cherrypicking this into internal master.
Change-Id: I71757a5b60fbdba3c69322b95a20527a1e3a66e9
Introduce IWindowToken to report config/display changes from
server side. When config change callback is received,
it will update the resources associated with the window token.
Test: WindowContextTests
Bug: 128338354
Bug: 146820733
Change-Id: I871bd78a21dbde1286786e65c340b6259b873660
1) BiometricService / AuthService always need to be started, since on
Android 11 and later, the public credential auth API comes through this
path.
2) Consolidate getAuthenticatorId() and expose via AuthService. This is
used only by the platform during key generation. Instead of asking
each individual service, AuthService will return a list of IDs for
sensors which are enrolled and meet the required strength.
Test: atest com.android.server.biometrics
Test: fingerprint device, CtsVerifier biometric section
Test: face unlock device, CtsVerifier biometric section
Test: remove biometrics from device, CtsVerifier biometric section
Bug: 148419762
Bug: 149795050
Change-Id: I2c5385b1cd4f343fabb0010e1fe6fb1ea8283391
We use the package settings class as a central point for invalidating
on package information changes; for permission changes, we invalidate
from inside the individual permission data objects.
Bug: 140788621
Test: boots, package tests (pending)
Change-Id: Iec14d4ec872124e7ef4612c72d94c89a7319ace0
When security logging is enabled on org-owned profile devices,
Security events will be redacted to preserve privacy on the personal
profile as follows:
* TAG_ADB_SHELL_CMD
Shell command will be redacted.
* TAG_MEDIA_MOUNT
* TAG_MEDIA_UNMOUNT
The media's volume name will be redacted.
* TAG_APP_PROCESS_START
* TAG_CERT_AUTHORITY_INSTALLED
* TAG_CERT_AUTHORITY_REMOVED
* TAG_KEY_GENERATED
* TAG_KEY_IMPORT
* TAG_KEY_DESTRUCTION
* TAG_KEY_INTEGRITY_VIOLATION
Only events happening inside the managed profile will be returned
to the admin.
Bug: 148437300
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest FrameworksServicesTests:SecurityEventTest
Test: atest FrameworksCoreTests:EventLogTest
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingWithSingleUser
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingWithTwoUsers
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingEnabledLogged
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testSecurityLogging
Change-Id: I2e52229a3163b3e0dc3d80d71700023394d84587
Make obtaining a visual service from non-visual Context instance
report a strict mode violation and print the stacktrace.
Make calling getDisplay() throw an exception if called on an instance
that is not associated with a display. For existing usages introduce
a new internal method that does not perform the verification until
the usages are properly fixed.
Bug: 128338354
Test: StrictModeTest#testIncorrectContextUse_GetSystemService
Test: StrictModeTest#testIncorrectContextUse_GetDisplay
Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
- We previously assumed that icons set in the task description would be
loaded from the same package as the root activity (which is incorrect),
instead, they should be fetched from the activity which set them.
We also deprecate getIcon() because:
- apps could only get the icons they set previously (not very useful)
- it didn't return resource icons, only in memory or loaded from disk
- the name doesn't indicate that it could result in a disk load
Instead, callers (namely SysUI) should now call loadIcon() to get the
actual icon directly (or loaded if necessary).
Bug: 143363444
Test: atest TaskDescriptionTest
Test: atest ActivityManagerTest
Change-Id: I48aaba17de2edf0b3a61fa049cf897020d4c2ef1
