Adding GApps to OTA without rooting

[xabolcs]

I'd like to reproduce that MEETS_STRONG_INTEGRITY from #80.

---

I have a Spacewar device and started with crDroid so GApps have to be installed separately.

How should I add GApps to system.img?
As I read the avbroot's help, it will be able to use that GApps-ed system.img to include the OTA.

But how should I add GApps to system.img in the first place?

Simply mounting it and copying into the files would be enough? Is it possible to sign that modified system.img with avbroot?

$ file extracted/system.img 
extracted/system.img: Linux rev 1.0 ext2 filesystem data, UUID=7361ef05-b700-5aec-a595-852e3b4af607 (extents) (large files) (huge files)

Thanks!

[chenxiaolong]

MEETS_STRONG_INTEGRITY

Unless your device has a buggy bootloader, this is unfortunately impossible. With hardware attestation,
the bootloader reports four (unspoofable) fields containing details about the device state. It not only reports whether the bootloader is locked, but also the hash of the public key that was used for signing. If this doesn't match the stock OS, Google Play Integrity will not grant MEETS_STRONG_INTEGRITY.

---

To answer your questions specifically though:

Mounting system.img and copying files is indeed the easiest way to do it. This is the full workflow that I would suggest, which will automatically take care of everything AVB-related (including signing and recomputing hash trees and error recovery data):

# Unpack AVB metadata
avbroot avb unpack -i system.img

# Mount and edit raw.img (which is system.img with the AVB metadata stripped out)
sudo mount system.img /some/mount/point

# Repack and sign the modified image
avbroot avb pack -o system.modified.img -k /path/to/avb.key

# Patch OTA zip and replace system.img
avbroot ota patch \
    -i ota.zip \
    --replace system system.modified.img \
    <other patch args...>

Note that some system.img images are formatted in a special way and use an Android-specific EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS flag. When this flag is enabled during formatting, certain space-saving things are done, but it makes the image permanently read-only (because certain data is shared and editing it would corrupt the filesystem). AOSP and most stock OS' enable this, but I don't think LineageOS does (so hopefully crDroid doesn't as well).

[chenxiaolong]

Awesome, glad you got it working!

[xabolcs]

Hi!

Sorry for bumping this thread, but there is a bug with that unpack software I found. 😕

Thankfully I found a usable tool for this: Android_boot_image_editor

Just a note about that Android_boot_image_editor: one should find a tool which correctly manages those img files! 🙃

This one is not perfect, as the symlinks are extracted as a textfile (containing the target as plain text, like git stores symlinks) and causes error, like below:

03-14 16:19:50.548 30707 30707 E AndroidRuntime: FATAL EXCEPTION: main
03-14 16:19:50.548 30707 30707 E AndroidRuntime: Process: org.codeaurora.ims, PID: 30707
03-14 16:19:50.548 30707 30707 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: "/system_ext/priv-app/ims/lib/arm64/libimsmedia_jni.so" is too small to be an ELF executable: only found 36 bytes
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at java.lang.Runtime.loadLibrary0(Runtime.java:1082)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at java.lang.Runtime.loadLibrary0(Runtime.java:1003)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at java.lang.System.loadLibrary(System.java:1661)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at com.qualcomm.ims.vt.ImsMedia.<clinit>(ImsMedia.java:202)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at com.qualcomm.ims.vt.ImsVideoGlobals.<init>(ImsVideoGlobals.java:66)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at com.qualcomm.ims.vt.ImsVideoGlobals.init(ImsVideoGlobals.java:35)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at org.codeaurora.ims.ImsService.setup(ImsService.java:42)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at org.codeaurora.ims.ImsService.onCreate(ImsService.java:71)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.app.ActivityThread.handleCreateService(ActivityThread.java:4692)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.app.ActivityThread.-$$Nest$mhandleCreateService(Unknown Source:0)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2289)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:106)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:205)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:294)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:8244)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
03-14 16:19:50.548 30707 30707 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:878)

I'll follow-up if the pack step is correct (by saving the symlinks manually, and overwrite the extracted dir with them).
Hopefully it's just an user error.

[chenxiaolong]

Oof, that's definitely a problem 🙂

Just out of curiosity, how are you unpacking and packing the image?

---

By the way, regarding:

was a sparse file and a simple mount + copy ended up as "No space left on device". 🙃

If you're able to mount it at all, it's likely not an Android sparse file. Android sparse files have extra headers that Linux does not understand.

The issue might just be that the image was formatted so that there's no free space left. It might be worth trying this:

1. Resize the image to make room:

   resize2fs system.img 4G

2. Undo Android's deduplicating of shared data so that the image can be made writable:

   e2fsck -fy -E unshare_blocks system.img

3. Mount and copy the files

4. Shrink the image so that there's no free space again:

   resize2fs -M system.img

[xabolcs]

Just out of curiosity, how are you unpacking and packing the image?

It uses 7z which has this symlink problem long time ago.
Now I try to teach fuse2fs and fusermount for it. 🙃

Ahh, thank you for the hint about resize2fs! Will try!

[xabolcs]

I was able to teach Android_boot_image_editor extracting img files without 7z - with fuse2fs, fusermount. It works now!

I also tried resize2fs and e2fsck and they also worked nicely!

Of course one should keep an eye about owners an permissions, but that can be checked from the install script.

@chenxiaolong, thank you for the hint! 🙏