Comment installer GSI sur Samsung Galaxy Tab Active3

Je tente de flasher un Android 12 GSI sur ma Samsung Galaxy Tab Active3. L'objectif est d'installer le GSI sans root / annuler la garantie. Mon entreprise produit une application principalement utilisée sur Android sur des appareils Galaxy Tab Active. Il est prévu que la Galaxy Tab Active3 reçoive la mise à jour Android 12 dans les prochains mois et nous voulions faire quelques tests de régression avant cela. D'où la nécessité d'obtenir Android 12 GSI sur la Tab Active3.

Le dispositif est un arm64 donc j'ai téléchargé la version arm64+gms d'Android 12 GSI (à partir du site web de Google). J'ai déverrouillé avec succès le chargeur de démarrage, et activé la prise en charge de DSU. Le dispositif prend en charge Project Treble et l'espace de nom isolé VNDK, donc en théorie devrait prendre en charge les GSIs.

Tout ce que j'ai essayé jusqu'à présent a échoué. Des idées pour que cela fonctionne?

DSU Manuel

J'ai essayé d'installer le GSI en démarrant manuellement le DSU via le gestionnaire d'activité. À chaque fois, il affiche simplement "Installation échouée" après avoir atteint environ 50% de progression. J'ai essayé de définir différentes tailles pour le USERDATA: 8 Go (taille recommandée par Google), 2 Go et 1 Go. J'obtiens la même erreur à chaque fois. Le dispositif dispose d'environ 40 Go d'espace libre et la taille de l'image GSI est d'environ 2 Go, donc cela ne devrait pas être lié aux exigences d'espace.

Logcat signale une erreur:

11-11 13:10:09.620  1103  3695 I DynamicSystemService: Échec de l'installation du système
11-11 13:10:09.621 16445 23403 E InstallationAsyncTask: java.io.IOException: Échec de démarrer l'installation avec la taille demandée: 1257738436

Cela n'aide malheureusement pas; cela est déclenché à partir du fichier suivant et c'est simplement déclenché s'il y a une erreur dans l'installation dynamique sous-jacente:

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/packages/DynamicSystemInstallationService/src/com/android/dynsystem/InstallationAsyncTask.java

PS: Malheureusement, le dispositif ne prend pas en charge DSU Loader même s'il fonctionne sous Android 11 (la recherche de "dsu" dans les paramètres ne renvoie aucun résultat pertinent). Apparemment, aucun des appareils Samsung ne prend en charge DSU Loader.

Fastboot et FastbootD

Le dispositif peut être redémarré en mode fastboot (adb reboot bootloader) mais chaque commande reste bloquée indéfiniment (sauf fastboot devices, qui détecte le dispositif). J'ai essayé fastboot reboot fastboot, mais cela redémarre simplement en mode standard du dispositif et n'entre pas en mode espace utilisateur fastboot (mode fastbootd) comme certains l'ont suggéré.

Heimdall

Au moins une personne a dit pouvoir patcher les GSIs en utilisant Heimdall: https://forum.xda-developers.com/t/can-i-flash-gsi-roms-with-odin.4029921/

Cette personne a réussi à flasher son GSI sur la partition SYSTEM, mais mon dispositif n'a pas de partition SYSTEM. Les partitions sont comme SUPER, PRISM, etc.

Je n'arrive pas à faire fonctionner Heimdall correctement sous Windows 10. J'ai essayé avec WinUSB, libusb0 et libusbK, mais c'est la même chose pour tous. Après avoir redémarré le dispositif en mode ODIN, le dispositif peut être détecté avec heimdall detect, mais je ne peux rien faire de plus, y compris heimdall print-pit, car j'obtiens une erreur "Impossible d'accéder au dispositif. Erreur libusb: -12".

J'ai réussi à configurer Heimdall sur une instance Ubuntu de WSL et à mapper l'USB en utilisant USBIPD. À l'intérieur de WSL, heimdall print-pit fonctionne mais je ne peux pas aller plus loin pour flasher quoi que ce soit (j'ai essayé de flasher le GSI sur SUPER, pas sûr si c'était une bonne idée mais de toute façon cela a échoué) car j'obtiens une erreur "Échec de l'initialisation du protocole!".

