I am trying to flash an Android 12 GSI onto my Samsung Galaxy Tab Active3. Goal is to install the GSI without root / voiding the warranty. My company produces an app which is primarily used on Android on Galaxy Tab Active devices. It's expected Galaxy Tab Active3 will get Android 12 update in the next few months and we wanted to do some regression testing in advance of that. Hence the need to get Android 12 GSI onto the Tab Active3.
Device is an arm64 so I downloaded the arm64+gms version of Android 12 GSI (from Google's website). I have successfully unlocked the bootloader, and enabled DSU support. The device supports Project Treble and the VNDK isolated namespace, so in theory should support GSIs.
Everything I tried so far has failed. Any ideas to get it working?
Manual DSU
I have tried to install the GSI by manually starting the DSU via activity manager. Every time it just says "Installation failed" after reaching about 50% progress. I have tried setting different sizes for the USERDATA: 8GB (Google's recommended size), 2GB and 1GB. I get the same error every time. The device has around 40GB free space and the GSI image size is around 2GB, so it shouldn't be anything to do with the space requirements.
Logcat reports an error:
11-11 13:10:09.620 1103 3695 I DynamicSystemService: Failed to install system
11-11 13:10:09.621 16445 23403 E InstallationAsyncTask: java.io.IOException: Failed to start installation with requested size: 1257738436
This doesn't help unfortunately; it is thrown from the following file and this is just thrown if there is any error in the underlying dynamic installation:
PS: Unfortunately the device does not support DSU Loader even though it's running Android 11 (searching for "dsu" in the settings returns no relevant results). Apparently none of the Samsung devices are supporting DSU Loader.
Fastboot and FastbootD
The device can be rebooted into fastboot mode (adb reboot bootloader) but every command just hangs forever (except for fastboot devices, which does detect the device). I tried fastboot reboot fastboot, but it just reboots into the standard mode of the device and does not enter a fastboot userspace mode (fastbootd mode) as some have suggested it should.
Heimdall
At least one person has said they can patch GSIs using Heimdall: https://forum.xda-developers.com/t/can-i-flash-gsi-roms-with-odin.4029921/
That person was able to flash their GSI to the SYSTEM partition, but my device doesn't have a SYSTEM partition. The partitions are like SUPER, PRISM, etc.
I'm not able to get Heimdall working properly on Windows 10. I have tried with WinUSB, libusb0 and libusbK, but the same is true for all of them. After rebooting the device into ODIN mode, the device can be detected with heimdall detect, but I can't do anything more including heimdall print-pit, as I get a "Failed to access device. libusb error: -12" error.
I managed to set up Heimdall on an Ubuntu instance of WSL and map the USB using USBIPD. Inside WSL, heimdall print-pit does work but I can't get further to flashing anything (I tried to flash the GSI to SUPER, not sure if this was a good idea but anyway it failed) as I get a "Protocol initialisation failed!" error.
Odin
I am not sure if Odin even supports GSIs and I can't find anyone saying it supports them. I have tried flashing the GSI as an AP in Odin 3.12, 3.13, 3.14 and the patched 3.14 which removes signature checks. But every time it just fails.
Custom recovery
Just to also note, it seems none of the custom recoveries (TWRP, SHRP, Orangefox etc) support the Tab Active3, or I could have tried to flash those using Heimdall/Odin and then use them to flash the GSI. But I feel it's likely I would have had the same issues, at least with Heimdall.
EDIT: Heimdall on native Linux
@Robert in the comments below suggested I run Heimdall on native Linux rather than on WSL or the Windows version. This worked better and fixed the issues I was having before with Heimdall.
I then tried to flash VBMETA (the one which is bundled with the GSI) using Heimdall which worked, however my device is now soft-bricked, can only boot into Download Mode, and gives the following error:
ODIN MODE (AVB fail)
vbmeta: Public key used to sign data rejected. (5)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
@alecxs in the comments had suggested flashing a VBMETA generated from avbtool instead; I tried this also, but got almost the same situation and a very slightly different error output:
ODIN MODE (AVB fail)
vbmeta: Error verifying vbmeta image: OK_NOT_SIGNED (3)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
EDIT 2: Heimdall on WSL again, VBMETA findings, and how I got DSU working
I found that both Heimdall on native Linux and Heimdall on WSL actually suffer from the same problem. You can only post one command to the device, then subsequent commands fail with "protocol initialisation failed". On WSL I was doing things like heimdall print-pit --no-reboot and that's why I was facing issues when flashing. Basically, if you get protocol initialisation failed, just reboot the device and it should work.
Samsung devices seem to do a signature check on VBMETA and only accept official Samsung-signed ones. I found two different VBMETA images in my stock ROM - vbmeta.img and vbmeta_samsung.img. I happened to notice that vbmeta_samsung.img has the same file size as the vbmeta disable images. By the time I'd got this fixed I'd flashed vbmeta_samsung.img and then done a factory reset. I'm not sure if this was strictly necessary though, as after flashing vbmeta.img it still worked. Not sure if re-flashing original stock vbmeta.img will have re-enabled AVB though. Although I'd say it's unlikely, as even Google themselves say you need to disable AVB in order to use DSU.
How I got DSU fixed eventually (aside from the above) - I had made a really stupid error when running the DSU command. For KEY_SYSTEM_SIZE I was passing the gzipped system size, not original system image size. This is why the installation always failed after 50%, because it was only installing 50% of the system image. Also another really important thing to note is that after running DSU, you have to restart the system from the DSU notification and not from the normal power menu of the device.