| 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
ocalTransport.java
|
| bf1a4a81ebd340a18583f4ca9b5d562a01f55674 |
09-Aug-2014 |
Christopher Tate <ctate@google.com> |
Start using cancelFullBackup() when appropriate
The API was in place but the framework wasn't yet calling it.
Bug 16524520
Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
BackupTransport.aidl
|
| 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
ocalTransport.java
|
| 9679410db578e179c7559e7a52bb21c8082e9631 |
28-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add data-management intent + label to BackupTransport API
Bug 16346320
Change-Id: Id9e855a1d3cebbf801c27a21e1edc3ffcccfd2e9
BackupTransport.aidl
ocalTransport.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
ocalTransport.java
|
| a50cd8d4264ca98e19b858596de3a223ba6bf42e |
15-Jul-2014 |
Ed Heyl <edheyl@google.com> |
reconcile aosp (f908b61abf0882ce97d6d5076ee1c84393ed1ecd) after branching. Please do not merge.
Change-Id: Icd3f2c31aca8c9888c81da27eaeaffed07ec9820
ocalTransport.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
ocalTransport.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
ocalTransport.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
BackupTransport.aidl
ocalTransport.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
BackupTransport.aidl
ocalTransport.java
|
| c777185688d1de4f1c989b3f7630e7715fd71be3 |
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Finish migration of backup transport constants
...and make sure to fix a couple of lingering Javadoc references.
Bug 15329632
Change-Id: I1de7b53a58940834cd2dae2301fd5f65dbb48ba6
ackupConstants.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
ocalTransport.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
BackupTransport.aidl
ocalTransport.java
ocalTransportService.java
|
| f97c63350abcc6715ba9fdc21fd3405d0f7ba716 |
29-Apr-2014 |
Elliott Hughes <enh@google.com> |
Move internal libcore.os users over to android.system.
Change-Id: I84e1ace19ba3b4e58d7bb24f3ecda1bdf5dc75a5
ocalTransport.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
ocalTransport.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
ocalTransport.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
ocalTransport.java
|
| 6090995951c6e2e4dcf38102f01793f8a94166e1 |
19-Nov-2013 |
John Spurlock <jspurlock@google.com> |
Remove unused imports from frameworks/base.
Change-Id: Ia1f99bd2c1105b0b0f70aa614f1f4a67b2840906
ocalTransport.java
|
| cefba58d14f9669b57c16b4ea493779d882c43bd |
15-Nov-2013 |
Christopher Tate <ctate@google.com> |
Handle backup transport registration dynamically
Bug 11369873
Change-Id: I9bbdcc21ce25159c6645690123b5d03c553b0ddc
BackupTransport.aidl
ocalTransport.java
ocalTransportService.java
|
| df4144f4dfaa3a344cfdf923121f6113463978da |
26-Mar-2013 |
Geremy Condra <gcondra@google.com> |
am 9fa57b74: am 2aee33c1: Merge "BackupManagerService files need new security labeling."
* commit '9fa57b74d8acb99c86f761a98f6e76998de8aff2':
BackupManagerService files need new security labeling.
|
| 294b512ecaa98a6a8ef12285ad14e7a4091b5d57 |
19-Feb-2013 |
Christopher Tate <ctate@google.com> |
DO NOT MERGE - Full backup/restore now handles OBBs sensibly
OBB backup/ restore is no longer handled within the target app
process. This is done to avoid having to require that OBB-using
apps have full read/write permission for external storage.
The new OBB backup service is a new component running in the
same app as the already-existing shared storage backup agent.
The backup infrastructure delegates backup/restore of apps'
OBB contents to this component (because the system process
may not itself read/write external storage).
From the command line, OBB backup is enabled by using new
-obb / -noobb flags with adb backup. The default is noobb.
Finally, a couple of nit fixes:
- buffer-size mismatch between the writer and reader of chunked
file data has been corrected; now the reading side won't be
issuing an extra pipe read per chunk.
- bu now explicitly closes the transport socket fd after
adopting it. This was benign but triggered a logged
warning about leaked fds.
(Cherrypicked)
Change-Id: I471f6348abcccb7bf1e1710b7beda9f23de53e14
ObbBackupService.aidl
|
| 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>
ocalTransport.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
ocalTransport.java
|
| 6de74ff2a45591455cbb5c21d78904065e89ec89 |
18-Jan-2012 |
Christopher Tate <ctate@google.com> |
Fix edge cases leading to backup hanging forever
Plug a couple of apparent code paths (one not obviously reachable, but
fixed here on general principles) that could lead to a backup pass
getting confused partway through and simply never properly completing.
In this state it would leave its wakelock held forever until next
reboot. Bug 5828859.
Those fixes are a total of two lines of code. The rest of the patch
adds a textual journal of the most recently completed (or ongoing!)
backup pass's progress, with an eye to being able to isolate any such
issues that may crop up in the future.
Change-Id: If8a5e8aba11db5a1e618d8b9c9ba3038dd5377a1
ackupConstants.java
|
| 8e294d45570b62a39ae972b146f0023c6beb00cb |
01-Sep-2011 |
Christopher Tate <ctate@google.com> |
Fix backup-agent timeouts
Away in the misty span of very-long-ago, it was suggested that spinning
a separate thread to run the backup process was wasteful, and that it
could just run it inline on the dedicated HandlerThread that the
backup manager uses for its own operations. That was indeed true,
except that the timeout management was also using delayed messages
to that handler. You see where this is going: timeouts were never
actually being processed, with the effect that a badly-behaving
app's backup agent could lock up the entire backup / restore system
until the device was rebooted.
This is bad.
Backup operations are now driven as an asynchronous state machine:
each step (init, call one agent to obtain data, send resulting
data to the transport, finalize the backup) is handled as a formal
state transition on-looper. No synchronous wait-for-completion
or -timeout is performed on any thread.
As an additional effect this greatly tightens up the serialization
and locking semantics. We no longer have to worry about an in-
flight operation involving a standalone thread spinning off on
its own; everything is on the HandlerThread and can be coherently
manipulated from that perspective.
Along the way, this CL tightens up the per-agent error handling
logic. Previously a single failed agent would abort the entire
backup process, tantamount to a transport-level failure. This could
mean that the aforesaid badly-behaving app's agent could in effect
starve out other apps whose agents were routinely showing up later
in the queue. There's some nondeterminism involved, but in practice
it could and did happen. Furthermore, the failure case would
reschedule *immediately* in this case, because the transport itself
would see that all is well and sure, why not run a backup soon?
This, as you might imagine, causes battery-life issues.
Now we note that the single agent has failed, mark it for a future
repeat attempt, and process the rest of the queue normally, pretending
success at the transport level even though we didn't actually send
any data for that app. This means that (a) we now finish running
backups for everything in the queue, (b) reschedule backups only for
those apps whose agents individually failed during this run, and
(c) perform the retry after the normal interval [typically on the
order of an hour] rather than immediately.
NOTE: this CL does not retool the restore code path, just backup.
Restore is similarly vulnerable to misbehaving apps, though, so a
future CL will address that bug vector.
Addresses bug 5074923
Change-Id: I67e3f8d06f322607881eaa4093de6d675b85ff2c
ackupConstants.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
ocalTransport.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
BackupTransport.aidl
ocalTransport.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
ocalTransport.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
ocalTransport.java
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
BackupTransport.aidl
ocalTransport.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.
BackupTransport.aidl
ocalTransport.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
ocalTransport.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.)
BackupTransport.aidl
ocalTransport.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.
ackupConstants.java
BackupTransport.aidl
ocalTransport.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).
BackupTransport.aidl
ocalTransport.java
|
| 9bb8fd77c8dc177aab9ac96bed4f55972dcda70a |
29-Jul-2009 |
Joe Onorato <joeo@android.com> |
Only restore the bits for wallpapers that aren't built in.
ystemBackupAgent.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.
BackupTransport.aidl
ocalTransport.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.
BackupTransport.aidl
ocalTransport.java
|
| 111bd4acdb378266221b430a284f88a3990a3958 |
25-Jun-2009 |
Christopher Tate <ctate@google.com> |
Start backing up wallpaper
This CL does the following:
+ adds an AbsoluteFileBackupHelper class for managing backup of files
known by absolute path, not based off of the app's getFilesDir() root
+ bumps up the collection interval from its testing-only default of 1 second
to 3 minutes
+ adds a SystemBackupAgent class to the main system package and names it as
the android:backupAgent for the main OS package. Right now this agent
only backs up & restores the wallpaper file.
+ amend the Wallpaper Service to inform the Backup Manager when the wallpaper
changes.
On the subject of the 3-minute collection interval before the backup actually
occurs: this can be short-circuited from an adb shell. Running the command
'bmgr run' will cause the Backup Manager to kick off any pending backup
operations immediately.
ystemBackupAgent.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.
BackupTransport.aidl
ocalTransport.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.
ocalTransport.java
|
| 5d605dc56b036232e885f6ec36b888b729673060 |
19-Jun-2009 |
Joe Onorato <joeo@android.com> |
backup stuff
ocalTransport.java
|
| e9190a2750e1fb67e300d2c128227cc9b7339efe |
18-Jun-2009 |
Christopher Tate <ctate@google.com> |
Base64 the keys to make filenames in LocalTransport
ocalTransport.java
|
| 3c2f8e6651178742bc685e7bd62fa8a6ca409a74 |
18-Jun-2009 |
Android (Google) Code Review <android-gerrit@google.com> |
Merge change 4456 into donut
* changes:
Replace the stub GoogleTransport with callout to the GoogleTransportService (which lives in vendor/google). Use the Google transport by default. Also, fix a bug: Thread.run() != Thread.start()
|
| 87a02bcf68dd4cc1f6d9fdcee3d1ebc9b04cf1f8 |
17-Jun-2009 |
Dan Egnor <egnor@google.com> |
Replace the stub GoogleTransport with callout to the
GoogleTransportService (which lives in vendor/google).
Use the Google transport by default.
Also, fix a bug: Thread.run() != Thread.start()
oogleTransport.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.
ocalTransport.java
|
| 5f15d151b5101fadfe6cba1e8f4aa6367e8c603e |
16-Jun-2009 |
Joe Onorato <joeo@android.com> |
checkpoint BackupDatAInput / RestoreHelper
ocalTransport.java
|
| aa088447baadd2e0bbcfd18cc529645610c13ddc |
17-Jun-2009 |
Christopher Tate <ctate@google.com> |
Hold the current transport instantiated all the time.
We no longer instantiate the transport just for the duration of handling a
backup or restore operation. Instead, we hold the object forever (replacing it
if instructed to do so). This makes it easier for transports to watch system
state and help set backup timing policy.
Also fixes up the IBackupTransport documentation a bit.
BackupTransport.aidl
|
| 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.
ocalTransport.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.
ocalTransport.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.
ocalTransport.java
|
| 9bbc21a773cbdfbef2876a75c32bda5839647751 |
11-Jun-2009 |
Christopher Tate <ctate@google.com> |
Flesh out restore interface on manager; work up most of LocalTransport
dbTransport.java
ocalTransport.java
|
| df01deaacff82b918b4f0ba774d5ad3087543629 |
10-Jun-2009 |
Christopher Tate <ctate@google.com> |
More restore plumbing, plus add suggested-backoff to transport API
Adds most of the code for a background-thread restore process, structured much
like the backup thread. Broke some common functionality out into a helper
function for doing a synchronous wait for a requested agent to attach.
Added a method to IBackupTransport whereby the transport will be asked for
an opinion on whether this is a good time for a backup to happen. It will
reply with the results of its policymaking around backoff intervals, time-of-day
selection, etc.
dbTransport.java
oogleTransport.java
BackupTransport.aidl
|
| 9b3905c4a25f2d785ce7535d1f2e1540b46bb561 |
09-Jun-2009 |
Christopher Tate <ctate@google.com> |
Revamp IRestoreSession a bit
We now supply an array of RestoreSet objects instead of wacky Bundle
shenanigans. Also, pushed beginRestoreSession() out to the BackupManager
concrete interface class so that SetupWizard can use it.
(beginRestoreSession() is @hide, non-privileged apps cannot use it. It's
also guarded by android.permission.BACKUP enforcement.)
dbTransport.java
oogleTransport.java
BackupTransport.aidl
|
| 8c850b792f2d371fd8a4aff146d9d757ee982539 |
08-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add IRestoreSession interface for the restore flow
Restore is a fairly complicated, somewhat stateful process, so we introduce
a new interface to encapsulate the various bits and pieces into a nicely
separable component. In particular, this will make it much cleaner to
open and interrogate an expensive-to-construct transport and then reuse it
for the actual restore process itself.
dbTransport.java
oogleTransport.java
BackupTransport.aidl
|
| b4a6188a74273611abcae05f3a3b1f0547548301 |
08-Jun-2009 |
Christopher Tate <ctate@google.com> |
Add rough-draft restore API set to IBackupTransport
* getAvailableBackups returns the list of backup sets available for restore
* getAppSet() returns the set of apps available from a given backup set
* getRestoreData() streams the full backup data for a given application
(within a given backup set) into a FD; that data will be handed to the
app's backup agent for processing.
dbTransport.java
oogleTransport.java
BackupTransport.aidl
|
| 7b88128e08ba45b071cd714dad9681ce66920d32 |
07-Jun-2009 |
Christopher Tate <ctate@google.com> |
Adjust IBackupTransport interface
Instead of just passing a package name to performBackup, pass the whole
PackageInfo struct, explicitly including the list of signatures for the package.
No need to make each transport look this up individually when it's a necessary
part of the backup payload for each app.
dbTransport.java
oogleTransport.java
BackupTransport.aidl
|
| 043dadc7516d20c3b3ccbcb20c53aaeef076a237 |
03-Jun-2009 |
Christopher Tate <ctate@google.com> |
More backup work
* Put in some permission enforcement around agent connection notification
and full-backup scheduling.
* Full backup now applies to any package, not just backup participants who
have declared their own android:backupAgent
* The process of running the backup operation on the set of apps who have
been queued for it is now done in a separate thread, with a notification
mechanism from the main Backup Manager service to pass along new-agent
binding knowledge. There's no longer one do-backup message on the primary
Handler per target application.
* The new backup thread sets up the desired transport now and passes
along the newly backed-up data to it for each backup target. Two
transports have been defined so far, GoogleTransport and AdbTransport;
both are stubs at present.
Note that at present the backup data output file seems to be properly
created, but after doBackup() is called on the test app's agent it's
still zero size.
dbTransport.java
oogleTransport.java
BackupTransport.aidl
|
| e10be807872a88f872bef96d1fd5a1d9f78af282 |
08-May-2009 |
Christopher Tate <ctate@google.com> |
Sketch out the IBackupTransport api
BackupTransport.aidl
|
| 487529a70cd1479ae8d6bbfb356be7e72542c185 |
29-Apr-2009 |
Christopher Tate <ctate@google.com> |
First baby steps towards settings backup
This change adds a sketched outline of the backup system architecture, with
all of the major pieces represented other than client-side helpers for
specific types of data. IBackupManager and BackupService are public so that
we can write test apps against SDK-domain symbols from the outset.
What code exists in this change hasn't been tested and may crash. It's the
beginnings of the real implementation but of course is barely begun.
BackupTransport.aidl
|