Odin

Je ne suis pas sûr qu'Odin supporte même les GSIs et je ne trouve personne disant qu'il les prend en charge. J'ai essayé de flasher le GSI en tant que AP dans Odin 3.12, 3.13, 3.14 et la version patchée 3.14 qui supprime les vérifications de signature. Mais à chaque fois cela échoue.

Récupération personnalisée

À noter également, il semble que aucune des récupérations personnalisées (TWRP, SHRP, Orangefox, etc.) ne prennent en charge le Tab Active3, sinon j'aurais pu essayer de les flasher à l'aide de Heimdall/Odin puis les utiliser pour flasher le GSI. Mais je pense que j'aurais eu les mêmes problèmes, du moins avec Heimdall.

MODIFIER: Heimdall sur Linux natif

@Robert dans les commentaires ci-dessous a suggéré que j'exécute Heimdall sur Linux natif plutôt que sur WSL ou la version Windows. Cela a mieux fonctionné et a résolu les problèmes que j'avais rencontrés auparavant avec Heimdall.

J'ai ensuite essayé de flasher VBMETA (celui qui est fourni avec le GSI) en utilisant Heimdall, ce qui a fonctionné, cependant mon dispositif est maintenant briqué, ne peut démarrer que en mode Download, et affiche l'erreur suivante:

MODE ODIN (échec AVB)
vbmeta: La clé publique utilisée pour signer les données a été rejetée. (5)
vbmeta: Le bit VERIFICATION_DISABLED est défini.
VBMETA PERSONNALISÉ
VBMETA: Aucune information de signature
VBMETA ,

@alecxs dans les commentaires avait suggéré de flasher un VBMETA généré à partir de avbtool à la place; j'ai essayé cela aussi, mais j'ai eu presque la même situation et une production d'erreur légèrement différente:

MODE ODIN (échec AVB)
vbmeta: Erreur de vérification de l'image vbmeta: OK_NOT_SIGNED (3)
vbmeta: Le bit VERIFICATION_DISABLED est défini.
VBMETA PERSONNALISÉ
VBMETA: Aucune information de signature
VBMETA ,

MODIFIER 2: Heimdall sur WSL à nouveau, conclusions sur VBMETA, et comment j'ai fait fonctionner DSU

J'ai constaté que Heimdall sur Linux natif et Heimdall sur WSL souffrent en réalité du même problème. Vous ne pouvez envoyer qu'une commande au dispositif, puis les commandes suivantes échouent avec "échec de l'initialisation du protocole". Sur WSL, je faisais des choses comme heimdall print-pit --no-reboot et c'est pourquoi j'avais des problèmes lors du flashage. Fondamentalement, si vous obtenez un échec de l'initialisation du protocole, redémarrez simplement le dispositif et cela devrait fonctionner.

Les dispositifs Samsung semblent effectuer une vérification de signature sur VBMETA et n'acceptent que les officiels signés Samsung. J'ai trouvé deux images VBMETA différentes dans ma ROM stock - vbmeta.img et vbmeta_samsung.img. J'ai remarqué que vbmeta_samsung.img avait la même taille de fichier que les images de désactivation de vbmeta. Au moment où j'ai réglé cela, j'avais flashé vbmeta_samsung.img puis fait une réinitialisation d'usine. Je ne suis pas sûr que cela était strictement nécessaire cependant, car après avoir flashé vbmeta.img ça a quand même fonctionné. Pas sûr si la re-flashage de la vbmeta.img d'origine réactivera AVB cependant. Bien que je dirais que c'est peu probable, car même Google lui-même dit que vous devez désactiver AVB pour utiliser DSU.

Comment j'ai finalement réussi à corriger DSU (en plus de ce qui précède) - j'avais commis une erreur vraiment stupide en exécutant la commande DSU. Pour KEY_SYSTEM_SIZE j'envoyais la taille de l'image système compressée, pas la taille de l'image système d'origine. C'est pourquoi l'installation échouait toujours après 50%, car elle n'installait que 50% de l'image système. Une autre chose vraiment importante à noter est qu'après l'exécution de DSU, vous devez redémarrer le système à partir de la notification du DSU et non à partir du menu d'alimentation normal du dispositif.