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>
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
Upon crash of com.android.phone process, NetworkFactoryInfo is
not getting removed from HashMap and will get accumulated on
every start of the process.
Change-Id: Iafde28daddfc82728c03208522682b1efc85a121
In some cases it is possible for the AppToken.allAppWindows list to
get out of sync with the list of windows known to WMS if the client
doesn't call Session.remove(Window). This can lead to an NPE when
the animation threads runs and the display for the window has been
removed.
Bug: 19972099
Change-Id: Ifdf9ff2364b96757bba0539394c4a682f64577c9
