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
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
