The TaskRecord intent (usually the intent of the root activity) component
names are based on the realActivity (the activity we are actually launching
and not the input alias) and the ActivityRecord intent is based on the input
component name which can be an alias. This leads to issues when we are trying
to compare the intent of a task and an activity to see if they resolve to
the same thing since the component names will be different in the case of
aliasing.
We know base the activity intent component name on the realActivity before
comparing with the task record intent.
Bug: 27403679
Bug: 27112965
Change-Id: I196e03bb018582cbac977fb3ad45354f00f51578
...isUserAMonkey for testing purpose
Add an argument for the caller to specify if they are a poo flinging
monkey.
Change-Id: I0e149a8d78776abaf07517bd4ae886047b7f4252
Preference allows override of AudioPolicyManager.
Lets user force or prevent use of AC3 and DTS regardless
of what the EDID says.
Bug: 26373761
Change-Id: I21440f2b90af9a369a36b7b07724e992501bce6d
Signed-off-by: Phil Burk <philburk@google.com>
We don't have a vold connection early in the PackageManagerService
constructor, so we can only migrate the system user at boot. We now
migrate other users only after they're explicitly unlocked by
UserManagerService.
Bug: 27330415
Change-Id: I29f21714acf65a598b8df496af0f7d2cb1d247c4
The Keystore should be unlocked by the work challenge when
the work profile has its own lock, and should not be unlocked
by the device lock in this case.
Tested use cases:
When unified, both users have the password key set to the parent's
Setting a work challenge changes the work profile's password key to its
own
Unifying causes the work challenge key to be set to null first and then
when the device password is reset right after that it is reset to the
same as the parent
Unlocking when locks are unified unlocks both using the same password
key
Unlocking the device when not unified only unlocks the parent
Unlocking the work challenge only unlocks the work profile
Bug:26817206
Change-Id: I99dca279687f4f77636992e355dbdb607bbf7b6d
Similar to first patch, but now using new "rethrowFromSystemServer()"
method which internally translates DeadObjectException into
DeadSystemException. New logic over in Log.printlns() now
suppresses the DeadSystemException stack traces, since they're
misleading and just added pressure to the precious log buffer space.
Add some extra RuntimeInit checks to suppress logging-about-logging
when the system server is dead.
Bug: 27364859
Change-Id: I05316b3e8e42416b30a56a76c09cd3113a018123
There was a period of interim deployments during which sync-manager jobs
were not properly attributed to the package whose sync operations were
being driven. This situation is now corrected when it is encountered.
Bug 27335118
Change-Id: Iafc40c80093499447b2e62a4888e3ece0371bfcb
The registered shortcut will be called from PhoneWindowManager,
before dispatching
Change-Id: If26128939b45a639c8895719a7a23ca433f39fd9
(cherry picked from commit 4da863c5a8872dcabb179a978a2b2157d9081679)
System config can defined apps to be automatically whitelisted for
restricted background data, but the user can remove the whitelist.
Implementation-wise, NPMS now keeps a list of
<revoked-restrict-background> UIDs in the netpolicy.xml file, and when
it starts it compares the UIDs returned by SystemConfig against this
list, and only whitelist them if they are not revoked. The
revoked-restrict-background is then updated as users change the
whitelist status of UIDs.
BUG: 27366993
Change-Id: I427024fd058924fc9831e409da6636e1bf8e4219
Support querying the AudioDeviceInfo in AudioRecordConfiguration.
When AudioService (through RecordingActivityMonitor) receives
a recording event on an existing session, report it as an
update if the recording configuration has changed.
Bug 22876530
Change-Id: I1b72c08aa0589077fe8ad254087965e6384ce50a
It is possible the add starting window to be scheduled and a remove request
come in before it is actually added. In this case we want to prevent the
addition of the starting window by clearing the AppWindowToken.startingData.
Bug: 26659857
Change-Id: I3ef6ea81d555e81b62e894003aadcc51d281b1ad
Also fix bug that was failing to remember the lock-only wallpaper, and
along the way make the disk write a single large block operation instead
of a number of small writes.
Bug 27353079
Change-Id: Ib1351e509af95905dced41e69c6e13dcce839511
We'll keep them around in the pending queue until the user is
unlocked, at which point we'll consider running them.
Bug: 27358148
Change-Id: I2eb538a89206d4caac620b3b4e989b011b309201
Encapsulating the logic to toggle multiwindow mode from recents,
and plumbing it through to accessibility global actions. Sending
accessibility events when windows bounds change. Exposing the
dock divider window type to accessibility services.
Bug: 27250995
Change-Id: Ib7491f1f853dc7f01bf5c5a4ac1f914f55d0608a
