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
Removed sentence in visible javadoc of #PhoneStateListener() which
was useless because it referred to another hidden constructor.
Change-Id: I14a956ac29881000e48bf31e0090e9e1f93bf6e3
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>
- allow Media.Image.setCropRect(null) to unset cropRect
- use full image if cropRect is null in MediaCodec$Image
Bug: 18124320
Change-Id: I7abb6175402a1fe913e16c0a682fabee79c55741
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
