An instance of ResourceKey may correspond to different instances
of Resources at different points in time. This can lead to old
instances of Display returned from cache even if resources have
changed.
We need to ensure 1:1 correspondence between Resources and
ResourceKey before using this kind of cache. Disabling it for now
to fix CTS.
Change-Id: Ib53550c4f2d969c06a570ab6051529269b04b38d
Fixes: 37328072
Fixes: 37305567
Bug: 33430498
Test: android.server.cts.ActivityManagerAppConfigurationTests
Test: android.app.cts.DisplayTest#testRotation
Now it's possible to listen to changes on wallpaper colors by
registering a listener on WallpaperManager. It's also possible
to get the current wallpaper text color hints.
Bug: 36856508
Test: compilation
Change-Id: I5102cb7be9a4af60b85fc8913154a79dfe5c21a0
This allows any service to interact with JobScheduler, which
should give us a lot more opportunity to do interesting stuff
in the support lib.
Test: bit CtsJobSchedulerTestCases
Change-Id: I0843e8b212a0a63a17558b837b899b90cac22805
This api will return the timestamp at which this activity start was last
initiated by the system. Implementation is wip.
Bug: 9058261
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases -t \
android.app.cts.ActivityStartTimeTest
Change-Id: I396458ecefbb09108f414b95f9c0beb6d609a4e1
This is just an internal API in the platform, not (yet?) available
in the SDK. But it will be useful for system services that want to
clean up state if a pending intent that has been registered with them
is canceled (either explicitly by the app, through the app being
uninstalled, etc).
Also improve the activity manager's dump of pending intents to
organize them by package, making it much easier to read (now that
we have so many active pending intents these days).
Test: ran and booted. no CTS, since no API.
Change-Id: Iad029cfedcd77e87357eca7da1b6ae94451dd981
This better accomodates those apps that play their own sounds.
Since most apps don't play their own sounds, update the documentation
on notificationchannel to add guidance about when they should add a
sound.
Fixes: 37237013
Test: runtest systemui-notification
Change-Id: If00b15b1b44da66d24dacb2895e9a6c0a06d1890
We now have a software feature for autofill which can be used
by partners to disable it on low-end devices or form factors
for which autofill doesn't make sense.
bug:35956220
Test: manual (requires a custom build)
Change-Id: I6c06462ed9ca3ae93331700dce38a8c08dfd0722
Effectively reverting 89927b3cd9, which
allowed direct-boot aware activities in the work profile to show before
the profile was unlocked. This causes problems with key eviction
introduced in O. Specifically, many system activities (e.g.
ChooserActivity, activities in Settings, etc.) are marked direct-boot
aware, and therefore can be started while the work profile is locked
with key evicted. Currently they either bypass the keyguard when they
should not, or simply crash due to profile still being locked.
In the future, we need to create a new mechanism to allow activities
such as video calls, alarm clocks, etc. to bypass the work keyguard. It
probably involves checking for something like FLAG_SHOW_WHEN_LOCKED.
Bug: 36961785
Bug: 35708183
Bug: 30296144
Test: manual, by following the steps in the bugs quoted
Test: runtest -c com.android.server.am.ActivityManagerServiceTest frameworks-services
Change-Id: I5ccaaf963f3dd96e4abb785a10aa258b15363178
Bug: 37197930
Test: runtest -x cts/tests/app/src/android/app/cts/FragmentReceiveResultTest.java
This verified existing startActivity* public APIs are still working
Test: The new hidden API is used/verified by the CLs under the same topic.
Change-Id: I2aca2823ecf26dc8a9318b3783b6041796c02582
This gives semantics similar to the start command
queue of services.
The implementation is currently lacking in URI permission
grant handling of the work intents; that will be coming
in a follow-up change.
This includes a first step of adjusting/fixing locking
within JobSchedulerService. The JobServiceContext class
has a bunch of stuff it does that assumes it doesn't need
locking because it schedules the work on a handler. However,
to be able to correctly implement the work finish flow (that
takes care of stopping the job when there is no more work),
we can't dispatch these asynchronously so need to get rid of
that and just do explicit locking.
The switch to explicit locking is half-way there (again the
remaining part will be a follow-on CL). Right now we have
the locking, but still also the handler. But it turns out
there were a number of things we were doing without a lock
held where we actually should have been holding a lock, so
this is better anyway.
Test: new tests added
Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03
- Callbacks when channels and groups are modified
- Allow them to read and update channels and groups
Test: runtest systemui-notification
Change-Id: Ie4d02bd4583f71f9faf27603bcc59a1ec0eeaf46
When an app calls setTaskDescription it overrides the hidden
attributes derived from the theme. Make sure to not override these
if they aren't set in the new task description.
Test: Open Maps, go home, rotate, open maps again, make sure
navigation bar is black
Bug: 36703868
Change-Id: If3f8948fe81af324411c2e828834f5d81e3eeddd
This reverts commit ba53d8ae41.
Also fixes that we always had a size mismatch.
Test: TaskSnapshotSurfaceTest
Test: Open app in different orientation than snapshot, make sure
looks ok.
Bug: 36991071
Change-Id: If572b68fd72cec7679984fdff0be5905caba69f4
Fixes: 36703868
When the system Application object is created, it should be shared by
both system and system UI context.
Bug: 37111478
Test: - Open settings
Test: - adb shell am crash com.android.settings
Test: - with crash dialog open, press volume keys
Test: - observe no crash
Change-Id: I2b4656680d25fe61fee69c01ee10522aac4e2942
1. ActivityConfigCallback might not have been registered
because DecorView was not yet attached to window and ViewRootImpl
was not available. In this CL the callback is set as soon as a
DecorView is attached to window.
2. When private display was removed from system, its stacks were
moved to bottom in AM but moved to top in WM.
3. When reparenting stack visibility of activities should be updated
before reparenting in WM, because otherwise WM will be resizing
windows that should no longer visible and reporting it to clients.
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Test: #testContentDestroyOnDisplayRemoved
Change-Id: I6ccc27d873d0d60d7650659fb25cbfcaaeb0fd07
