I won't be expanding it into a broader project without the appropriate funding / resources though. The scope is limited to integrating the hardened malloc implementation into AOSP and setting up proper builds of that. It won't be very usable/useful without fixing uncovered bugs.
Conversation
Simply doing all the debugging and release engineering necessary for production releases is a huge amount of work without even adding more privacy/security features and needs funding. It's too much work for one person unless it's their entire job, and I won't do it alone again.
2
3
Replying to
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 :)
1
1
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.
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.
1
Show replies