Because ANR will dump cpu usage, stack traces in ActivityManager
thread, if system is busy or in low-end device, it may spend more
than 5s to dump. So when there is UI operation (e.g. pop dialog)
in ActivityManager thread, it may meet key dispatch timeout.
Change-Id: Ie550e31a7cff65bdcfc9af2c32989e9deb5fb2cf
Caller C accesses provider P. Both processes of C and P died
before P publishes, P will still be restarted even there is
no connection because P is in mLaunchingProviders.
When device is low memory, the restarting provider process
may be killed easily before publish because no caller to raise
its oom-adj. Then device will busy keeping restart it.
Solution:
If there is no connection to the provider, do not restart it.
Change-Id: If6f2d2258d78b6c0989c6e5f3e0cad14db821464
fix return value scale of notifyANR()
from milliseconds to nanoseconds when windowState is not null
This prevent unintended frequent method calls of notifyANR()
in a very short time.
Change-Id: Icc1f363b3ed3538821a42c080809567473bfb833
Signed-off-by: Baik Han <baik.han@lge.com>
Sample code, symptom video and detail:
http://code.google.com/p/android/issues/detail?id=87909
If device is sleeping, activity will be paused immediately
after resume, it is unnecessary to force complete it.
Otherwise the state may get worse because mPausingActivity
is cleared, the real pausing from activityPausedLocked won't
be able to complete pause flow (PAUSING to PAUSED).
If the fail-to-pause activity called finish, it will also
cannot complete finish flow because only !PAUSING can do it.
This results in an activity that has visible=true, finishing=true,
state=PAUSING and always show on wallpaper.
Issue flow:
Case 1
1.At home stack and screen off.
2.A task T contains one activity Z and its process was died.
3.Launch new activity X on T.
4.Before activity Z complete resume, any process
bound and died trigger update visibility and resume top.
5.X calls finish.
6.Turn on screen, X will be always visible.
Case 2
1.Launch Settings (or any), press home key.
2.Launch an activity X in Task T, press home key.
3.Kill process of activity X, turn off screen.
4.Launch activity X with NEW_TASK | CLEAR_TASK.
5.Activity X calls finish.
6.Turn on screen, X will be always visible.
Change-Id: I8ca1845fd100e13ec58382c8c0105bf0a9f8137d
Fine tune commit 9ac9609f.
Because process may reuse same process record to restart.
It is better to check below conditions to skip:
1. Simple dead and has been cleaned.
=> .thread will be null
2.The process has restarted with new pid but has not attached yet.
=> .thread will be null
3.The process has restarted and attached.
=> The IBinder will be different
Change-Id: Ic052f5025558ca93e1a6ab11bca61fe995126bb9
Imposing an order on Policy objects allows us to extend the
policy writers ability to union mac_permissions.xml files.
Policy developers can now create new mac_permissions.xml
entries under their device specific directories. This is
in contrast to current methods which only allow differing
stanzas to appear outside the base mac_permissions.xml.
Also, report on stanzas with duplicate input selectors and
treat these as errors. There are some ambiguities that can
arise otherwise.
Lastly, impose an XOR condition on signer stanzas w.r.t seinfo
and package tags. This finer distinction helps the union feature
of policy to become clearer and simpler to code.
Change-Id: Idd86df8ad9a63d1b8ba6e8270670814ca6cee8d2
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
This change adds new method overloads to provide volume UUID. The
older methods remain for now, and pass through the "null" UUID to
reference internal storage.
Follows the existing pattern where null arguments are passed as "!".
Bug: 19993667
Change-Id: Ia1b7c8550cabc13e4f6e1182eabb650f2c33e44f
The original logic lets windows be able to freeze screen again (by
setting win.mOrientationChanging=true) after WINDOW_FREEZE_TIMEOUT is
triggered before mInnerFields.mOrientationChangeComplete is set to
true. In this case, we would lose the protection of
WINDOW_FREEZE_TIMEOUT. If the app never finishes drawing the window,
the screen would keep freezing that the user cannot operate the
device.
Change-Id: I45a0a9e4b3f8d5b0b0043229bfa4890236ae8ab2
Symptom:
In some scenario, the mPausingActivity may be replaced by other
activity. When previous activity paused, the completePausedLocked()
won't be invoked because it is no longer the mPausingActivity. If
the activity is also pending to finish, it would never be done
because the activity kept in PAUSING state. Since the activity's
window also remain visible and is above on Wallpaper, user would
see it when back to home.
Solution:
Finish the failed-to-pause activity if the activity is pending to
finish.
A Real Case:
(1) Screen turn off
(2) The top activity T1 crashed
(3) When finish activity T1, the next top activity T2 will be
scheduled to resume and pause (due to screen off).
(4) The activity T2 is also set to finishing due to T1 crashed.
(5) Before T2 paused and before paused timeout occurs, there has
a new process started which brings up the next top activity T3
to resume and pause. So the pausing activity is now replaced.
(6) When activity T2 paused, it cannot completed the pause operation
T2 will remain in PAUSING and finishing state with its window
visible. The process won't be killed because the oomadj stays
at 1 (Visible).
Change-Id: Ib10fded891b21c774b26a93071c717fa50516e22
When an activity stops drawing following a rotation the rotation
screenshot would become stuck on top of all the other windows. The
timeout was being acknowledged but mWindowsFreezingScreen was set to
true which kept stopFreezingDisplayLocked() from dismissing the
screen rotation animation.
By changing mWindowsFreezingScreen from a two state variable to a
three state variable, including a timeout state we allow
stopFreezingDisplayLocked() to continue and dismiss the screen
rotation animtion.
This change also reduces the APP_FREEZING_TIMOEOUT from 5 seconds to
2 seconds.
Bug: 15664090
Change-Id: Ida5aca002a82ec8fe1ea99f0ced814c5c8f01a95
Symptom:
During switching task in same stack, the first result
of getRunningTasks will be the behind stack's top task.
e.g.
App Task X is starting task Y, the first entry may be home.
Root Cause:
TaskRecord's lastActiveTime is updated when pausing
or resuming. When X task launch a new task Y, Y is
on the top of task history, before X complete pause,
Y's lastActiveTime will be 0 because it is a new task.
Then when comparing the front task with other stack,
other stack will be regarded as the newer one.
Solution:
If the stack is focused stack, give the top task with the last time.
Change-Id: I0adc07608e03d333e0120a0dbc52a0fbbbb12f34
When a new package is created, installNewPackageLI does not need to call
dexopt, since it has already been made.
Bug: 19550105
Bug: 20087446
Change-Id: If6b05bea590eea5f95efebb22a67ccd8cdf632c2
