- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
* changes:
Fix bug 2129190 The context used by the status bar (i.e., the system context) was not properly initialized to have the right ApplicationInfo inside its PackageInfo. This eventually caused it to believe that it was running at 160dpi.
The context used by the status bar (i.e., the system context) was
not properly initialized to have the right ApplicationInfo inside
its PackageInfo. This eventually caused it to believe that it
was running at 160dpi.
Kudos to Dianne for figuring this out.
* We now check for in-progress backups when asked to perform one, and don't
bother firing off another one concurrently (nor do we adjust the scheduling;
after all, someone asked to do a backup "now" and we're doing one, so we are
in line with expectations). We also defer backup passes while a restore is
in flight, and abort attempts to perform a restore during a backup pass.
* When a backup attempt fails, we now ask the transport how far in the future we
should put our retry. Previously we were simply not bothering to consult with
the transport, so we would wind up retrying backup while network connectivity
was known to be down, etc.
Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90
Turning off backup in the Settings UI constitutes an opt-out of the whole
mechanism. For privacy reasons we instruct the backend to wipe all of the data
belonging to this device when the user does this. If the attempt fails it is
rescheduled in the future based on the transport's requestBackupTime()
suggestion. If network connectivity changes prompt the transport to indicate a
backup pass is appropriate "now," any pending init operation is processed before
the backup schedule is resumed.
The broadcasts used internally to the backup manager are now fully protected;
third party apps can neither send nor receive them.
(Also a minor logging change; don't log 'appropriate' EOF encountered during
parsing of a backup data stream.)
Lot of infrastructure for more things to go away when "clear system dialogs"
happens, and now do this when we turn on the lock screen.
Change-Id: I567130296fe47ce82df065ed58ef21b37416ceaf
- New meta-data you can add to a dock activity to have it launched by the
home key when the device is in that dock.
- Fix a deadlock involving ActivityThread's internal content provider lock.
- New window flag to have a non-secure keyguard entirely dismissed when a
window is displayed.
- New WindowManagerPolicy APIs to allow the policy to tell the system when
a change it makes during layout may cause the wall paper or
overall configuration to change.
- Fix a bug where an application token removed while one of its windows is
animating could cause the animating window to get stuck on screen.
Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
This allows us to support binary proximity sensors that only return 0.0 and 1.0
Change-Id: Ifaf3a4e6fc720cb246ac3558e3e733b4b612c95b
Signed-off-by: Mike Lockwood <lockwood@android.com>
* changes:
Make IBackupTransport.finishBackup() also return an int code, since it too can return TRANSPORT_NOT_INITIALIZED (in fact that's typically how it comes).
Add API to skip the animation for a particular start activity, so that
a latter better one can be used.
Fix Theme.NoDisplay to actually work.
Fiddle with various animations: don't do a different animation for task
switching, try a scale animation for switching in/out of the wallpaper.
Adjust the animation duration so that at normal speed we have something
more like the slower animation option (so slow is now the default).
Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
return TRANSPORT_NOT_INITIALIZED (in fact that's typically how it comes).
For consistency, make other IBackupTransport methods return int instead of
boolean, and handle accordingly.
Make initializeDevice() its own method instead of a flag on performBackup().
This will be needed when un-checking the settings box anyway, and is
conceptually unrelated to whatever happens to be the first post-initialization
backup we perform. (Note that even if the init is sent separately from the
backup operation, the server will remember that an init has been done and
will *not* return NOT_INITIALIZED for the subsequent backup.)
Fix LocalTransport accordingly (trivial changes).
Handle failures more robustly in BackupManagerService -- most notably,
doQueuedBackups() was ignoring the result code of processOneBackup(), so
a NOT_INITIALIZED error would go past unseen (at least until the next
backup pass). Keep track of error code returns more universally now.
(This includes finishBackup(), of course.)
When attempting a backup, the transport may inform us that the backend is in an
uninitialized state. This typically means that the device's data has been wiped
after a period [e.g. 90 days] of inactivity. This means that we need to
re-store all data subject to backup, and all of our incremental state tracking
on the device is now stale.
In response, we wipe all of our recorded backup state and restart the backup
pass on all participants.
More CPU speed stepping happening with newer devices, so we need
to qualify CPU time with the CPU speed, since power consumption
varies greatly by speed. Apps that peg the CPU should get a higher
penaltly.
Also, fix for 2062930: NPE at VolumePreference.onKey()
This changes a couple of bits of the Backup Manager's logic around
first-backup-ever handling. First, it uses the same "what we've ever backed up"
handling as the rest of the system for purposes of instructing the backend to do
a wipe when the metadata is initialized for the device, instead of looking at
the presence of the @pm@ file. Secondly, for the time being we won't be using
the saved state produced by agents' doRestore() logic. Until the server is
migrating each restored package's data over to the new dataset, this was
resulting in the client holding an agent state blob for which no data existed on
the server under this device's identity but which the device thought was fully
up to date.
IBackupTransport.performBackup() now takes a flag "wipeAllFirst", which if set
will result in the entire restore set for the current device/account being wiped
clean prior to the storage of the provided package. This ensures that a device
on which backup has just been enabled will not confront potentially-stale
information, nor will the restore set potentially contain mismatched data from
orphaned packages.
The Backup Manager has also been revised to pass this flag when first backing up
its master metadata block (and never pass it thereafter unless something has
caused the backup state tracking to be erased, e.g. the user has opted out of
backup and then later re-enabled it).
This fixes a problem that resulted in the screen staying off indefinitely if the prox sensor
is active at the beginning of a bluetooth call and could result in the screen staying off
in other similar circumstances.
Change-Id: Icfa0046d3179f9bb2247e7a3c1f9ff073312667a
Signed-off-by: Mike Lockwood <lockwood@android.com>
The process for starting wifi was using a wakelock around a message-pass and this was causing
an exception for meer mortals (who don't have WAKE_LOCK permission).
bug: 1750535
This also takes care of the problem of system dialogs like the
crash dialog causing the status bar to dim behind the lock screen.
On the down side, the fade transition from the lock screen is
now gone, and I'm not sure how likely it is for it to return.
Change-Id: I7f9e6d0f3510a1fdbbe6ad252d986bd85a16475d
Avert your eyes!
The key change here is that RemoteViews can now call a Context API to
start its pending intent, which inside of the activity manager we can
use to determine to cancel the timeout delay for external entities
to disrupt the home screen.
Change-Id: If097cf7478cbed7a3c04a304050bd7fd5703d197
This was a problem with not hiding the starting window when it got
transfered to an activity whose window (instead of token) animates
when displayed.
Change-Id: I9eb58faa6e27d53144687952a715fc083a5c5842
