search

AOSPAlliance / android-prepare-vendor

Set of scripts to automate AOSP compatible vendor blobs generation from factory images
24 stars 8 forks source link

Android 11 support #12

Closed chirayudesai closed 3 years ago

chirayudesai commented 4 years ago

Let's

Devices: Pixel 2 family: #31

Pixel 3 family: (quite similar overall) #32 #33

Pixel 4 family: (basically identical in 10) #34 #35

Doing one device of the family should cover the others for the most part, would just need testing / validation at that point.

chirayudesai commented 4 years ago

First two: https://github.com/AOSPAlliance/android-prepare-vendor/pull/13

dan-v commented 4 years ago

Verified on crosshatch build, AOSP boots with upstream binaries - https://developers.google.com/android/drivers

danielfullmer commented 4 years ago

In case it is helpful, I have a WIP branch that I had previously built using the beta 3 image/tag for crosshatch. I've just rebased against the android11 branch here: https://github.com/danielfullmer/android-prepare-vendor/commit/dc5fd6a9e6492804e3825ab1de9d9c5d8e37cecf IIRC, the file list diff between the built image and google's upstream image looked OK with the above changes for beta 3. I never actually ran the built image, since my crosshatch device is my daily driver. There's also a big hack around excluding vintf files that I haven't looked into further.

When I tried using this against the recently pushed android 11 tag / crosshatch image, I have the following error:

system/chre/Android.mk: error: "chre (EXECUTABLES android-arm64) missing libsdsprpc (SHARED_LIBRARIES android-arm64)"

See also: https://android.googlesource.com/platform/system/chre/+/refs/tags/android-11.0.0_r3/Android.mk libsdsprpc.so is a prebuilt shared library included in the Google vendor image. It's not immediately obvious to me what the right way would be to to link chre against the prebuilt libsdsprpc.so.

chirayudesai commented 4 years ago

@danielfullmer it would be nicer if you could just replace the api29 bits instead of adding a new api30.

for libsdsprpc, we want something like https://github.com/TheMuppets/proprietary_vendor_google/blob/lineage-17.1/crosshatch/Android.bp or https://github.com/TheMuppets/proprietary_vendor_sony/blob/lineage-16.0/shinano-common/Android.mk

So here we want to put it in dep-dso, in the scripts look for DEP_DSO_BLOBS_LIST / HAS_DSO_MODULES

chirayudesai commented 4 years ago

One thing I've found helpful is looking at the file list on https://git.rip/dumps/google

E.g. https://git.rip/dumps/google/crosshatch/-/blob/crosshatch-user-11-RPB3.200720.005-6705141-release-keys/all_files.txt

It's from a beta but close enough right

dan-v commented 4 years ago

Update on my end:

danielfullmer commented 4 years ago

I also have another update on my android11 branch: https://github.com/danielfullmer/android-prepare-vendor/commit/885d0151672e009565ad87ca538d048ce813ed30

dan-v commented 4 years ago

I ran through devices=( blueline crosshatch bonito sargo coral flame sunfish ) and got rid of all the warning overrides and tried to match as close to factory vendor as possible (still a bit more work to do). I've also updated https://gist.github.com/dan-v/8fee2122b004ec1dd0971d4ebaff612f with a few more details and workarounds specific to coral/flame. I have factory images for all of these devices that I can share for testing. I personally only have a crosshatch device available for testing at the moment.

vendor diffs as of commit https://github.com/RattlesnakeOS/android-prepare-vendor/tree/1ec8d49874edbaf9bb3112597c45e69120789a2d

blueline and crosshatch vendor diff:
Only in /home/ubuntu/factory_images/blueline-rp1a.200720.009/vendor/etc/vintf/manifest: manifest_wifi_ext.xml
Only in /home/ubuntu/factory_images/blueline-rp1a.200720.009/vendor/lib: libprotobuf-cpp-full.so
Only in /home/ubuntu/factory_images/blueline-rp1a.200720.009/vendor/lib64: libprotobuf-cpp-full.so

bonito and sargo vendor diff:
Only in /home/ubuntu/factory_images/bonito-rp1a.200720.009/vendor/etc/vintf/manifest: manifest_wifi_ext.xml
Only in /home/ubuntu/factory_images/bonito-rp1a.200720.009/vendor/lib: libprotobuf-cpp-full.so
Only in /home/ubuntu/factory_images/bonito-rp1a.200720.009/vendor/lib64: libprotobuf-cpp-full.so

