We still retain the data in the backup, in order to support the flow
in which a user has the app and its data is stored; then the app
is uninstalled; then later the app is reinstalled. We depend on
having correct metadata for the data in the datastore in order to
evaluate its validity for restore-at-install, so we mustn't
forget that metadata just because the app is not currently
installed.
We also now permit the sentinel pseudopackage name "@pm@" as an
argument to dataChanged(), indicating specifically that the metadata
should be scheduled for backup without having to be piggybacked on
another app's requested backup pass. That lets us now make sure to
schedule a backup pass for metadata-update in response to app
install activity.
Finally, fix a "min instead of max" bug in full backup scheduling
that was causing the OS to ignore the transport's inter-package
quiet time requirement when multiple packages were overdue for
backup.
Bug 21471973
Change-Id: I1dbc260edb91b8deadd2744e273dfa9578b9ef2a
When bouncer was showing, but keyguard was occluded, staus bar
window couldn't receive input, and thus the IME window was placed
below the status bar window. In addition to that, fix the layout when
IME is showing up on the bouncer screen.
Bug: 19969474
Change-Id: I38d21647801b57608d49c3f525d4840e6ba58296
- Track the calendar provider for the managed profile user if found.
- Add userId to the shared data structure to disambig calendar ids.
- Delay rule update a bit to guard against chatty updates.
- Fix logging in calendar rule.
Bug: 21155107
Change-Id: Id2303fcc39b1fa7417b1844b7869d773ef92434c
- Specify the package name. This provides a bit of security, but
not much since the package is "android".
- Specify the interface name so we can run more than one client
at a time.
Bug: 21395858
Bug: 19704592
Change-Id: I91c9ea15285b36628b6aef0b975c16a0b08d061e
It is possible for us to leak an app starting window if the app it
is associated with fails to start before adding any windows. This
causes the starting window to permanently be visible at the layer
it occupies.
We now remove the starting window immediately when the app token
is been removed if it is the last window in the token and it isn't
animating.
Bug: 21375344
Change-Id: Ib3da148501645a44736c639c0181c3fabe0138e8
Ensure any active voice interaction session is canceled when the
voice interaction service is shutdown. This ensures that the UI window
is closed when a user switches accounts.
Bug: 20501283
Change-Id: I9f3dae5afc4048482f6bedaed36dbae3c0823ebd
Bluetooth was being queried too often, leading to more power
consumption and wakelock time.
Bug:21063567
Bug:21269307
Change-Id: Idddbab46d13016ef8528e095945b7817c12f7266
This adds a new ActivityOption for the caller to ask the
system to track the time the user is in the app it launches,
delivering the result when they are done.
The time interval tracked is from when the app launches the
activity until the user leaves that app's flow. They are
considered to stay in the flow as long as new activities
are being launched or returned to from the original flow,
even if they cross package or task boundaries. For example,
if the originator starts an activity to view an image, and
while there the user selects to share, which launches gmail
in a new task, and they complete the share, the time during
that entire operation will be included.
The user is considered to complete the operation once they
switch to another activity that is not part of the tracked
flow. For example, use the notification shade, launcher, or
recents to launch or switch to another app. Simply going
in to these navigation elements does not break the flow
(although the launcher and recents stops time tracking of
the session), it is the act of going somewhere else that
completes the tracking.
The data is delivered to the app through a PendingIntent,
which includes the total time the app was in the flow along
with a time break-down by app package.
Change-Id: If1cf8892d422c52ec5042eba0e15a8e7e8f83abf
Previously getHomeActivity() returned the topmost home activity
independent of which user was currently running. That defeated the
purpose of the method. This fix returns the home activity of the
current user or null if one has not yet been created.
Also remove some cruft that accumulated.
Fixes bug 21055376.
Change-Id: Ic1d58129aedbe3624f8a9d12c05c84674687b0a4
If there was a window with FLAG_DISMISS_KEYGUARD first, when the
device was unlocked, mWinDismissingKeyguard was set to that window.
Now, a window with FLAG_SHOW_WHEN_LOCKED came on top, so we set the
Keyguard as occluded, but we didn't reset the window that is
dismissing Keyguard.
After that, the old window with FLAG_DISMISS_KEYGUARD was the focused
window again. However, since we didn't reset mWinDismissingKeyguard,
we ended up with DISMISS_KEYGUARD_CONTINUE, and lockscreen was not
occluded anymore. However, we never really told Keyguard about it
because DISMISS_KEYGUARD_CONTINUE was set instead of
DISMISS_KEYGUARD_START.
The first fix of this bug is to always tell Keyguard about the
current occluded state. The second fix is to reset
mWinDismissingKeyguard in case a window SHOW_WHEN_LOCKED comes on top.
Bug: 20102975
Change-Id: I7c778df09a1e393b9eeaf51fd2013012cb40fea9
