If an app sets an alarm and then cancels the underlying PendingIntent,
delivery will fail in such a way that the OnFinished callback is not
invoked. The Alarm Manager relies on that callback for managing
wakelock lifetime, however; this meant that the wakelock acquisition
would leak, burning down the battery.
We now detect these sorts of delivery failures and manage the
wakelock appropriately.
Bug 25864361
Change-Id: I74af48e81002b29b129c41a76c0a8329c647390d
Previously it would snap to the floor(progress) tick, which makes the
touch target size for the last tick 0px wide and difficult to touch.
Change-Id: Iac488d73e5a67c29b45f9bb4368db46c0028483e
The keypair is specified by alias and removed via a call to the
KeyChainService, which will have installed the pair in the first place.
Bug: 22541933
Change-Id: I37317e7c22e89816156e6e9a7abf4c5a59e8440a
Some tiles are statically not available on boot, etc.
based on hardware availability or settings, but most
are just always visible.
Change-Id: Ib1a45ef5b029fe710f9957cb997496dcb14f5875
Some work (mostly on the new QS only) to make things more like they
will be.
- Remove Quick Tiles
- Remove Dual Tiles
- All tiles are the same, with slightly different UI in the header
- QS tiles in the header match the beginning of QS
- handleClick is a click from QS, handleSecondaryClick is a click
from the header, but defaults to normal behavior.
- Opening a detail panel from the header opens QS and the detail
selected
- Fix onStartListening bug in CustomTile
- UI updates towards how QS will look
Change-Id: Id820586ccdaa258a5bcb72cadbeb14941fc5f935
This is useful when using the new AlarmManager direct callback
interface to wake up the system and request that an object whose
API consists of messages (such as a StateMachine) perform some
action.
In this situation, using AlarmManager.onAlarmListener by itself
will wake up the system to send the message, but does not
guarantee that the system will be awake until the target object
has processed it. This is because as soon as the onAlarmListener
sends the message and returns, the system is free to go to sleep
again.
Bug: 20157436
Bug: 25823676
Change-Id: Idff20029d287f26347441a2523b7fb20eda6a8b0
After previous change removed LOCAL_NO_STANDARD_LIBRARIES:=true
it is no longer necessary to explicitly add framework to
LOCAL_JAVA_LIBRARIES as it is added automatically by the build.
Change-Id: I68bf700375e34a10302f76d7463110755b815f85
updateRunningAccounts and dispatchSyncOperation is running in different thread,
and mActiveSyncContexts not synchronization.
If methods occur together,
mActiveSyncContexts change may occur when cycle is running.
Sample:
https://code.google.com/p/android/issues/detail?id=195341
Solution:
Offboard the traversal from the main thread to the handler thread.
Change-Id: Ifb9fbb466a5087186be31f7877c50b8c8b6737e4
Signed-off-by: wangzhengan <wangzglx@gmail.com>
The window will appear cutoff during the animation if the window was
cropped due to stack or decor bounds before the animation started. We
need to disable the cropping (both from decor and from stack bounds)
for the duration of the animation.
Unfortunately, by disabling cropping of a freeform window to the stack
bounds, we will make it appear above the docked window during the
animation (because the animation will lift the layer). To fix this, we
need to treat the docked stack like the pinned stack and assume it's
always on top for the layering purposes.
CL also includes refactoring of mSystemDecorRect and
mLastSystemDecorRect which can be moved from WindowState to
WindowStateAnimator and made private there.
Bug: 24913782
Change-Id: Idbea99ba04e9449d0563d0c02636f8b4b63087f7
Needed for apps that want to migrate SharedPreferences from CE to DE
storage. Note that a device will only ever enter a CE mode with a
factory reset, so apps should only be using these APIs when they
want to migrate files to a consistent location on non-FBE devices
for simplicity.
Bug: 25503089
Change-Id: Ic846215da1617d116a048e036415ac7ad523b770
The thumbnail header animations were constructed based on opening apps,
in this case Recents. This is obviously wrong, but used to work because
there was only one closing app in non-multi window world.
For the animation to work correctly, i.e. each thumbnail have its own
header animation, we need to correctly construct animations for either
opening apps or closing apps (depending on the transition type we are
seeing).
The CL also refactors handleAppTransition into smaller methods.
Bug: 24913782
Change-Id: I9f30a53d2f90f0628bb8c6238b2d0f35592b8f63
