| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I84e1ace19ba3b4e58d7bb24f3ecda1bdf5dc75a5
|
|
|
|
|
|
| |
Bug 13906859
Change-Id: I926ccc5620abae8b97bd2b7de21b82b7729e78dd
|
|
|
|
|
|
|
|
|
|
| |
If the user has stated a preference about their home app, make sure we
capture that so that a system restore can return them to that preferred
situation. It's built into the system metadata so that we can, if
necessary, fast-path configuration of that home app while the rest of
the restore operation is in flight.
Change-Id: I64dfee8f7a2a9e40f556cd19298d7b367c6aa8dc
|
|
|
|
|
|
| |
Bug 13732002
Change-Id: Ic8f71234d1bbc7420eaa8e1762b999d09f308d46
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
|
|
|
|
| |
Change-Id: I8f21b7239621da500d9a73eb17d350e06dda9b20
|
|
|
|
|
|
|
|
|
| |
klp-modular-dev
* commit '777b8a808ee76401429f7210ebb7194632040d45':
Adapt to underlying changes in the PBKDF2 implementation
Change-Id: Ia68694a03e52693fceaedc6740dbd8e690e21257
|
|
|
|
|
|
| |
Bug 12991308
Change-Id: Ie5d3d27fe565dd4014976f5333e37b5707acb707
|
|
|
|
|
|
|
| |
com.android.server.SystemServer was no longer imported
on master.
Change-Id: Ie712aa28940953952aa7a99cbb22f74129649249
|
|\
| |
| |
| |
| |
| |
| | |
Context." into klp-modular-dev
* commit '25df673b849de374cf1de40250dfd8a48b7ac28b':
Make SystemService constructor take a Context.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
|
|\ \
| |/
| |
| |
| |
| |
| | |
services" into klp-modular-dev
* commit 'a5a93f559d337ad5b79716b05ea43707eb779dc8':
Check feature bits before loading optional services
|
| |
| |
| |
| |
| |
| |
| |
| | |
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Change-Id: I5443f31a5e13c24f44445768b6e9a6eea221ede6
|
|\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
services/print/java/com/android/server/print/PrintManagerService.java
Change-Id: I1b9bf364ca50ee3c48f53d87ae0ce23e7f3c2bc2
|
| |
| |
| |
| |
| |
| |
| |
| | |
These services can now be excluded by modifying the list of REQUIRED_SERVICES (TB renamed)
Changed appwidget, devicepolicy, backup and print services.
Change-Id: Id8e2855d5c045cd57bdb02dca9ed75172803bce7
|
|/
|
|
|
| |
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|