coral and flame vendor diff:
Only in /home/ubuntu/factory_images/coral-rp1a.200720.009/vendor/etc/vintf/manifest: manifest_wifi_ext.xml
Only in /home/ubuntu/factory_images/coral-rp1a.200720.009/vendor/lib: android.hardware.sensors@2.0-ScopedWakelock.so
Only in /home/ubuntu/factory_images/coral-rp1a.200720.009/vendor/lib: libprotobuf-cpp-full.so
Only in /home/ubuntu/factory_images/coral-rp1a.200720.009/vendor/lib64: libprotobuf-cpp-full.so

sunfish vendor diff:
Only in factory_images/sunfish-rp1a.200720.011/vendor/etc/vintf/manifest: manifest_wifi_ext.xml
chirayudesai commented 4 years ago

We can start to merge some / all of this into android11.

It's fine if it's not the cleanest since we're moving off this anyway (#15), and well this can be a considered a WiP branch right now anyway.

@danielfullmer your generic commits look good. @dan-v nice, I'll try and get them tested ASAP

dan-v commented 4 years ago

I cleaned up my commits and put up a PR for blueline, bonito, coral, crosshatch, flame, sargo, sunfish: https://github.com/AOSPAlliance/android-prepare-vendor/pull/21

@danielfullmer - could you put up a PR for walleye/taimen and any other fixes from your branch?

dan-v commented 4 years ago

thanks @danielfullmer !

chirayudesai commented 4 years ago

Thanks for the PRs, I went through them and left reviews.

One thing that came up is system_ext - should we add support for it here now?

Won't be too hard, should be the same as:

dan-v commented 4 years ago

The PR for blueline, bonito, coral, crosshatch, flame, sargo, sunfish (https://github.com/AOSPAlliance/android-prepare-vendor/pull/21) wasn't ready to merge yet. The latest commit in there (https://github.com/AOSPAlliance/android-prepare-vendor/pull/21/commits/6a58769ee4018e3a69bbdde28fe2d288a2b0073e) was untested and I just verified that crosshatch has issues with lots of things crashing including SystemUI. I'm reverting that commit on my branch, will do another crosshatch build, and if that works it might be better to go back to that commit.

Update 1: hmm, very interesting. I re-flashed with the factory image without this reverted commit and it is booting fine now. Something must have gone wrong with the OTA update process. I'll do some more testing of OTA updates and see if I can repro this issue.

Update 2: ignore this issue. I tracked down the OTA issue to me not including the required selinux rules for updater app that Daniel put together here: https://github.com/GrapheneOS/platform_system_sepolicy/commit/33fa92c37dd0101164a55ea1584cef6450fa641b.

chirayudesai commented 4 years ago

@dan-v let's just do per-device pair PRs now.

We can also just mark PRs as drafts when not ready to prevent an early merge.

Looking at https://github.com/AOSPAlliance/android-prepare-vendor/commit/6a58769ee4018e3a69bbdde28fe2d288a2b0073e

gee-one commented 4 years ago

Let me know if you need testing/logs from sargo. I built aosp with a vendor image created with this repo. So far, I can say that wifi calling works.

I can also build for other devices, but not test them.

gee-one commented 4 years ago

Tested with sargo at head 8868b90c6b5deeb814cdffd6eb9dfcba93b68422

I think this means that AVB/verified boot 2.0 is working?

sargo:/ $ getprop | grep veri                                                                                                                                                                
[init.svc.update_verifier_nonencrypted]: [stopped]
[partition.product.verified]: [2]
[partition.system.verified]: [2]
[partition.system_ext.verified]: [2]
[partition.vendor.verified]: [2]
[pm.dexopt.boot]: [verify]
[pm.dexopt.inactive]: [verify]
[ro.boot.verifiedbootstate]: [yellow]
[ro.boot.veritymode]: [enforcing]
chirayudesai commented 4 years ago

Awesome, thanks for testing!

WiFi calling is nice, that's new to us.

bonito should also be working then, that's two (more) devices done :D

gee-one commented 4 years ago

Wifi calling might vary by carrier. I tested on Ting which is a T-mobile MVNO. Other carriers might not have support for wifi-calling.

chirayudesai commented 4 years ago

Yeah my carrier supports it, works on stock / Lineage / other OSes. Here I think we might have missed some wfc app / libs first, and perhaps carrier settings #28 - that would be the two differences I can think of it.

chirayudesai commented 4 years ago

I created issues with testing checklist for all

31 #32 #33 #34 #35

chirayudesai commented 4 years ago

Looks like https://github.com/AOSPAlliance/android-prepare-vendor/issues/36 (the two linked issues) would affect all devices.

We should handle it here later, but for now remember to pick the fixes to your devices!

chirayudesai commented 3 years ago

This can be closed now, everything works, and this has been running fine for months!