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
Bug: 148155907
Bug: 135299581
Test: Covered by CTS
We plan to remove Bitmap#createGraphicBufferHandle. Call the new
Bitmap#getHardwareBuffer instead.
Change-Id: I0b3ada9636fcc00df82472ea9479eb0bfbcda9eb
Original commit:
[DexLoadReporter] Report classloader contexts directly from classloader
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Exempt-From-Owner-Approval: This is a pure re-revert, previously owner approved.
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I8d1af791f93a3f8fa6eca78df50891cd2ebbb4a3
Feature is disabled on non-FBE devices since the profile user will
end up in RUNNING_UNLOCKED state.
Bug: 143516540
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: manual
Change-Id: Ib87492577b4e5153a8108036af89c547e4bb76ee
If the admin has turned on always-on VPN, do not allow the user
to modify it. In order to distinguish between a user-initiated
always-on request and an admin-initiated one, DevicePolicyManager
needs to track what the admin has set, and provide getter to be
consumed by Settings code.
Bug: 137938969
Test: manually set always-on VPN and check Settings is disabled
Change-Id: Ief7454a2b66c487c23d06c2b4486a7107f8a385a
* changes:
Clear preferred activities affected by MIME groups changes
Implement new API to modify MIME groups by adding/removing MIME types
Add mimeGroup tag to intent filters
This change includes an AppOp that will be used to grant access to telephony call audio (RX and TX) to the default dialer application (assigned to the Dialer role).
A new permission was created so only apps that also require this permission will be granted. It will also be used to keep track of usage (audit).
Test: Compilation and manual verification
Bug: 135197853
Change-Id: I5d042f667ca5fe64f8048b8aff7b98f51b3c1500
Adds getThermalHeadroom, which allows users to determine how close the
device currently is to SEVERE thermal throttling. For intensive
applications which can scale their workloads, this allows them to help
manage the thermal envelope of the device.
Test: Manual, modify Filament test app to call and observe values
Test: PowerManagerTest#testGetThermalHeadroom
Test: atest android.os.cts.PowerManager_ThermalTest
Test: atest com.android.systemui.statusbar.phone.StatusBarTest
Test: atest CachedDeviceStateServiceTest
Test: atest AbstractAccessibilityServiceConnectionTest
Test: atest KeyEventDispatcherTest
Test: atest AttentionManagerServiceTest
Test: atest HdmiControlServiceTest
Test: atest ThermalManagerServiceTest
Test: atest RecoverySystemServiceTest
Bug: 136285293
Change-Id: I26e1c849c4b08cbf7ee0057f555cf0893750da43
