It is possible to have multiple committed rollbacks which include the
same app.
Uninstalling an app will delete committed rollbacks which include
the app. However, there is a race condition between when the app is
uninstalled and when rollback manager deletes the rollback as is stated
here:
https://cs.corp.google.com/android/frameworks/base/tests/RollbackTest/RollbackTest/src/com/android/tests/rollback/RollbackTest.java?rcl=75dfeca3d40624b745f41155aa38bc5e3fa405fe&l=116
We hit the assertion in #getUniqueRollbackInfoForPackage when there are
multiple rollbacks including the same package which is caused by the
race condition above.
Let's rewrite the code by calling #hasRollbackInclude instead which will
not throw.
Also do some cleanup in the xml to improve the isolation of our tests.
Bug: 152271716
Test: atest RollbackTest
Change-Id: Iad3effe52db2a0d2d5e3914bcd08ed93926f3fd3
https://g3doc.corp.google.com/experiments/g3doc/mobile/phenotype/android/testing.md?cl=head#hermetic
Phenotype talks to a server to override the device config changes made
by the tests. Therefore, rollback expiration didn't happen as expected
and caused the test to fail.
We need to override the flags on our own during tests so the
device config values ('rollback_lifetime_in_millis' in this case)
won't be changed in an unexpected way.
Note this is the same fix as ag/10467568.
Bug: 151890602
Test: atest RollbackTest
Change-Id: Ie884e4807999d105f6224c46a39434e1f437ed1b
When tradefed fails to run a test, it will try to recover the device
which might lead to another reboot. This interferes with our test
flow which also involves reboot. See b/150749023#comment2 for more
details.
Let's rewrite the test to prevent auto-recovery of tradefed from kicking
in. Generally, it is a bad practice to depend our test flow on a failed
test due to reboot. We should call #waitForDeviceNotAvailable to wait
for reboot to happen and then call #waitForDeviceAvailable before
continuing next tests.
Bug: 150749023
Test: atest StagedRollbackTest#testBadApkOnly
Change-Id: Ia39630585c3b7344174a8c66d0a33f05a2d80cc7
Somehow rollbacks related to testappA are not cleaned before running the
test and cause test failures. See b/150653097#comment2 for more details.
Let's clean rollbacks manually to have a clean start.
Bug: 150653097
Test: atest MultiUserRollbackTest
Change-Id: I4eb126e193f76c821d26fc62115263b86066a215
https://g3doc.corp.google.com/experiments/g3doc/mobile/phenotype/android/testing.md?cl=head#hermetic
Phenotype talks to a server to override the device config changes made
by the tests. Therefore, watchdog timeout didn't happen as expected and
caused tests to fail.
We need to override the flags on our own during tests so the
device config values ('watchdog_request_timeout_millis' in this case)
won't be changed in an unexpected way.
See b/148042585#comment21 for more details.
Bug: 148042585
Test: atest NetworkStagedRollbackTest
Change-Id: I4d8944f7fef93445de8f971c6a96fef7c71872db
In the cases that a logging parent cannot be found for any packages
in a rollback, the watchdog event should still be logged. Ensure
that the state of a rollback is captured on boot by removing the
condition of only saving a rollback id if there is a logging package,
and by adding a symbolic null package to the list of logging packages
on boot if none were found. Expand tests to verify.
Bug: 149957011
Test: atest StagedRollbackTest
Test: atest NetworkStagedRollbackTest
Change-Id: I56f8afb6730e59fbe67ea8747e0da3aca19a0d8a
'-g' to grant permissions automatically without checking the API level.
This works around the issue of b/149733368#comment2.
'--user all' to install the app on all users. This is more efficient
than calling #installPackageAsUser one by one on each user.
Bug: 149876119
Test: atest MultiUserRollbackTest
Change-Id: Ia5d85d3c13925ae969ffab9319360c1fefe1f950
My local test shows that switch-user doesn't work on my physical device.
In fact there are APIs to run tests against a particular user without
switching. It also speeds up tests without switching users from time to
time.
Bug: 149876119
Test: atest MultiUserRollbackTest
Change-Id: I34d26ddcb6a6e9cdc39228310830a3cd83212e4a
Sometimes RollbackManager is slow in making rollbacks available.
Let's give it enough time to do the job and make test less flaky.
Bug: 149876119
Test: atest MultiUserRollbackTest
Change-Id: I0a64e2dcde1f5e6dae618cacd6546ad953c1aca7
Don't reboot the device when there is no file to delete. This saves us a
significant amount of time since each reboot takes 1 min and there are
dozens of reboot during the whole test case.
Bug: 149528114
Test: atest StagedRollbackTest
Change-Id: If3b06a304d9c87680c7cc5b7498d3b2ecf11cdfa
By classifying the tests into 2 categories, we can:
1) run remaining tests with network disabled to reduce the interference
of network crashes.
2) make it easier to identify bugs caused by network stack or
problems in rollback infra.
Note this CL contains stubs only. We will move actual test code later.
Bug: 147785893
Test: m
Change-Id: I5ecc63a057e9a115ea3aa446970a3f20dff750d0
Use the logcat output of WatchdogRollbackLogger as an indication
that the expected log events are sent to statsd.
Bug: 138782888
Test: atest StagedRollbackTest
Change-Id: I9a9d48da1cb1926186b2feedd0b78ab1bbd14fdf
This adds a test for rolling back device encrypted (user) apex data,
similar to the tests previously added for DE_sys and CE data.
Bug: 141148175
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_DeUser
Change-Id: I632957449e4aa4f93df2e8bf0ae541937472d9fe
This adds tests in StagedRollbackTest for apex data directory rollback.
The test performs the following steps:
- Push files into the apex data directory
- Update the APEX with rollback enabled
- Remove files from data directory
- Add new files to data directory
- Roll back the update
- Verify old files are restored
Bug: 141148175
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_DeSys
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_Ce
Change-Id: Ie1e7ed626c0b654c19b23bfcb008ac4d717aafe2
* changes:
No need to call #updateRollbackLifetimeDurationInMillis (3/n)
Register an OnPropertiesChangedListener in onBootCompleted (2/n)
Squash runnables in onBootCompleted (1/n)
This reverts commit 400124c6aecf5cfcd06f101d2260c016f3b6cae5.
Reason for revert: Fixed the compile error; TestAppACrashingV2 was not
available to com.android.apex.apkrollback.test_v1
Change-Id: Ic443e913b837c9bb2716678521ad1d12d3bc7e4d
This reverts commit d56ce0003926fd9ee7d358cb45f8af7f562a33d6.
This revert is to fix the wembley build.
Test: Local wembley build
Change-Id: I651f20ffc6ba11cced5a2a737fd3d77211127221
Due to b/147666157, this CL will only work as long as an apk is not
embedded in two different apex.
Bug: 142712057
Test: StagedRollbackTest#testRollbackApexWithApkCrashing
Change-Id: I60f7f70b627fd380094a11373259debddd5dc532
* changes:
Allow handling of all pending staged rollback sessions before rebooting
Add test for verifying all available rollbacks are triggered during native crash
No need to call #updateRollbackLifetimeDurationInMillis manually inside
reloadPersistedData. Also fix tests since #reloadPersistedData no longer
pulls DeviceConfig changes.
Bug: 147712943
Test: atest StagedRollbackTest RollbackTest
Change-Id: I7579d6c969117189e01e0767decd1faeaa811eb9
When there is an unattributable native service crash during boot, we
rollback all packages available for rollback. In the current
implementation, we reboot immediately when a staged rollback session
becomes ready, even though there can be other staged rollback sessions
which are still being handled.
In this CL, the logic is changed to allow the health observer wait for
all staged sessions to be handled before rebooting.
Bug: 141843321
Test: atest StagedRollbackTest#testNativeWatchdogTriggersRollbackForAll
Test: atest StagedRollbackTest
Change-Id: Ib2aaee22868e5502b68847aa7f64e428070f7e3c
Currently, the RollbackManager is not aware of the apk-in-apex being
installed since the install is done by PM during scan phase of boot. As
such, RM does not backup the user data of the apk-in-apex.
In the new implementation, we ask the RM to snapshot/restore user data
of apk-in-apex while resuming the apex session in StagingManager.
Bug: 142712057
Test: atest StagedRollbackTest#testRollbackApexWithApk
Test: atest AppDataRollbackHelperTest
Test: atest RollbackStoreTest
Test: atest RollbackUnitTest
Change-Id: Ibbaa5d0c98cb883588c085d77bc89c3e8217d76a
testNetworkPassedDoesNotRollback leaves a rollback for the network stack
and we need to clean up all rollbacks before running
testNativeWatchdogTriggersRollback otherwise the test will fail on
devices which doesn't support checkpoint.
See b/146991129 comment#2 for the detail.
Bug: 147259494
Test: atest StagedRollbackTest
Change-Id: Ib9c5e3f56bf31bfbf6f5a415879f9eb1b10d270e
The test is rewritten as testNetworkFailedRollback was in ag/9648485 to
empoly more device methods for better logging and debugging.
Bug: 147259494
Test: atest StagedRollbackTest
Change-Id: I4104d20296dee4abba2996f8f9e3b47e258bf6a9
1. Don't snapshot user data when the policy is WIPE.
2. Add tests to verify user data is wiped/restored correctly.
Bug: 144683152
Test: atest RollbackStoreTest RollbackUnitTest AppDataRollbackHelperTest
Test: atest RollbackTest StagedRollbackTest
Change-Id: I470233080efbba724ace6f0dbf2ab5256db49054
When multiple staged sessions are installed on a device which doesn't
support checkpoint, only the 1st will prevail. The test failed when
TestApp.A is not the 1st rollback to commit.
We need to clean up the rollback left by testRollbackWhitelistedApp so
TestApp.A is always the only and first one to commit.
Bug: 146991129
Test: atest StagedRollbackTest
Change-Id: I4afdace934b7b7e3b198169dc2eb0da66c65eb94
Mitigation attempts should be made whenever rollbacks are available.
Bug: 141843321
Test: atest StagedRollbackTest#testNativeWatchdogTriggersRollback
Change-Id: I2dde8c6415191ff3787a82ea3abc0fcc9a3cd7b1
The rollback shouldn't be available if any of the child sessions times
out in enabling rollback.
Bug: 144732395
Test: atest RollbackTest
Change-Id: Id899f3c1ec100fcdcad1f24f2701f95b1c49bc69
The network stack module may be implemented by NetworkStack (updatable
version built against stable SDK) or NetworkStackNext (test version
shipped only in system images, built against in-development SDK).
Bug: 144168912
Test: atest RollbackTest
Change-Id: I1788e323f763ca88b69b082f38078bee3bfe480d
My local tests show that sometimes testNetworkFailedRollback_Phase3
fails to reboot within 120s. Since it takes 120s to fail the health
check and trigger rollback, there is not much time left to finish
shutdown and begin reboot before finishing sleeping.
Let's generously give it 120 more seconds so shutdown and reboot have
enough time to take place.
Bug: 143999213
Test: atest StagedRollbackTest
Change-Id: Icf3a5583a906da312189a6d027a5c269e2fd8d46
This patch improves test isolation.
Sometimes a previous test fails with reboot in progress. Then the next
test is in an unstable state since reboot could happen at any moment and
fail the device test.
Doing a reboot before each test starts protects us from pending reboot
from the last test and improve isolation.
Bug: 143999213
Test: atest StagedRollbackTest
Change-Id: Idd0fd1cc6810659990b406640efd7404de1dcd07
1. Wait for 120s for reboot to happen. This improve the stablity of
virtual devices which sometimes could be slow in shutdown.
2. Use assertThrows to catch exception when reboot doesn't happen which
gives us better error messages than expecting next phase to fail.
Bug: 143999213
Test: atest StagedRollbackTest#testBadApkOnly
Change-Id: Ibafcbe7e003fb92991d6f8fe2fde7b344ffd6db6
Reconnect internet so we won't break tests that assume internet is
available.
This is a patch to fix the regression caused by ag/9648483.
Bug: 143514090
Test: atest StagedRollbackTest CtsLibcoreTestCases:DatagramChannelMulticastTest
Change-Id: Ic0ef26027388500795b3555f5a56f82bfc1b975e
Install#commit ensures a staged session is ready before the function
returns. So we don't need to sleep to wait for disk IO to complete.
Bug: 143211397
Test: atest StagedRollbackTest
Change-Id: Ic4b53dc5aaef7a22d7d64c14ee4f77bee84c26b1
This is an effort to fix flaky StagedRollbackTest.
ag/9614192 adds support for native file path to TestApp so now we can
install network stack package using install.lib which provides better
tools for logging and synchronization than shell commands. This will
facilitate debugging flakiness.
Also move other code to device tests for the same reason.
Bug: 143211397
Test: atest StagedRollbackTest
Change-Id: I971618da3defade4693be154ab523f1cbfea5b7c
This is an effort to fix flaky StagedRollbackTest.
My local tests show that the crash has something to do with repeatedly
turn on/off network connection for each test. Several things are done
below to reduce the flakiness:
1. Disable testNetworkPassedDoesNotRollback
It sometimes takes more than 5 minutes for the device to be back
online after turning on the network connection during the test. This
test contributes a lot to the flakiness. Let's disable it for now so
other tests can keep running.
2. Rewrite testNetworkFailedRollback so we only turn on/off network
connection when necessary in the hope to reduce the WifiHandlerThread
crash. The change works pretty well for my local tests which run over
40 loops without a single failure.
Bug: 143514090
Test: atest StagedRollbackTest
Change-Id: I9aec5eafdd3368ef76517e3b8500970e60d07487
b/143035398 #3 shows the network stack will pass health check anyway
even there is not internet connected. We have to reduce the timeout and
finish the test before the health check is passed.
Bug: 143035398
Test: atest StagedRollbackTest
Change-Id: I39a84b06a19648a3ec19c5f334bed9ef4bce1533
