| d5f70b748351eb82a5f3567e2a1edea2de458951 |
|
22-Mar-2016 |
Christopher Tate <ctate@google.com> |
Clean up a couple of bugs about transport init staging
Using the right names for things typically works better.
Bug 27794697
Change-Id: Ic8c3c2c978536545bd669c1c12aad9ee6783f38a
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| e5f51c212cc3292a69988cd3569ce24cbb98f978 |
|
28-Jan-2016 |
Christopher Tate <ctate@google.com> |
Stage backup/restore data in a cache subdir rather than root
Also make sure not to do the restorecon() before the file is
created.
(Also fix binder identity bug in the 'bmgr fullbackup' flow.)
Bug 26834865
Change-Id: Ia8a59eeb55762264163c8b310caae5e303413571
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 872d3b6e19933af6fa9ae65214b9f6df04fc3222 |
|
12-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Quota exceeded API in BackupAgent
Should be also implemented in GMS BackupTransport.
Bug: 25693504
Change-Id: I6e4b2edb6d62addca0aced3e801d7629fb9394ca
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 9310e4285b3fc951c3524d040726d1161015562c |
|
10-Apr-2015 |
Christopher Tate <ctate@google.com> |
Avoid zero-payload backups in local transport
The local debugging transport now implements
BackupTransport.checkFullBackupSize() to detect and reject backup attempts
for which no actual file content will be committed. The documentation for
checkFullBackupSize() has also been expanded to document the transport's
responsibilities in this regard.
The local transport now lazy-creates the destination file when data is
first delivered for an approved backup operation, rather than doing it
proactively in performBackup(), to ensure that changes in the datastore
are only attempted after the transport has positive confirmation that
data is indeed flowing.
Change-Id: I6e47a7e72cd938fc0ed31da4bc490540c71f9e65
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| de2826b1e95573cf1cf065f46d661ab27bade00c |
|
13-Mar-2015 |
Christopher Tate <ctate@google.com> |
Properly set up local transport data dirs after an initialize operation
We were properly setting up the underlying storage at boot time, but
*not* doing so after an "initialize" operation, i.e. after wiping all
of the data upon request. The effect was that after an init operation
while using the local transport (e.g. if you disabled backup and then
reenabled it with the local transport as your active one), full-data
backup operations wouldn't work until after the next reboot.
(Resubmit, with fixes, of earlier revert.)
Change-Id: I745cb49b5155119d63cff6fffad5230687faca71
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 0a809733daff50c096075b54c4dccb495d002aeb |
|
13-Mar-2015 |
Ed Heyl <edheyl@google.com> |
Fix build: Revert "Properly set up local transport data dirs after an initialize operation"
This reverts commit dc205b3f9530ab8f25b9d8fdbe0fd942fcfc750e.
Change-Id: I6ed27c1eb8ddd1894bf0374b989a1b4e3d7761a3
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| dc205b3f9530ab8f25b9d8fdbe0fd942fcfc750e |
|
13-Mar-2015 |
Christopher Tate <ctate@google.com> |
Properly set up local transport data dirs after an initialize operation
We were properly setting up the underlying storage at boot time, but
*not* doing so after an "initialize" operation, i.e. after wiping all
of the data upon request. The effect was that after an init operation
while using the local transport (e.g. if you disabled backup and then
reenabled it with the local transport as your active one), full-data
backup operations wouldn't work until after the next reboot.
Change-Id: I3bfda1e94ae2312678b0bb2dde13ebdb64a56d2b
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 77a2d78dbf91d4799f811385b1e39ad89052e7eb |
|
04-Mar-2015 |
Christopher Tate <ctate@google.com> |
Don't enqueue allowBackup=false apps for full backup attempts
We are correctly refusing to actually process apps for backup if they have
declared android:allowBackup="false" in their manifests, but we're still
wasting bookkeeping & a certain amount of work in tracking them as part of
the full backup queue. Fix that; now we recognize that they shouldn't be
in the queue in the first place.
When reinflating the queue at boot time we also re-verify the participation
of each mentioned app so that we properly drop ones that have been uninstalled
or altered such that they are no longer full-data backup candidates.
Finally, if an app previously implemented key/value backup, so we think
we'll be running it in that mode in a future backup pass, but has been
updated to use the full-data path instead, we don't want to go ahead and
run a key/value pass on it. Added a backstop check and proceed gracefully
in this situation.
(Also add bit more debug-build logging to LocalTransport)
Bug 19462310
Change-Id: I07ab4f2e68e92766d9e8f2595fa763c91193d743
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 824392bdbdd0d593c4bd2d26f197bb0009ff75c9 |
|
15-Nov-2014 |
Christopher Tate <ctate@google.com> |
Don't crash just because invalid datasets were offered for restore
In practice, recognize that the current transport state may not yet
incorporate a valid restore data stream object, so don't go making
assumptions that it's usable / closeable / etc.
Bug 18379004
Change-Id: I221e04b5b83438e37455e025d67f412d3abb8c50
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| e079264b981d87c648921185528b553a86ae353d |
|
07-Aug-2014 |
Christopher Tate <ctate@google.com> |
API to tell the transport to cancel a full backup in progress
Bug 16524520
Change-Id: If2cbffd3c8a03bf4eb7b11ff1ae784c437e27e7f
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 9679410db578e179c7559e7a52bb21c8082e9631 |
|
28-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add data-management intent + label to BackupTransport API
Bug 16346320
Change-Id: Id9e855a1d3cebbf801c27a21e1edc3ffcccfd2e9
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 89101f7fe89134a609459e80f779c1a5114e562a |
|
18-Jul-2014 |
Christopher Tate <ctate@google.com> |
Tear down agents properly at EOD in full restore
The restore engine wasn't tearing down the bound agent after reaching
the end of data for the app, and furthermore was allowing the restore
operation to resume running the queue before all data had been delivered
to the current target.
Also make LocalTransport deliver data in 2K chunks rather than 32K,
as a first step towards making its timing characteristics more like
we'll see in networked situations.
Finally, added a bunch of MORE_DEBUG output for finding odd bugs
like this.
Change-Id: Icdbe6a070af6cc7c708a938ad044108d40ebce9a
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| a50cd8d4264ca98e19b858596de3a223ba6bf42e |
|
15-Jul-2014 |
Ed Heyl <edheyl@google.com> |
reconcile aosp (f908b61abf0882ce97d6d5076ee1c84393ed1ecd) after branching. Please do not merge.
Change-Id: Icd3f2c31aca8c9888c81da27eaeaffed07ec9820
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 51fea57e06fcb1dab1d239a5fff6e75ba2b7cee7 |
|
24-Jun-2014 |
Christopher Tate <ctate@google.com> |
Refactor restore to deal with heterogeneous datasets
Transport-based restore now handles both key/value and full-data
(stream) data delivery.
Also: PMBA now holds metadata for *all* apps, not just those with
backup agents. Since we need to consult this for every restore-
at-install operation we cache this locally now, tagged per transport
and per remote dataset, to avoid having to re-download it as part
of every future restore operation.
Also fixed a bug in LocalTransport that was preventing restore of
key/value datasets, i.e. all of them that were nominally available
prior to this change.
NOTE: at present there is no automatic full-data backup; if for
testing purposes you need to create some to then use for restore,
you still need to use 'bmgr fullbackup ...' to push them.
NOTE: at present the unified transport restore uses a refactored
"engine" implementation to handle stream data that encapsulates
the existing "adb restore" implementation. However, the adb
restore code path has not yet been refactored to wrap the newly-
extracted engine version; it still contains its own copy of all
the relevant logic. This will change in a future CL, at which
point offline/USB archive restore will simply wrap the same
shared stream-restore engine implementation.
Bug 15330073
Bug 15989617
Change-Id: Ieedb18fd7836ad31ba24656ec9feaaf69e164af8
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 5a009f9008d1f18b156c142b69e173109f5e218b |
|
19-Jun-2014 |
Christopher Tate <ctate@google.com> |
Adjust full restore API
Introduces a new constant, BackupTransport.NO_MORE_DATA, defined to
be -1. The transport returns this constant when asked for the next
chunk of streaming full restore data to indicate that it has reached
EOF on the current restore target's archive stream.
If the transport returns TRANSPORT_PACKAGE_REJECTED from that same
method, then the OS will abort the current target's restore operation
and move on to the next package in the overall restore dataset (by
calling nextRestorePackage() on the transport).
If the transport returns zero when asked for the next chunk of
restore stream data, this will be interpreted as meaning that no data
is currently deliverable but the restore download is still running
properly; the caller will then retry until either data is delivered
or the transport reports NO_MORE_DATA (or an error).
Also sketched in the implementation of this latest API in the
test LocalTransport.
Bug 15330073
Change-Id: I81621cb322f831460133b7dced5bb88d2a4124e1
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 6a49dd087f29cfca82d55dfabeb97439ef84b508 |
|
17-Jun-2014 |
Christopher Tate <ctate@google.com> |
Tweak restore API
We need the transport to tell the system not only what package it's going
to deliver data for next, but also what format that data is in.
Change-Id: I989cf78febf923a4208acb33ed80ccc7869356f5
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 9ff53a7100b1a40f5d2df3eb19a2f3f2fff39a46 |
|
04-Jun-2014 |
Christopher Tate <ctate@google.com> |
Implement full data backup through transport
Currently no timed/scheduled full-data backup operations are
performed by the OS, but the plumbing is now in place and can
be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'.
The LocalTransport test transport implementation has been augmented
to support the new full-data backup API as well.
In addition, 'adb backup' now takes the -compress/-nocompress
command line options to control whether the resulting archive is
compressed before leaving the device. Previously the archive was
always compressed. (The default is still to compress, as it will
usually reduce the archive size considerably.)
Internally, the core implementation of gathering the full backup
data stream from the target application has been refactored into
an "engine" component that is shared by both 'adb backup' and the
transport-oriented full backup task. The archive file header
generation, encryption, and compression logic are now factored out
of the engine itself instead of being hardwired into the data
handling.
Bug 15329632
Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 4dd2635bf501ad1a1adc22a6ceb4c66cd61a1a23 |
|
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Add full-backup stream API to BackupTransport
Also started migrating the definition of transport success/failure constants
into BackupTransport to make them permanent.
The new methods are not yet plumbed in; this is just to allow forward
progress against a proposed stable API.
Bug 15329632
Change-Id: I27472e09b831350c140b9fa548ebda3af334eb1a
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 74318c98a0f67e042815798f85c75eb7f14390e1 |
|
16-May-2014 |
Christopher Tate <ctate@google.com> |
Provide stable concrete wrapper for backup transport API
This initial version is a simple pass-through of the existing
IBackupTransport AIDL definition.
Change-Id: I0f6c9ffc7101f82127ab61ba6cba9f5003af6a0c
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| f97c63350abcc6715ba9fdc21fd3405d0f7ba716 |
|
29-Apr-2014 |
Elliott Hughes <enh@google.com> |
Move internal libcore.os users over to android.system.
Change-Id: I84e1ace19ba3b4e58d7bb24f3ecda1bdf5dc75a5
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| adfe8b86e9178a553b6db9722340fa4ff5201cf1 |
|
05-Feb-2014 |
Christopher Tate <ctate@google.com> |
App widget backup/restore infrastructure
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
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| a9b91864a1aedd71eaaaa43ee078cf93922289f3 |
|
26-Feb-2014 |
Christopher Tate <ctate@google.com> |
Deal with apps known to LocalTransport backend but with no data
An app might have backed something up and later deleted it, in which
case it will have a directory in the LocalTransport bookkeeping but
with no actual dataset. Skip these packages at restore time, since
we know a priori that there will be nothing to do.
Change-Id: I85853097bc65ed60e5efd217ee6553b50459e445
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| b048c33d5bdaec747195dfedf971d4d9155f5000 |
|
21-Feb-2014 |
Christopher Tate <ctate@google.com> |
Don't assume that we're at start of file at ctor time
BackupDataReader / BackupDataWriter were implicitly assuming that when
instantiated, the underlying fd was positioned at start-of-file. If one
tried to e.g. open an existing data stream to append further data to it,
things might randomly fail (at read time, possibly when consuming the
stream later) due to incorrect alignment of the data entities: the
appending writer would assume that no padding was needed to achieve
correct alignment, and this might easily be false.
Now the underlying native reader/writer helpers recognize the true
position within the file when constructed, and as a result it's now
safe to e.g. construct a BackupDataOutput for an existing file and
then append to it.
Change-Id: If0484921e687852f923a4b4efabff573a6c16981
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 6090995951c6e2e4dcf38102f01793f8a94166e1 |
|
19-Nov-2013 |
John Spurlock <jspurlock@google.com> |
Remove unused imports from frameworks/base.
Change-Id: Ia1f99bd2c1105b0b0f70aa614f1f4a67b2840906
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| cefba58d14f9669b57c16b4ea493779d882c43bd |
|
15-Nov-2013 |
Christopher Tate <ctate@google.com> |
Handle backup transport registration dynamically
Bug 11369873
Change-Id: I9bbdcc21ce25159c6645690123b5d03c553b0ddc
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| ebab0ae105f1a6df593a4bc2549fae3ee8b2ade4 |
|
04-Dec-2012 |
rpcraig <rpcraig@tycho.ncsc.mil> |
BackupManagerService files need new security labeling.
Use restorecon to label files and directories
specific to BMS.
* /data/backup : provide default type labeling
for all files/dirs used by BMS.
* /data/secure/backup : provide default type
labeling used by BMS when encrypted
file system is enabled.
* /cache/<package name>.{data|restore} :
specifically target files opened and
passed by BMS to apps that have backup
capabilities.
* /cache/backup : default labeling for the
directory used by the LocalTransport
that stores backup files for local testing.
Change-Id: Id4d46e82cd13abc2e395e0c30c515f0a33df93e7
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 0abf6a001461a4c2ea31ddc44a60b003b4e0554d |
|
24-Mar-2012 |
Christopher Tate <ctate@google.com> |
Don't crash when wiping backup data redundantly in the local transport
Previously, if using the "local" debugging transport:
adb shell bmgr wipe com.android.browser
adb shell bmgr wipe com.android.browser
... would bring down the runtime. This no longer happens. The fix
covers two aspects of the situation: 1. the local transport no longer
blows up in this use case, and 2. the backup manager itself now catches
blowups on the part of the transport, and tidies up after them.
Bug 6205185
Change-Id: Ieb9b8827a62523148ad5a0ec15b05a954d198b3d
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 4140faeebbfa23d56068c1862b2913fb62145f4f |
|
25-Jan-2011 |
Brian Carlstrom <bdc@google.com> |
Tracking jarjar of org.bouncycastle to com.android.org.bouncycastle
Bug: 3086427
Change-Id: I7af99fe4c36d9a519777f0499ccab65646313879
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| a8ddef346cece1ad229e270ac4deebbd41ba6721 |
|
10-Nov-2010 |
Chris Tate <ctate@google.com> |
Add description and configuration methods to the transport interface
It's now possible for the transport to supply a descriptive string to inform
the user about the nature of the backup destination (e.g. telling the user
what account the data is being stored under), and to supply an Intent with
which the system can initiate a configuration Activity supplied by the
transport (e.g. allowing the user to select which account their data is
being stored under).
The transport interface is not public.
Part of bug 2753632 and bug 2987804
Change-Id: I911f70a3ea440daf2a7a04710e9d7e65b61a58db
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 1afd1c90ebe789b8d3a137004127a50d2db7e3b5 |
|
19-Mar-2010 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #2457218: Corrupt batterystats.bin file preventing phone boot - LIBtt68127
No steps to repro, but makes the code more robust by using the standard
JournaledFile class and doing sanity checks on the input it reads.
This required moving the JournaledFile class in to the framework (and
we really should get rid of either it or AtomicFile, but they have
different recovery semantics so that is tough). Also went through and
cleaned up the file management in various places.
Change-Id: Ieb7268d8435e77dff66b6e67bb63b62e5dea572e
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 15a4d2ffd04dc6c70f2cd17dae12ac6bc14c69ab |
|
12-Mar-2010 |
Kenny Root <kroot@google.com> |
Add correct copyright headers to multiple files
Format for the list of changes shows the origin commit reference followed
by the file name.
33931-p9 awt/org/apache/harmony/awt/gl/font/AndroidGlyphVector.java
33931-p9 awt/org/apache/harmony/awt/gl/image/PngDecoderJava.java
133776-p9 core/java/android/app/IntentService.java
127013-p9 core/java/android/appwidget/AppWidgetHost.java
27863-p9 core/java/android/bluetooth/BluetoothAudioGateway.java
60765-p9 core/java/android/content/SyncResult.java
43920-p9 core/java/android/content/pm/ActivityInfo.java
43920-p9 core/java/android/content/pm/ApplicationInfo.java
43920-p9 core/java/android/content/pm/InstrumentationInfo.java
43920-p9 core/java/android/content/pm/PackageInfo.java
44103-p9 core/java/android/content/pm/PackageItemInfo.java
68960-p9 core/java/android/content/pm/PackageStats.java
43920-p9 core/java/android/content/pm/ResolveInfo.java
43920-p9 core/java/android/content/pm/ServiceInfo.java
60641-p9 core/java/android/content/res/Configuration.java
60734-p9 core/java/android/content/res/TypedArray.java
137672-p9 core/java/android/inputmethodservice/ExtractButton.java
123112-p9 core/java/android/inputmethodservice/ExtractEditText.java
119291-p9 core/java/android/inputmethodservice/IInputMethodSessionWrapper.java
112946-p9 core/java/android/inputmethodservice/IInputMethodWrapper.java
115078-p9 core/java/android/os/BatteryStats.java
124790-p9 core/java/android/text/style/UpdateAppearance.java
45083-p9 core/java/android/view/RawInputEvent.java
101491-p9 core/java/android/view/inputmethod/EditorInfo.java
114701-p9 core/java/android/view/inputmethod/ExtractedText.java
123112-p9 core/java/android/view/inputmethod/ExtractedTextRequest.java
119291-p9 core/java/com/android/internal/os/HandlerCaller.java
129279-p9 core/java/com/android/internal/os/PkgUsageStats.java
114701-p9 core/java/com/android/internal/view/IInputConnectionWrapper.java
114701-p9 core/java/com/android/internal/view/InputConnectionWrapper.java
84364-p9 opengl/java/android/opengl/EGLLogWrapper.java
11355-p9 opengl/tools/glgen/src/CFunc.java
11355-p9 opengl/tools/glgen/src/CType.java
11355-p9 opengl/tools/glgen/src/CodeEmitter.java
11355-p9 opengl/tools/glgen/src/GenerateGL.java
11355-p9 opengl/tools/glgen/src/JFunc.java
11355-p9 opengl/tools/glgen/src/JType.java
11355-p9 opengl/tools/glgen/src/JniCodeEmitter.java
11355-p9 opengl/tools/glgen/src/ParameterChecker.java
57236-p9 services/java/com/android/server/status/AnimatedImageView.java
66754-p9 services/java/com/android/server/status/CloseDragHandle.java
57188-p9 services/java/com/android/server/status/DateView.java
46928-p9 services/java/com/android/server/status/ExpandedView.java
70590-p9 services/java/com/android/server/status/FixedSizeDrawable.java
45968-p9 services/java/com/android/server/status/IconData.java
57470-p9 services/java/com/android/server/status/IconMerger.java
82719-p9 services/java/com/android/server/status/LatestItemView.java
45968-p9 services/java/com/android/server/status/NotificationData.java
66754-p9 services/java/com/android/server/status/NotificationLinearLayout.java
57458-p9 services/java/com/android/server/status/NotificationViewList.java
45968-p9 services/java/com/android/server/status/StatusBarException.java
45968-p9 services/java/com/android/server/status/StatusBarIcon.java
46130-p9 services/java/com/android/server/status/StatusBarNotification.java
45968-p9 services/java/com/android/server/status/StatusBarView.java
46199-p9 services/java/com/android/server/status/Ticker.java
62286-p9 services/java/com/android/server/status/TickerView.java
57188-p9 services/java/com/android/server/status/TrackingView.java
86041-p9 telephony/java/android/telephony/PhoneStateListener.java
87020-p9 telephony/java/com/android/internal/telephony/TelephonyIntents.java
136269-p9 telephony/java/com/android/internal/telephony/gsm/SpnOverride.java
34409-p9 tests/FrameworkTest/src/com/android/frameworktest/FrameworkTestApplication.java
55717-p9 tests/FrameworkTest/src/com/android/frameworktest/performance/InvalidateCycle.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/AutoCompleteTextViewActivityLandscape.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/AutoCompleteTextViewActivityPortrait.java
129372-p9 tests/ImfTest/src/com/android/imftest/samples/BigEditTextActivityNonScrollablePanScan.java
129372-p9 tests/ImfTest/src/com/android/imftest/samples/BigEditTextActivityNonScrollableResize.java
129372-p9 tests/ImfTest/src/com/android/imftest/samples/BigEditTextActivityScrollablePanScan.java
129372-p9 tests/ImfTest/src/com/android/imftest/samples/BigEditTextActivityScrollableResize.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/BottomEditTextActivityPanScan.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/BottomEditTextActivityResize.java
127341-p9 tests/ImfTest/src/com/android/imftest/samples/ButtonActivity.java
129347-p9 tests/ImfTest/src/com/android/imftest/samples/DialogActivity.java
129372-p9 tests/ImfTest/src/com/android/imftest/samples/EditTextActivityDialog.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/ManyEditTextActivityNoScrollPanScan.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/ManyEditTextActivityScrollPanScan.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/ManyEditTextActivityScrollResize.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/OneEditTextActivityNotSelected.java
128994-p9 tests/ImfTest/src/com/android/imftest/samples/OneEditTextActivitySelected.java
25959-p9 tests/framework-tests/src/android/test/FrameworkTests.java
46162-p9 tests/framework-tests/src/com/android/internal/http/multipart/MultipartTest.java
77101-p9 tools/layoutlib/bridge/tests/com/android/layoutlib/bridge/NinePatchTest.java
9788976b1465ce982b5ae7c741345edd0ecd9322 core/java/android/accounts/AuthenticatorDescription.java
53332883543868fb83e111a07306368b7772b340 core/java/android/app/UiModeManager.java
93e7e22ec91dbc641d10ca6d70423e1357a95bba core/java/android/app/FullBackupAgent.java
328c0e7986aa6bb7752ec6de3da9c999920bb55f core/java/android/content/CursorEntityIterator.java
307da1a46b4c9b711bafe8fbaaa6b98e8868c18e core/java/android/content/SyncQueue.java
307da1a46b4c9b711bafe8fbaaa6b98e8868c18e core/java/android/content/SyncOperation.java
eb034652c2037a47ebfd99779e8383bb8bb528af core/java/android/content/pm/LabeledIntent.java
49237345d83e62fdb9eb8d50b13ad086636a04fa core/java/android/content/pm/FeatureInfo.java
a2b6c3775ed6b8924232d6a01bae4a19740a15f8 core/java/android/content/pm/PackageInfoLite.java
3ecd5f437580e49d80beecd29489d5fb1f7a7db0 core/java/android/content/pm/RegisteredServicesCacheListener.java
5ebbb4a6b3e16f711735ae0615b9a9ea64faad38 core/java/android/content/pm/XmlSerializerAndParser.java
c4516a7b62de525e3d6d5e76851bdfaf12c11f05 core/java/android/database/sqlite/SQLiteTransactionListener.java
9bbc21a773cbdfbef2876a75c32bda5839647751 core/java/com/android/internal/backup/LocalTransport.java
21f1bd17b2dfe361acbb28453b3f3b1a110932fa core/java/com/android/internal/content/PackageMonitor.java
4c62fc0e1e5ea9c69a12a7d1cf8b3ec8b2d114a3 core/java/com/android/internal/view/BaseSurfaceHolder.java
4c62fc0e1e5ea9c69a12a7d1cf8b3ec8b2d114a3 core/java/com/android/internal/view/BaseIWindow.java
e540833fdff4d58e37c9ba859388e24e2945ed45 core/java/com/android/internal/os/SamplingProfilerIntegration.java
192ab903887bbb8e7c7b6da5c581573850e30f46 core/tests/coretests/src/android/widget/expandablelistview/PositionTesterContextMenuListener.java
1619367ab823150fa8856d419abe02ceb75886f1 media/tests/MediaFrameworkTest/src/com/android/mediaframeworktest/MediaProfileReader.java
27f8002e591b5c579f75b2580183b5d1c4219cd4 opengl/tools/glgen/stubs/gles11/glGetString.java
560814f6b11abe83ff0c4ed18cac015c276b3181 opengl/tools/glgen/stubs/gles11/glGetProgramInfoLog.java
560814f6b11abe83ff0c4ed18cac015c276b3181 opengl/tools/glgen/stubs/gles11/glGetShaderInfoLog.java
560814f6b11abe83ff0c4ed18cac015c276b3181 opengl/tools/glgen/stubs/gles11/glShaderSource.java
1c4907ee77392afb768c2f088e0dedbe4239f6fb opengl/tools/glgen/src/GenerateGLES.java
1c4907ee77392afb768c2f088e0dedbe4239f6fb opengl/tools/glgen/src/Jsr239CodeEmitter.java
1c4907ee77392afb768c2f088e0dedbe4239f6fb opengl/tools/glgen/src/GLESCodeEmitter.java
69e21f5f6e0d04539cd92848ea009dd615d88c2c opengl/tests/gldual/src/com/android/gldual/TriangleRenderer.java
c028be4f3b8c7476b46859f66c3f33d528adf181 packages/DefaultContainerService/src/com/android/defcontainer/DefaultContainerService.java
7c6efa13f129dbae5319f0981a430d4662f43354 tests/BrowserPowerTest/src/com/android/browserpowertest/PowerMeasurement.java
7c6efa13f129dbae5319f0981a430d4662f43354 tests/BrowserPowerTest/src/com/android/browserpowertest/PowerTestActivity.java
7c6efa13f129dbae5319f0981a430d4662f43354 tests/BrowserPowerTest/src/com/android/browserpowertest/PowerTestRunner.java
df8a3f31d871db25e952972c2eb346a71186e9e3 tests/BrowserTestPlugin/src/com/android/testplugin/TestPlugin.java
cfaef699e1dfb3a75d5b51f3b15816f13670fd51 tests/permission/src/com/android/framework/permission/tests/ActivityManagerPermissionTests.java
cfaef699e1dfb3a75d5b51f3b15816f13670fd51 tests/permission/src/com/android/framework/permission/tests/ServiceManagerPermissionTests.java
cfaef699e1dfb3a75d5b51f3b15816f13670fd51 tests/permission/src/com/android/framework/permission/tests/WindowManagerPermissionTests.java
Copyright header moved to top in following file:
core/tests/coretests/src/android/widget/ListViewTest.java
Change-Id: I3c3198be5a0ba36e18679ed834170432bf0b8418
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 50c6df04cf17a99c3959c306a4e0e10da6d85c46 |
|
29-Jan-2010 |
Christopher Tate <ctate@google.com> |
Add a method to IBackupTransport to get the current backup set token
This will be used to specifically manage restores of last-known-good data
generated from the current device during its normal provisioned lifetime.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| bd0a81ff1c0e92e80e05e2f12bb1805c7d081e94 |
|
04-Oct-2009 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #2163789: Way too much logging
Dr.No from mcleron.
Change-Id: Iaca2268684f83fe8757e64db0b0e047a19755311
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 0144516e19b9fd5415a56f8b41191187e2344bb0 |
|
22-Sep-2009 |
Dan Egnor <egnor@google.com> |
Make IBackupTransport.finishBackup() also return an int code, since it too can
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.)
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| d55e18acbe444b74dc9e71eff6ea2c3eaf25fbd0 |
|
21-Sep-2009 |
Christopher Tate <ctate@android.com> |
Reset backup tracking in response to transport data-wipe notification
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.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 25a747f5c47f25c1a18961b03507f309b84924fe |
|
20-Sep-2009 |
Christopher Tate <ctate@android.com> |
Add an 'init everything' operation to the first backup pass
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).
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| ee0e78af5af3bf23dd928fe5e0ebeb39157eaf66 |
|
02-Jul-2009 |
Christopher Tate <ctate@google.com> |
Add a "clear backed-up data" method to the backup mechanism
It's now possible to ask that the backup manager wipe the saved data for a given
application from the backing store. LocalTransport implements this now but the
Google backend does not yet. When the data is wiped, the on-device backup state
is also wiped to ensure that the next backup pushes all necessary data.
Bmgr has not yet been modified to actually call into this method, but it will
be soon.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 5cb400bd72726c22f641f334951b35ce2ddcfeef |
|
26-Jun-2009 |
Christopher Tate <ctate@google.com> |
Keep track of backup state independently for each transport
Backup transports now provide the Backup Manager with a suggested name with
which it can disambiguate any transport-specific bookkeeping that it needs to
maintain. The Manager keeps separate application backup 'state blobs' for each
transport now, preventing things from getting out of step if the device is
switched among multiple transports.
Also, the metadata backup agent is always invoked now on each backup pass. This
is cheap when there is nothing to do, but also strongly ensures that we never
wind up in a situation where a given transport destination has not been given
all of the metadata necessary for the backup set.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| efe52647f6b41993be43a5f47d1178bb0468cec8 |
|
24-Jun-2009 |
Dan Egnor <egnor@google.com> |
Modify the IBackupTransport API to support bulk restore operations.
Change the BackupManagerService and LocalTransport to support the new API.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 3a31a93b8a195ae2d0180e6dfbf292da2e581f50 |
|
23-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add some global metadata to the restore set
In addition to the signatures of each participating application, we now also
store the versionCode of each backed-up package, plus the OS version running on
the device that contributed the backup set. We also refuse to process a backup
from a later OS revision to an earlier one, or from a later app version to an
earlier.
LocalTransport has been modified as well to be more resilient to changes in the
system's use of metadata pseudopackages.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 5d605dc56b036232e885f6ec36b888b729673060 |
|
19-Jun-2009 |
Joe Onorato <joeo@android.com> |
backup stuff
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| e9190a2750e1fb67e300d2c128227cc9b7339efe |
|
18-Jun-2009 |
Christopher Tate <ctate@google.com> |
Base64 the keys to make filenames in LocalTransport
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 83248c432ffe2e2a17abbc8e4960c26574b46bca |
|
18-Jun-2009 |
Joe Onorato <joeo@android.com> |
backup fixes:
- BackupTestAgent calls the DispatchHelper
- Make BackupAgent.onRestore take a BackupDataInput, not just a
generic ParcelFileDescriptor.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 5f15d151b5101fadfe6cba1e8f4aa6367e8c603e |
|
16-Jun-2009 |
Joe Onorato <joeo@android.com> |
checkpoint BackupDatAInput / RestoreHelper
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| f68eb500f99361541049e09eb7f9ddd6f4ef4efa |
|
16-Jun-2009 |
Christopher Tate <ctate@google.com> |
More bmgr work; fix clear-data signalling
The 'list sets' and 'restore token#' commands from bmgr now do what they are
supposed to. At this point we see the restore target's data being cleared
properly and its agent being launched and invoked for restore.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 8e55eac96d768a4de68a091f57487deadf6d0a87 |
|
15-Jun-2009 |
Christopher Tate <ctate@google.com> |
Bring the test transport's restore code into line
It now reconstructs the backup data stream as it was originally structured, no
longer assuming that its backed-up records can simply be concatenated into the
destination stream.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 2fdd428e0f18384160f7c38ce3a2cd9ba7e7b2c2 |
|
13-Jun-2009 |
Christopher Tate <ctate@google.com> |
Fix some backup reader/writer issues; make local transport do backup
As of this change, LocalTransport is successfully propagating data changes from
the backup data format into a repository stored in /cache/backup/[packagename].
Each backup key gets a separate file there for ease of manipulation and testing.
The general semantics of BackupDataReader have been tweaked, too; it now just
returns simple "we're done with the data" when it hits the end, even if no
footer has been found, because on the writing side the footer isn't being
written. Also, reading an entity now merely requires a "big enough" buffer, not
an exactly-sized one.
This is all a work in progress, but this is at least working now for purposes of
this local transport.
Still to do: proper change vs deletion detection, as well as expanding the data
format itself to include necessary metadata etc.
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|
| 9bbc21a773cbdfbef2876a75c32bda5839647751 |
|
11-Jun-2009 |
Christopher Tate <ctate@google.com> |
Flesh out restore interface on manager; work up most of LocalTransport
/frameworks/base/core/java/com/android/internal/backup/LocalTransport.java
|