Since we were unloading tasks when the activity was stopped, but only reloading
tasks on the next onCreate()/onNewIntent(), there were cases where the system
would create the activity but then immediately stop and start it (ie. when the
screen is turned off while the activity has resumeWhilePausing=True set in its
manifest). This CL ensures that we reload the tasks with the same state used
the last time the Recents activity was started.
The CL also cleans up some visibility state that was confusing and is no longer
necessary, fixes a small issue with the dismiss button flashing when toggling
Recents quickly, and fixes some cases where the initial stack scroll is set
incorrectly.
+ Calling activity which calls provisioning app only if provisioning
is needed.
+ Hiding Hotspot tile from quick settings when screen is locked.
Bug: 18368949
Change-Id: I5b92a7f2d46c8b5d9b323d6a5d49315694c599f7
Symptom:
The task thumbnail is not updated when activity relaunched.
Reproduce Steps:
1. Put device in portrait
2. Launch Calculator
3. Launch Recent App (the Calculator's screenshot is correct)
4. Rotate device to landscape
5. Click Calculator in Recent App to return to Calculator (Calculator has relaunched to landsacpe ui)
6. Launch Recent App again (the Calculator's screenshot is not updated)
Change-Id: I92e951ea2ee215c52ca6e50cf6f9e02deb787bce
In case, process doesn't create well while startingProcessLocked().
There is possibility to make NPE.
Setting app's crash handler needs to be assigned after null check routine.
Change-Id: I67fb6427f72d93f79fed36eb44c47d37eafdac31
Symptom:
There has a race condition that two threads are accessing
the mPendingPssProcesses simultaneously. One of the thread
is collecting the process pss by looping the mPendingPssProcesses.
The other thread is requesting to collect pss of all processes,
which clears mPendingPssProcesses and adding processes back.
Solution:
Avoid race condition by adding synchornized protection.
Change-Id: Ifb090eda9c4a1b8e3fd980fe0171e9dd77773b46
Cherry picked from aosp.
Fixes bug 18593309.
ActivityManager reuses a process record object that killed
by him under some situation. That reused process record inherits
a killedByAm flag unexpectedly.
The killedByAm flag must be reset otherwise ActivityManager can't
judge the process can be killed or not.
Change-Id: If95137d91939cc44882ad2813131bcde0edd0c1b
Since the game randomly flips horizontally anyway, forcing
the game view to LTR fixes the coordinate math without
affecting gameplay. (The score view did need to move to
start instead of left, however.)
Bug: 18628150
Change-Id: I7cf8bd1e2b9a2316d30e17a9251173598c687c2b
Cherry picked from aosp.
Fixes bug 18593457.
Symptom:
NPE occurs in line 1184 (resultStack.sendActivityResultLocked)
because resultStack is null.
Root cause:
When starting activity with FLAG_ACTIVITY_FORWARD_RESULT flag,
the resultRecord could be updated, but the resultStack is not
updated as well. In that case, the resultStack is still be
null. The exception will occurs if the activity is not
granted to launch due to permission denied.
Solution:
Update resultStack when resultRecord updates.
Change-Id: I91634e4f713c2e8dbd1a71f358a8fd9beed83ec7
Previously we were failing to update references to drawables that had
been pulled from constant state, so we were drawing the wrong ones.
Also fixes button Z translation on press, which was WAY too high.
BUG: 18542282
Change-Id: Ifde7d64e31d31737854cfcbe75777e5b07a06e3a
Pulled from aosp.
Fixes bug 18593454.
Two broadcasts could be sent to the same app simultaneously:
one foreground, one background. For example, LOCALE_CHANGED
and PACKAGE_CHANGED are delievered to com.android.vending
at the same time.
1. AMS started new vending process to handle LOCALE_CHANGED.
And set app.curReceiver = LOCALE_CHANGED.
2. Before LOCALE_CHANGED is handled by vending process,
PACKAGE_CHANGED was delievered to vending process too.
AMS set app.curReceiver = PACKAGE_CHANGED. Bad!
3. Vending process finished handling LOCALE_CHANGED.
AMS clear app.curReceiver = NULL. Bad!
And Vending process killed itself without handling
PACKAGE_CHANGED.
4. AMS known vending process has died, but didn't know that
BgBroadcastQueue was still waiting for finish message
for PACKAGE_CHANGED.
At last, BgBroadcastQueue reported ANR for PACKAGE_CHANGED.
This patch adds protection before clearing app.curReceiver,
only set to NULL if the finishing receiver = app.curReceiver
So handleAppDied would know that PACKAGE_CHANGED was not
finished yet, it will abort the broadcast and continue.
Change-Id: Ic4f31b35e21823d4a3c27712391ecbede213a494
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
Cherry-picked from aosp
Fixes bug 18613138.
If the process of a BroacastReceiver is dying at the same time
as the system is trying to send an ordered broadcast to the
receiver, the system will try to start the process again. The
BroadcastQueue will store the BroadcastRecord in mPendingBroadcast
to be able to handle it again when the process is awake. A
timeout Message is posted to the handler of the BroadcastQueue.
As part of the shutdown sequence skipCurrentReceiver is called for
the ProcessRecord. This will check if there is a curReceiver set
for the application and make sure to finish the receiver.
Each of the foreground and background BroadcastQueues have their
own handler for managing broadcast timeouts. If the wrong
BroadcastQueue finishes the receiver, the pending timeout Message
will never be cancelled, leading to an ANR report for a receiver
that has already been finished.
Change-Id: I960c0d8f1a8b739b54a8f09f496b32a3498b9e9a
