The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Now with 100% less build break.
Bug 11716868
Change-Id: I2af4e93788068cfac97c0a48d3568c561eefa23d
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Bug 11716868
Change-Id: I4860fe3d4e99618b2cd194c83162bd7cbd5a83a9
We now expect that the transport service's host process will be
OOM-killed sometimes, but will come back automatically because we
still hold the binding. So, we no longer drop it as the
expected-to-be-current transport when that happens.
Bug 10728767
Change-Id: I5e756e8942e7c4c3567632f10460ee31b9618d75
...by making sure to drop binder identity before writing our new
state to secure settings etc.
Bug 10506933
Change-Id: I00505cc5215c8fe5f30f2f35698b30645fe14c87
Provide developer APIs to discover application-specific paths on
secondary external storage devices. Covers files, cache, and OBB
directories. Apps will not have write access outside their package-
specific directories on secondary devices, so only primary storage is
exposed through Environment.
Creation of .nomedia files will be handled by FUSE daemon in future
change.
Change-Id: Ifcce6201a686d80269d7285adb597c008cf8fa7c
When we've installed an apk from the archive, recheck whether
to apply the system-uid policy restrictions around file system
restores.
Bug 8833099
Change-Id: Ifa1b5877673a0d6ca6acf94e60f314fd0dda008c
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
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>
The bug was that when an app was uninstalled, the Backup Manager was
discarding its bookkeeping about that app being represented in the
device's current live backup dataset. This in turn meant that if the
app was subsequently reinstalled, its data would not be restored from
that most-recent dataset: it would be restored from the *ancestral*
dataset if possible, or not at all.
Now the "ever backed up" state is retained correctly, and the app
will get its most-recent-data restored as expected.
Bug 7394519
Change-Id: I733cf41737765676e0a3a05fb1bcd32b165cb4ba
Bug: 7368245
Log a warning if the system process calls unqualified sendBroadcast()
and other calls.
As a result of the logging above, found a few more method calls such as
bindService() that would benefit from being more explicit to avoid
future confusion and reduce the log warnings.
Change-Id: I17f15c8be9adf7becd456d6abbab606f19befdbf
Two distinct changes:
Fix a bug seen in the wild where a newly-launched application will be
spuriously asked to instantiate a backup agent. What was happening
there is that some Activity Manager state was being left stale in certain
circumstances, and then in combination with app uninstall / install, there
could be a case where uid reuse wound up looking like an app identity
match.
We now positively verify before instantiating the agent that the intended
backup target package is uid-compatible with the app process that the
instantiation was requested of. The incomplete bookkeeping in the
Activity Manager has also been tightened up, and the Backup Manager is
more aggressive about cleaning up pending operations pertaining to
apps being uninstalled.
Bug 5874010
Change-Id: Ic389f4a96c9dcd0ba6b3962b579084033d8ae9f8
(1) Prevent full restore from creating files/directories that are
accessible by other applications
(2) Don't restore filesets from "system" packages; i.e. any that runs
as a special uid, unless they define their own agent for handling
the restore process.
Bug 7168284
Change-Id: Id6a0cb4c113c2e4a8c4605252cffa41bea22d8a3
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
When building external storage paths, always include user in path
to enable cross-user paths and aid debugging.
Each Zygote process continues to only have access to the appropriate
user-specific emulated storage through bind mounts. A second set of
mounts continue supporting legacy /sdcard-style paths. For example,
a process running as owner has these mount points:
/storage/emulated_legacy
/storage/emulated_legacy/Android/obb
/storage/emulated/0
/storage/emulated/obb
Since Environment is created before Zygote forks, we need to update
its internal paths after each process launches.
Bug: 7131382
Change-Id: I6f8c6971f2a8edfb415c14cb4ed05ff97e587a21
When a restore dataset includes data for an app that used to have
a backup agent, but does not in the currently-installed version, we
were merrily trying to bring up the agent for restore anyway, and
crashing. Now we don't do that; we check whether there's actually
going to be an agent to handle the data before doing any of the
heavy work.
Bug 7130695
Change-Id: I0a38c2a8bb51d4a140a72d22896fa58d98ebaa02
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
For now only the device owner "user" gets cloud backups. Also, only the
device owner account has access to local backup/restore.
Bug 6956438
Change-Id: I87d7ba5969e606c23f4214469f9bf2fd47a6c61b
Previously, the setup app was responsible for telling the backup
manager through a side band that the user had passed through the
backup/restore-related portion of the setup flow. Now that the
flow has been streamlined and certain mandatory portions of it
are no longer relevant, we can ditch the whole idea of the backup
manager's internal "provisioned" state. This makes setup and the
setup "wizard" applications less fragile as well as eliminating
the possibility of unrecoverable "backup was never provisioned"
failure modes.
Now, the only check the backup manager has to do is against the
full "device is provisioned" flag, just like all of the other
components on the phone that only become usable after the setup
process has exited [such as phone calls].
Bug 6493520
Change-Id: I13ec8dd8baa1e74ed8569b0326219a98a7f632a9
This never worked properly; now it does. We also no longer
do a redundant pair of remove/add operations when a package is
updated.
Bonus memory savings: we were keeping sets of ApplicationInfo
objects as part of the ongoing bookkeeping, but those were no longer
being used for anything other than the package names. That's been
tossed out now and only the name strings are now used; hooray for
memory savings!
Change-Id: I4c6e592a1680e28550bcb4f76789260ded22280d
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
In particular, if the low-level zip or crypto layers of the output
pipeline throw, the output becomes invalid at that point, but we
were not properly detecting this; we were missing the exception and
the runtime was going down. Now we catch any such fatal exception
and make sure to shut down the backup operation cleanly, leaving
the output at whatever point in its construction that it had
achieved.
Bug 6131870
Change-Id: If0fe0337857404b776f407a79d11dd88b8e60fd0
Fixes a crash that would occur if an app with a pending backup
pass in the pipeline was updated to remove its agent declaration
from the manifest (or other more esoteric ways that a backup
pass was expected to run for an app without their own agent).
Bug 5776591
Change-Id: I5a8bc8c12de6a2bfa82f5093fe3a15b754109ab1
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
The special shared-storage step was mistakenly writing its data directly
to the USB output pipe rather than to the proper stacked data handling
chain that applies compression and encryption. Fix this by getting rid
of the custom handling of the shared-storage data, instead folding it
into the normal data handling flow [with a small amount of additional
management because e.g. it doesn't need a "manifest" pseudofile in the
archive stream].
Fixes bug 5897791
Change-Id: I3995b07963334d2f8cce49b247c87d3d3ff93bed
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
In particular, don't do O(asec_apps * installed_apps) work during the
broadcast receiver's operation. On devices with many installed apps
and a large number of them moved to ASECs, this was causing the system
process to become unresponsive and the watchdog to fire -- which in turn
would initiate a restart loop, as the same package-installed broadcast
would then be issued again once the package manager rescanned the ASEC
containers, ad infinitum. With this change, the expensive call to the
package manager is only made once rather than asec_apps times.
Bug 5850283
Change-Id: I14e280ea1fa6af19cebc58869a20fbb599c92c8c
This supersedes any backup-password that the user might supply. Per
design, the device encryption password is also always used to encrypt
the backup archive.
The CL introduces two new strings, used for prompting the user for
their device encryption password rather than their settings-defined
"backup password" when confirming a full backup or restore operation.
Bug 5382487
Change-Id: I0b03881b45437c944eaf636b6209278e1bba7a9f
Although it's typical for a backup transport to report that it
needs an explicit initialization opportunity when the backup is
initiated, it can sometimes come to pass that the "needs init"
error condition is reported at backup *finish*. In this case the
framework side was failing to properly reset all of the relevant
state. The end result was to spin hard forever, holding wakelocks
and continually failing to actually perform the necessary init
operation, possibly continuing even after a reboot. Fixed.
Bug 5434579
Change-Id: If1d72c338526e4019ea524c48a11e71e44e77f71
We've seen cases (bug 5417779) where the transport kicked off an immediate
backup operation but then was perfectly content to allow the periodic
timer to start *another* pass concurrently while the first was still in
progress. This wound up with the backup manager getting mightily
confused and leaking wakelock acquisitions, which is Very Bad(tm).
This patch adds a little bookkeeping so that the backup manager is aware
of backups in flight, and refuses to kick off a new one until the ongoing
one has finished.
Change-Id: If12b54f4db3effc8af36d31c58d8f9b415ddc01e
This makes it easy to back up everything that belongs to 3rd party apps, but
nothing that comes with the system per se. If any system packages are
explicitly named on the command line they will be included in the backup
even if -nosystem was passed. So, for example, this will back up all 3rd
party apps as well as system settings, but nothing else belonging to
system-deployed apps:
adb backup -all -nosystem com.android.provider.settings
Bug 5361503
Change-Id: Iebe04b7d7027ca58b9f55e8eb7f219d6cca69269
The text of the dumped output can potentially include an email address;
we don't want random code to be able to read it.
Bug 5389201
Change-Id: If84886357a36b7015878e4d72017abba83b4c511
Casualty of the recent refactoring: in this particular error case,
the restore sequence wasn't being directed into the finalization
state. Fixes bug 5336295.
Change-Id: Ibf5570cd1003e123da8b561685de8479663340ce
On the restore side, there's a bunch of one-time setup, device
provisioning, etc that we're very much not prepared to do in
lieu of running setup wizard, at least at this time.
On the backup side, it simply doesn't make sense to back up
stuff before the device has been set up.
Part of bug 5290261
Change-Id: If1c65e88e2da589d6204232d2b59c3e994f4ed3f
