All below cases should return to home but the top will be Settings.
The initial steps are
1.Launch Settings from home
2.Press home key
3.Launch activity A in task X from home
Case 1
4.A starts activity B in task Y and calls moveTaskToBack
Case 2
4.A starts activity B in task X and calls moveTaskToBack
5.B calls finish
Case 3
4.A launches activity B in task Y
5.B launches A with NEW_TASK (bring existed task)
6.A calls finish return to B
7.B calls finish
Case 4
4.A launches activity B in task X
5.B launches C in task X
6.C launches A with flag NEW_TASK and CLEAR_TOP
7.A calls finish
Solution:
Transfer return-to to next adjacent task.
Change-Id: Icdad980eec64e081d15679600da07cf4431e40d6
* 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>
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
