To fully pass the CTS, you need to have a non-test-key-signed release / user build. Something that amuses me is that the public CTS build published by Google isn't signed with release keys and it gets mad about the apps it sees using the test key that it installed itself.
Conversation
Can build it from source and properly sign it or just ignore those couple test failures though.
1
1
grapheneos.org/build#compatib has a quick guide on using their public builds. In the CTS test harness, `run cts --skip-device-info --module CtsBackupTestCases` will run the backup tests.
Those definitely pass on a user build and it does backups/restores via LocalTransport.
1
1
Replying to
right, I'm reading the CTS sources right now but so far I don't understand how it actually pulls/pushes the data
1
Replying to
I think it's a set of app-based test suites that are installed and run on the device rather than host tests, and it just triggers LocalTransport via adb and then does most of the work via the code running on the device. I'm normally just running the CTS tests, not writing them.
1
android.googlesource.com/platform/cts/+ is the metadata telling the CTS test harness what to do including the app-based test suites to install and run together. In many cases it cheats via adb tricks like granting minor 'development' permissions that must be granted via adb shell.
1
Replying to
I *think* that test suite never actually pulls any data to the host? it just uses a lot of apks to exercise the transport, and matches logcat messages for what it can't do that way
2
1
so you don't need adb_root to trigger it (which I knew) but you do seem to need adb_root to actually get a hold of the data
1
1
Replying to
Ah, interesting. It's not as useful as I thought without a way to get the data on a user build. What I really don't understand is why adb backup is so horrible and why it's even adb functionality instead of a proper feature for end users based on an actual backup service.
1
3
Fwiw, you can get adb root on user builds as is documented for VTS here: source.android.com/compatibility/
1
It makes it a lot more accessible for people using the stock OS with an unlocked bootloader.
I'd much rather have a userdebug build with ro.adb.secure=1 on a locked device than a user build on an unlocked device in terms of security though.
Yeah, this definitely doesn't seem to be intended for production or with security in mind.
Theoretically, if you're willing to suffer, you could pull data without root by catting the file over adb shell and redirect into a file on the host, but iirc it would be painfully slow.