There are two separate issues here that need to be fixed, both
boil down to the fact that adding an imperative (userSetLocale)
to the Configuration is a bad idea. Because of this:
- We'd never persist the first user set configuration if it was en_US,
because of an erroneous call to Configuration.setLocale.
- ActivityManager.getConfiguration would sometimes return a
Configuration with userSetLocale == true, which means callers with
the right permissions would inadvertently persist a locale they didn't
want to persist.
bug: 18879010
(cherry picked from commit c63a16b8e46f2f3ecce6c548663cc3185f011fd6)
Change-Id: I4d714eb1f75afc0a5bf4d53a374df4ed16e328bf
toHex was changed to throw an exception in
I4986a8e806d9066129f696ab9f2e80655424e723, but its caller was not adjusted
accordingly, causing a crash whenever an unencrypted device was booted.
Bug: 18886749
Change-Id: If0505f617001cf5e0d99cf14c8b09e6a6a377167
Symptom:
Remain dead process record in mLruProcesses.
Root cause:
When a process dies and needs to restart immediately.
The process record will not be removed from mLruProcesses
in handleAppDiedLocked (return kept=true).
If the restarting process start timeout, the record in
mLruProcesses will not be removed.
Solution:
Call removeLruProcessLocked in processStartTimedOutLocked.
Change-Id: I1935ccc586016cb4e90dfdfac96cc88931553d5f
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
* We now require that all certs used to sign the apk and all
certs stored with policy be tested for set equality. Prior
efforts required that the cert included with policy only
needed to match one of the certs included with an apk.
* Allowed a new tag to be included with policy describing the
signatures. <cert signature=""/> is now allowed as a child
element of the <signer> tag describing multiple certs. The
old way of describing signatures attached as attributes to
the root signer tag is still supported. The engine now treats
it the same as if they used the new layout with the outer
signature as the first signature value.
* Moved the class which holds all policy from an inner static
to a builder pattern governed by the Policy.PolicyBuilder
class. This will help provide more clarity and allow for
easier enforcement of certain invariants as the policy
representation is being built.
* Loads of new comments.
Change-Id: I38eb00ed8962fdef71bc9f2e7370cb910cadeff4
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Symptom:
The ActivityRecord's waitingVisible is not set to false for
all cases when the ActivityRecord is removed from
mStackSupervisor.mWaitingVisibleActivities.
Solution:
Set the waitingVisible to false when it is removed from
mStackSupervisor.mWaitingVisibleActivities
Change-Id: If0f0683971d70a6866b0167e91dd95feebaac178
Copy region from DisplayContent.mTouchExcludeRegion instead of
directly refer to the same object of DisplayContent, and able to
protect it by lock of self class, don't have to lock out mWindowMap
on every tap.
This fix is to avoid racing condition of mTouchExcludeRegion.
Change-Id: I7401968167c2e539b4da2afe71e3020038fbfcbf
Signed-off-by: tingna_sung <tingna_sung@htc.com>
checkAllowNonWakeupDelayLocked() method determines that delay the dispatching of non-wakeup alarms.
(there are no wakeup alarms and the screen is off, it can delay until the future.)
if there is any pending non-wakeup alarms, non-wakeup alarm delivery time is bigger than nowELAPSED.
but, checkAllowNonWakeupDelayLocked() returns false and non-wakeup alarm is not delay until future.
i think it is necessary to reverse the inequality symbol on "mNextNonWakeupDeliveryTime > nowELAPSED"
if it isn't, Could you let me know when we get ¡°stuck in a loop¡± in the comment of checkAllowNonWakeupDelayLocked () method?
Change-Id: I7e972064547f4d0a9b4175dbd4cf735b4837abfd
Signed-off-by: Minho Choo <minho.choo@lge.com>
Symptom:
in .ActivityStack.resetTargetTaskIfNeededLocked, "allowTaskReparenting" if case will call setTask
to remove activities from task, that will caused numActivities in main for-loop not consist with task.mActivities size.
caused NPE will happend in finish activities for-loop due to get null object from activities when clearWhenTaskReset" as true case.
Root Cause:
when clearWhenTaskReset as true, will set "end" variable as numActivities -1, but if calling setTask to remove activities from task,
end value will out of date & not same with task.mActivities size.
Solution:
use activities.size() - 1 to assign end value.
Change-Id: I5d7fe22e1df2fc61738db23402e7c42cf6d8c4cc
Adjust format strings to not produce Clang warnings in both 32-bit and
64-bit builds
Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
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
Before the ActivityManagerService sends an intent or
starts an activity it checks if target user is in
mStartedUsers array.
When removing a non-owner user process the
UserStartedState instance will still be in mStartedUsers
array with mState STOPPING or SHUTDOWN.
This should be checked before sending an intent or start
an activity.
isUserRunningLocked(...) will interpret mState STOPPING
and SHUTDOWN as a non running user.
Change-Id: I1b51bcdb62bdd0f6dbe05dab4d529d4ad40d0d44
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
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
Captured screenshot bitmap is all black one if none of windows is
surface shown.
Change-Id: I651b2ade1865926d61f945167d60219535fa8bf8
Signed-off-by: tingna_sung <tingna_sung@htc.com>
Root Cause:
If a process which contains provider is starting but not
from accessing provider, e.g. service/activity/receiver,
its providers' will be created during handleBindApplication.
And before the process complete publish provider to
ActivityManagerService, if there is an access call to
process provider before the process completes publishing
providers to ActivityManagerService, then the providers
will be created again.
Solution:
Don't schedule install provider if the provider record
already exist and will be published later.
Change-Id: Ic200ceae042c014c86e7edee0acd013b513af334
Avoid pointer index out of range error if return value is -1 of
findPointerIndex() when there is no data available for that pointer
identifier.
Change-Id: I2a08f04c678164e220852094baa124ba157e2e42
Signed-off-by: tingna_sung <tingna_sung@htc.com>
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
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
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>
