Don't go looking at attributes of a package struct without first verifying
that the struct pointer is non-null: in the failed-install case, of course
there will be no package info.
Change-Id: I3b2cafca2f1e3891a6592825ce5bcc977e7f3483
When an application being installed defines a backupAgent in its manifest, we
now automatically perform a restore of the latest-known-good data for that app.
This is defined as "data backed up by this app from this handset, if available;
otherwise data for this app as it existed when the device was initially
provisioned." If neither option exists for the app, no restore action is
taken.
The CL involves major changes in the Backup and Package Managers...
* The Package Manager's act of installing an application has now been split
into two separate phases, with a data-restore phase optionally occurring
between these two PM actions. First, the details of the install are performed
as usual. Instead of immediately notifying install observers and issuing the
install-related broadcasts, the in-process install state is snapshotted and
the backup manager notified that a restore operation should be attempted. It
does this by calling a new API on IBackupManager, passing a token by which it
identifies its in-progress install state.
The backup manager then downloads [if possible] the data for the newly-installed
application and invokes the app's backupAgent to do the restore. After this
step, regardless of failure, it then calls back into the Package Manager to
indicate that the restore phase has been completed, supplying the token that
was passed in the original notification from the Package Manager.
The Package Manager then runs the final post-install actions: notifying install
observers and sending out all the appropriate broadcasts. It's only at this
point that the app becomes visible to the Launcher and the rest of the OS.
... and a few other bits and pieces...
* The ApplicationInfo.backupAgentName field has been exposed to the SDK. This
can be reverted if there's a reason to do so, but it wasn't clear that this
info needs to be hidden from 3rd party apps.
* Debug logging of restore set IDs and operation timeout tokens [used during
any asynchronous Backup Manager operation] are now consistently in hex for
readability.
* We now properly reset our binder identity before calling into the transport
during restore-set operations. This fixes a permissions failure when a
single-app restore was attempted.
* The 'BackupTest' test app is no longer lumped onto the system partition
by default.
Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
This is a bunch of reworking of how configuration changes are handled:
- When orientation is changing (for whatever reason), the window manager no
longer tries to pre-emptively compute a new configuration. Instead, it
just determines change is happening and tells the window manager.
- The activity manager is now responsible for giving the window manager the
final configuration it is using. This is both so it knows whem the
activity manager is done with its configuration updates, and so the window
manager can use the "real" configuration.
- When an orientation or other configuration change is happening, freeze the
screen and keep it frozen until the activity manager has given us the
final configuration.
- The window manager can now send new configurations to its clients during
its layout pass, as part of a resize, if it has determined that it has
changed. This allows for a new View.onConfigurationChanged() API for any
view to easily find out when the configuration has changed.
- ViewRoot now also works with the activity thread to make sure the process's
current resources are updated to the new configuration when it receives one
from a window. This ensures that at the time onConfigurationChanged() and
other view callbacks are happening, the correct configuration is in force.
- There is now a sequence number associated with Configuration, which
ActivityThread uses to avoid using stale configurations. This is needed now
that it can receive configurations asynchronously from both the window
manager and activity manager.
- The hack for keeping the locale has been removed, and underlying problem
fixed by having Configuration initialize its locale to "unknown" instead of
a valid default value.
Merge commit '6371a2d31f30b473e91be9cced64a2527c086af1'
* commit '6371a2d31f30b473e91be9cced64a2527c086af1':
Don't crash the system process when apps give us a bad foreground service notification.
Merge commit 'ee3bbefd34fd5330ebbc59175a328197ab7526af' into eclair-plus-aosp
* commit 'ee3bbefd34fd5330ebbc59175a328197ab7526af':
Don't crash the system process when apps give us a bad foreground service notification.
The passive location provider allows receiving location updates without
actually triggering them. This allows an application to receive location
updates that are being generated due to other clients of the location manager.
Change-Id: Ibf7a96b089c56875d4f62d3210252ae8d9f32768
Signed-off-by: Mike Lockwood <lockwood@android.com>
Changing the status bar behavior requires special permission.
Since disableCarMode is called out of a context that might not have this
permission, the calling identity is cleared before changing the status
bar behavior.
Note in docs that callbacks are on main thread.
Rename to DeviceAdminReceiver?
Document resetPassword is the device's password.
Also hide android.R.attr.neverEncrypt.
The core backup/restore classes [BackupManager, BackupAgent, RestoreSession, and
RestoreObserver] are now published for 3rd party developers, as well as the suite
of helper classes that exist so far to aid authorship of backup/restore agents.
In conjunction with the API change, the restore-time automatic data wipe has now
been removed: applications are responsible for managing the logic of wipe vs
merge themselves. If the app's agent onRestore() callback throws, the data
is presumed to be incoherent and a wipe is issued via the Activity Manager;
otherwise, no automatic action is ever taken.
Change-Id: I0b3418b829d4689b58b88be3d9c4ace37a8583a9
For the system server process, do the disableJitCompilation/startJitCompilation
callbacks depending on whether the system is in safe mode or not.
In addition, if the system is found to be in safe mode, a flag will be set in
the Zygote class which will be used to launch subsequent apps in VM safe mode.
Bug: 2267590
Refactoring of the dumpsys framework introduced a comparison that
always made the action dump all the services.
Change-Id: I1f3ac2bd903e39e2a6e8632e8cbb23a982dfe0c6
Include a proper name for processes that are in the background
with running services that have been running for a long time (instead
of showing them as bg-empty).
Batch together multiple processes into the same background bin when
there are significantly more processes than bins. Arguably this
should be smarter and base the binning on the number of background/empty
processes instead of the total count, but this should be good
enough for now.
