previously marked as @Ignore.
The test was bad because it set 11 as the ancestral serial number for
the system user UserBackupManagerService but asserted that 11 corresponds
to user 1 - which is not the system user. This CL fixes the assert.
Also added corresponding test for non system user.
Fixes: 147012496
Test: atest com.android.server.backup.BackupManagerServiceTest
Change-Id: Iab736885264aa4befc644678e5fe66d602ed00e3
Currently backup dumpsys in bugreport only contains information
for system user making it hard to debug backup bugs in non-system
users. Therefore, add dumpsys information for all users running backup.
For system user, keep the dumpsys format the same for compatibility with
cts and gts tests. For non-system users, add a prefix "User <userid>:"
to all dumpsys headers.
The changes in Android.bp and AndroidManifest.xml are to support mocking
of the static method DumpUtils.checkDumpAndUsageStatsPermission in the
test testDump_systemUserFirst
Bug: 143867387
Test: atest com.android.server.backup.BackupManagerServiceTest
Test: atest com.android.server.backup.UserBackupManagerServiceTest
Test: adb shell pm create-user test1 -> say this gives 11
adb shell am start-user 11
adb shell bmgr --user 11 activate true
adb shell dumpsys backup users -> "Backup Manager is running for users: 0 11"
adb shell dumpsys backup -> contains both
"Backup Manager is enabled / setup complete / not pending init" and
"User 11:Backup Manager is disabled / not setup complete / not pending init"
adb shell pm remove-user 11
Test: "adb bugreport" on device with secondary user as created above and check that result
contains dumpsys for both system and secondary users.
Test: atest -v CtsBackupTestCases
Test: atest -v CtsBackupHostTestCases
Change-Id: Ib94c168f8e89b0ba8f398152ea744fe3d626efc4
Bug: 144431410
Test: 1. atest BackupHandlerTest
2. Manual (with and without the fix):
1) Locally create a host-side CTS test that extends
BaseMultiUserBackupHostSideTest
2) Modify the test so that it creates a user, starts backup
init and removes the user
3) Add log in BackupHandler to indicate when an exception is
suppressed.
3) If the fix is applied, verify the crash doesn't happen and
the log message from 3) is present. If the fix isn't applied
verify that the crash happens.
After backup service for a user is stopped, leftover work on the
corresponding BackupHandler can throw exceptions. If uncaught, they
can crash the system process. Catch all uncaught BackupHandler
exceptions after the backup service has entered the stopping state, to
allow any leftover work to finish harmlessly.
Change-Id: I8c233ad0e117ec0ae65599a762d87f15f8a3cec2
1. the private members in BackupManagerServiceTest were all unused
2. remove TODO for b/124359804 which is marked as wont-fix.
3. remove adb backup multi-user TODOs as adb backup is deprecated and we
don't intend to extend multi-user support to it.
Bug: 136738613
Test: m -j
Change-Id: Ia4c6ebce7b9bb7ab8bfe1f6a18f9b67ec6098cd2
Currently this variable gets picked up by simple scans for work
labelled TODO. By renaming it we can use simple filters to find
work in need of doing.
Bug: None
Test: atest BackupFrameworksServicesRoboTests
Change-Id: I5a5b5c6e49febae2636b6b4dc97ab3e922aa3eef
Use enforceCallingOrSelfPermission which is the same as
enforceCallingPermission except it grants own permissions
when not processing an IPC.
Also remove unused private field from KeyValueBackupTask
Bug: 146939599
Bug: 136738613
Test: 1) adb shell bmgr enable true
2) adb shell bmgr enable false
3) adb shell am broadcast -a "android.app.backup.intent.INIT"
logcat is as expected:
BackupManagerService: Backup enabled => false
BackupManagerService: Running a device init; 3 pending
BackupManagerService: initializeTransport(): [com.android.localtransport/.LocalTransport, com.google.android.gms/.backup.migrate.service.D2dTransport, com.google.android.gms/.backup.BackupTransportService]
BackupManagerService: Initializing (wiping) backup transport storage: com.android.localtransport/.LocalTransport
....
BackupManagerService: Initializing (wiping) backup transport storage: com.google.android.gms/.backup.migrate.service.D2dTransport
...
BackupManagerService: Initializing (wiping) backup transport storage: com.google.android.gms/.backup.BackupTransportService
Change-Id: I98d87f3163cd7fbc1f7aa6712ec421cc8efd5d29
backup.
Bug: 144155744
This solves a bug which makes staged installs hang. This is
happening because when installing, the PackageManager is waiting for a response to be sent back from
the BackupManagerService after it finishes restoring. In the case of staged installs which happen at boot,
isUserReadyForBackup is false, so the method does nothing and the
PackageManager keeps on waiting on a response.
Test: 1) atest RunBackupFrameworksServicesRoboTests and atest AutoRestoreHostSideTest
2) Manual:
- Applied ag/9722795
- run `atest com.android.tests.rollback.host.StagedRollbackTest#testStagedInstallHang`
- The log file doesn't contain any "Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in handler on main thread (main)".
Change-Id: I294c309b0c7e5a9e12bdbd0c3fc4946767f91cee
Pass the list of the keys excluded from KV restore to the backup agent to make it aware of what data has been removed (in case it has any application-level consequences) as well as the data that should be removed by the agent itself.
Bug: 145126096
Test: atest CtsBackupTestCases
Change-Id: I34415b149b379fb5bb67b0fbcd70ec9b9858acfe
Thisis the NPE bug we saw a while ago but it has been coming up in test runs recently (b/). Let's fix the NPE for now and we can work on the underlying issue later.
Bug: 136730045
Test: atest DataChangedJournalTest
Change-Id: I7267f507be4c797491d86ebb8bc5e6c3c17652a3
Add the method as a hidden API for now. Move to System API later.
Bug: 145126096
Test: 1. Call BM#excludeKeyFromRestore for a test package
2. Reboot the device
3. Run restore for the test package
4. Verify excluded keys are not restored
Change-Id: Ice57299eaf54cee8428b86e2d4f78de12b8db4fc
We will route backup through the BackupEncryption APK which will
implement an intermediate transport which will encrypt (or decrypt) the data when
sending it (receiving it) from the real transport.
Since both backup services and IntermediateTransport need to bind to
IBackupTransport, they both need the transport client code so we move that
into its own lib.
Bug: 139269919
Test: atest -v RunBackupFrameworksServicesRoboTests
Test: atest -v $(find frameworks/base/services/tests/servicestests/src/com/android/server/backup -name '\''*Test.java'\'')'
Test: atest -v CtsBackupTestCases CtsBackupHostTestCases
Change-Id: Id986162ac71adf8638e5797169ef70e0d3d58b0c
If an exception which isn't in the IOException hierarchy gets
thrown within this code it can bring down the system_server, so
we should capture and log any exception rather than letting it
propagate out and bring down system_server.
I decided not to capture all Throwables because they represent
more serious runtime errors that probably should bring down
system_server.
Fixes: 140472631
Test: m -j (compilation means we're OK).
Change-Id: Ibbd9612d1e9b42c100ce7fda0b7463ac3f10704e
Perform the merge by:
1. Moving lifecycle inside Trampoline without IDE support
(since we'll rename Trampoline in this CL as well, making the published binder
the same).
2. Move constants to Trampoline without IDE support as well (again, we'll
rename Trampoline).
3. Change the last usages of BMS constructor to use
Trampoline's. Now BMS is effectively empty.
4. Delete BMS.
5. Rename Trampoline to BMS with IDE support (renaming related classes
and variables that the IDE could find).
6. \o/
Split CL into Path Sets to ease review:
Base > PS2: Steps 1..4 (+121 -333)
PS2 > PS4: Step 5 (+214 -204)
Test: m -j
Test: adb shell dumpsys backup
Test: atest BackupManagerServiceTest BackupManagerServiceRoboTest
Bug: 135661048
Change-Id: Ia6cd340d3c5fcdb9c8f409035d032efeb090cd20
From BMS. Moved mUserServices list creation from BMS to Trampoline.
BMS still uses it but the plan is to move gradually in multiple
CLs to eventually delete it. Both are dealing with the same instance
because of this. Start and stop of sub-system (uBMS) is now handled in
Trampoline. getUserServices() was also moved. BMS robolectric tests were moved
to Trampoline *robolectric* tests to simplify this CL. After we merge BMS and
Trampoline, we can look into moving tests away from Robolectric.
Test: atest BackupManagerServiceTest TrampolineRoboTest TrampolineTest
Bug: 135661048
Change-Id: I4e612d06fe006c12f215a94f210450a5e6316b75
From BMS.
Test: Inflate user 11 then remove it, make sure directory /data/backup/11 is
removed
Bug: 135661048
Change-Id: I482e7fb4c8ccd630ab812a396d3570be996c2a62
This manually cherry picks ag/8713360 into master. I had to do a manual
cherry pick as the cherry pick from gerrit fails with:
"Could not perform action: Cannot create new patch set of change 8677635
because it is abandoned"
Currently we call .quit() on the underlying thread which will cause all
messages to stop being processed. This has the side effect that, because
the backup system is a state machine where the state transitions are
messages, the message to transition into a state where the WakeLock is
released may not occur when a user is torn down.
This change adds a stop method we can call instead of .quit() on the
thread which drops any remaining messages and then releases the
WakeLock.
We also wrap the wakelock acquire/release calls to prevent any acquire/release on
the underlying wakelock after a quit. For the acquire, this avoids a non-released
wakelock and for the release, this avoids a runtime exception which can happen
when we release a released wakelock
Test: atest CtsBackupTestCases CtsBackupHostTestCases
Test: m RunBackupFrameworksServicesRoboTests && atest RunBackupFrameworksServicesRoboTests
Bug: 136264323
Change-Id: Ic8742bf01a0ff71bd57dd73b01a423d3432bf7b2
After multi-user BMS became a lightweight class as well, so no need to
lazily initialize it. This lays the ground for unifying Trampoline and
BMS.
Test: atest TrampolineTest
Test: adb shell bmgr backupnow <package>
Bug: 135247112
Bug: 135661048
Change-Id: Ia7f69d2ed282c6dfe6443a601f27229d43802fe6
The filesystem is checked when the BMS is created for a user so we
don't need to recheck it every time we perform a backup related
operation because wihout the BMS we shouldn't say the system is
read for the user to back up their data.
Change-Id: Iaaa7d7381182ba7e05173cc4f5d25ce61054e210
Test: atest CtsBackupTestCases CtsBackupHostTestCases TrampolineTest BackupManagerServiceTest
Fixes: 133584471
