search

AOSPAlliance / android-prepare-vendor

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

Add missing firmware files for Pixel Ambient Listening on b4s4 API-29 #42

Closed CaseyBakey closed 3 years ago

chirayudesai commented 3 years ago

Hi,

I hate to be this guy, but could you please update the commit message itself to add a "b4s4: " at the front?

I would fetch this locally, run git commit --amend locally, and then git push --force git@github.com:CaseyBakey/android-prepare-vendor.git HEAD:b4s4_api29_full_configuration_missing_ambient_listening_files to update this existing PR without having to create a new one.

Thanks!

CaseyBakey commented 3 years ago

Here you go. This was tested and validated on sargo.

chirayudesai commented 3 years ago

Oh wait, how did I not notice this before?

Does this work now? Because it's all mixed up.

On bonito/sargo product is it's own partition.

So under system-other: you should only have system/ - same for system-bytecode For product/, use product-other and product-bytecode

CaseyBakey commented 3 years ago

Yep, as I said, I tested it on sargo.

Since I didn't notice anything mentioned in product-other and product-bytecode in any "full" configurations (sargo/bonito, blueline/crosshatch, started to look also flame), I didn't think about putting my findings there.

Feel free to rework my previous PR/commits if you prefer, but it doesn't seem to pose problems to have these files being in system-other/system-bytecode.

Pixel Ambient Listening is working fine on b4s4 and b1c1.

chirayudesai commented 3 years ago

Yep, as I said, I tested it on sargo.

Hah. Would you happen to have output logs from execute-all.sh by any chance

Since I didn't notice anything mentioned in product-other and product-bytecode in any "full" configurations (sargo/bonito, blueline/crosshatch, started to look also flame), I didn't think about putting my findings there.

That is because product is a new partition added in API29. We didn't work on any full configs for API29, thus those sections would've been empty. However, you will also see that only 'system/' files are present in 'system-bytecode'

Feel free to rework my previous PR/commits if you prefer, but it doesn't seem to pose problems to have these files being in system-other/system-bytecode.

I won't be able to test this right now, but in case you make any changes in the future, it would be good to have this in the right sections. For API 30, or another device, or just in general.

Pixel Ambient Listening is working fine on b4s4 and b1c1.

Since you're saying this works now, I don't mind merging it as it's a small fix after all.

I should've noticed this early on, and in the future we should fix it.

CaseyBakey commented 3 years ago

Hah. Would you happen to have output logs from execute-all.sh by any chance

No, not right now. I'll get back to my build machine next week and could do it at this time

On bonito/sargo product is it's own partition.

On blueline/crosshatch and flame also. I think all Pixels upgraded to Android 10 went to this partition scheme?

Btw, is product-other a thing? I don't see it declared anywhere, even when empty.

chirayudesai commented 3 years ago

Hah. Would you happen to have output logs from execute-all.sh by any chance

No, not right now. I'll get back to my build machine next week and could do it at this time

Np

On bonito/sargo product is it's own partition.

On blueline/crosshatch and flame also. I think all Pixels upgraded to Android 10 went to this partition scheme?

Yeah, only walleye/taimen didn't, they still have /system/product

Btw, is product-other a thing? I don't see it declared anywhere, even when empty.

It sure is! For example - https://github.com/AOSPAlliance/android-prepare-vendor/blob/android10/coral/config.json#L41