Other threads may change mOpModeWatchers, mPackageModeWatchers
by startWatchingMode, stopWatchingMode.
Change-Id: Id260172979ddfc2df9331880805d16ee13e183eb
If an L device has a privileged app on the system image which was
updated and an M OTA renames the app package (supported only for
privileged apps) we end up with a disabled system package setting
with no package information. Since we are not doing a null check
of the package we get from the disabled package settings during
default grants we crash leaving the system in a bad state.
bug:25687380
Change-Id: I4f2ebcaf471e4bd1696298eab4716b50c52ca5c4
Apparently OEMs can set the chooser so this patch is not enough since it assumes the chooser is a platform component.
This reverts commit fce33d58d8.
Change-Id: I3b8e499d2f0a731a227d193f6c5d6ed528be2272
Symptom:
NullPointerException crash while call startNextMatchingActivity.
Root Cause:
Activity starts with FLAG_DEBUG_LOG_RESOLUTION for debug dump.
If the current Activity is the last object of resolves list,
we can not get the next Activity and aInfo is still null.
Solution:
Check null in debug log dump.
Change-Id: I4c5d14d9acd8d47768b36c95354763841579e050
Use the correct API to query activities when granting
default permissions to ensure the preferred apps are
taken into account. This allows OEMs to customize which
app should get default permission grants if there is
more than one resolving to the query intent.
Change-Id: I047f22dfff773a2ba9de1a0144442e372607777c
Symptom:
The stack was deleted during cleanup, so the stack
list size has reduced by one and cause this issue.
IndexOutOfBoundsException: Invalid index 1, size is 1
Change-Id: Ic6722aed98a0ad789b331d00e89cb74bf3b36d4c
If there are 2 activties launched during screen off.
Both of them will be scheduled to pause immediately.
But if the first one does not complete pause in time,
and the second one is a non-fullscreen activity, the
first one will still be visible and no need to stop.
After the second one complete pause, mPausingActivity
is cleared, then the first one's complete pause is failed
and keep state at pausing. If it calls finish, it cannot
be destroyed because its state is pausing so expect it will
be paused later, but actually is has complete paused.
Sample and video:
https://code.google.com/p/android/issues/detail?id=190955
Solution:
A failed-to-pause activity should still change state to paused
if it is pausing. Then when the first activity calls finish,
it will satisfy the condition in ActivityStack.finishActivityLocked
"r.state != ActivityState.PAUSING" to continue the finish flow.
Change-Id: I2f211ddf5039b332b0c7d01ccd043aa18fe168f7
There are 4 components that all implement package parsing, they are:
1. sdcardd
2. libselinux
3. logd
4. runas
Create a library that can be used by all of them, and new ones as needed.
Change-Id: I87a406802f95d8e7bfd8ee85f723f80e9e6b6c0c
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Allow privileged apps to run in their own priv_app domain.
Motivation:
Untrusted_app is overprivileged due to the inclusion of privileged
apps like gmscore, play store and finsky. Moving these and other
privileged apps to their own domain reduces the permissions required
by untrusted_app.
A separate priv_app domain also protects priv-apps by further
isolating them from third party apps.
Bug: 22033466
Change-Id: I8e6ae5677c5a978301c453d0aa51ebed4459f5a0
Not to resume home activity in finishing stage as following case:
When only home task has 2 activities,
(ex: SetupWizard & DeviceOwnerProvisioningActivity),
If SetupWizard crashed during DeviceOwnerProvisioningActivity in
finishing stage,
makes DeviceOwnerProvisioningActivity cannot destroy immediately,
In resumeHomeStackTask, will resume DeviceOwnerProvisioningActivity
(returned by getHomeActivity),
But actually, DeviceOwnerProvisioningActivity cannot be resumed.
Caused ANR when back key since no more running activity can resume.
Change-Id: Icec49e092d2e7bee7f6a2d198913c1c5db7122f2
Fix a race condition where the wait index can be incremented inbetween
the while() loop and the lock
Fix when updateOrientation() is called: after the sleep, otherwise
the last sleep is useless.
Bug 24677424
Change-Id: I03770a0fc8af57f4696ebee7e9c9110e17c55a24
The logging of saved time was erroneously being called more than once
per wake period. Moved the logging logic to be called from
finishWakefulnessChange(), which is only called once per wake period.
Change-Id: I268ef44edce5807644fcc8fb0dcaa1a96cae6c9e
Processing ZenModeHelper.setConfig() synchronously in
ZenModeConditions.onConditionChanged() can cause a cross deadlock between
ConditionProviders.mMutex and AudioService.mSettingsLock.
Add a method to set Zen mode config asynchronously.
Bug: 24528290.
Change-Id: I9c1701ca6bef084527821175d84002b612241995
For devices that monitor orientation (primarily for channel assignment
to stereo speakers):
The com.android.server.policy.WindowOrientationListener API is more
power efficient than simply monitoring the device's orientation. When
supported, use it instead of android.view.OrientationEventListener.
When WindowOrientationListener reports an orientation change, start
a thread to poll the UI orientation, as its change may lag behind
the observed rotation. Gradually increasing delays between polls
are stored in a table.
Bug 24415763
Change-Id: I69bf68da6107af24cd02a48961dd17ceab557816
Send a POWER_HINT_INTERACTION to improve redraw performance when the
phone is rotated.
bug 24583227
Change-Id: I1978f0dfb9a25c00ad4da5b44d10410ad7412001
Use the lock to prevent other threads clearing mInputMethodTarget
while we are accessing members of mInputMethodTarget, or it will
cause system server crash due to unexpected NullPointerException.
Change-Id: Iec3bed916a019827364ddaf63a89270a4c407a47
