I am working on an reproducible build/sign/release system for Pixel 3 devices: github.com/hashbang/os
I plan on incorperating your work incrementally. Feel free to reach out if you want to collaborate at all, else just keep open sourcing stuff and I'll keep doing my thing :)
Conversation
Replying to
Using those driver packages won't provide fully functional builds and will break verified boot and some other security features. Most of the components in the vendor image are open source too, so if you want to build what you can from source you need to assemble it yourself.
2
Replying to
the new driver packages alone yielded me builds where all hardware seemingly works fine. Been painless so far. Working on verified boot and and a hashed manifest update system atm. Next is a system to publish signed builds and adapt your Updater to fetch them.
1
Replying to
Appears to work is a lot different than fully working. If you run the Compatibility Test Suite you'll see that what they provide it far from working properly. You could also just try using telephony features and you'll probably be able to find a lot of problems without the tests.
1
Replying to
LTE, BT, Wifi, screen, touch, audio etc work. Phone calls work but no phone audio. Will investigate compatibility suite. Going to try implementing phone audio fix from here: github.com/dan-v/rattlesn
1
Replying to
CTS will uncover much more than light manual testing. It's a very large test suite covering a broad set of APIs accessible via adb and apps including device managers. There's also the VTS for privileged testing but the CTS is already a lot of test coverage.
2
Replying to
1
Replying to
There's also the VTS but it's best to start with the CTS since it works with normal production user builds via adb and app level access including testing device managers, etc. It doesn't require privileged access and explicitly requires production user builds to pass the suite.
1
Some basic instructions: gist.github.com/thestinger/72d. There's more to it than that and there are tests requiring other setup to pass. Some tests are flaky if the device isn't totally stable (no vibrations) and on a good network with proper IPv6 support too.
1
I prefer running it module by module. You can use `list modules` (or the short form `l m`) to get a list, copy that to a text file and run them one by one if you want to do it that way. That lets you focus on the tests you care about first and it's manageable when it goes wrong.
1
For example, to test telephony stuff quickly: CtsTelecomTestCases, CtsTelecomTestCases2, CtsTelecomTestCases3, CtsTelephony2TestCases and CtsTelephonyTestCases. There are also telephony tests mixed in with other modules like CtsUsageStatsTestCases but those cover most of it.
The CTS tests most of the baseline functionality exposed via apps / adb. It doesn't test features like Wi-Fi calling, VoLTE, etc. that are beyond the basic functionality. Similarly, it doesn't directly test fancier camera features and other device-specific extensions, etc.
1
It doesn't have privileges beyond what's exposed via apps for most of the tests. The hosts tests use adb to go a bit beyond that, but it doesn't have priv apps or root so it can't do deep internal testing. It's extremely useful and catches many issues before they ship though.
1
Show replies