Estoy tratando de flashear un GSI Android 12 en mi Samsung Galaxy Tab Active3. El objetivo es instalar el GSI sin Root / anular la garantía. Mi empresa produce una aplicación que se utiliza principalmente en Android en los dispositivos Galaxy Tab Active. Se espera que el Galaxy Tab Active3 obtenga la actualización de Android 12 en los próximos meses y queríamos hacer algunas pruebas de regresión antes de eso. De ahí la necesidad de conseguir Android 12 GSI en el Tab Active3.
El dispositivo es un arm64 por lo que he descargado la versión arm64+gms de Android 12 GSI (del sitio web de Google). He desbloqueado con éxito el cargador de arranque, y habilitado el soporte DSU. El dispositivo soporta Project Treble y el espacio de nombres aislado VNDK, por lo que en teoría debería soportar GSI.
Todo lo que he intentado hasta ahora ha fracasado. ¿Alguna idea para que funcione?
Manual DSU
He intentado instalar el GSI iniciando manualmente el DSU a través del gestor de actividades. Todas las veces dice "Instalación fallida" después de alcanzar el 50% de progreso. He intentado establecer diferentes tamaños para los USERDATA: 8GB (el tamaño recomendado por Google), 2GB y 1GB. Siempre me sale el mismo error. El dispositivo tiene alrededor de 40GB de espacio libre y el tamaño de la imagen GSI es de alrededor de 2GB, por lo que no debería tener nada que ver con los requisitos de espacio.
Logcat informa de un 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: 1257738436Esto no ayuda desgraciadamente; se lanza desde el siguiente archivo y éste sólo se lanza si hay algún error en la instalación dinámica subyacente:
PS: Desafortunadamente el dispositivo no soporta DSU Loader a pesar de que está ejecutando Android 11 (la búsqueda de "dsu" en la configuración no devuelve resultados relevantes). Al parecer, ninguno de los dispositivos de Samsung es compatible con DSU Loader.
Fastboot y FastbootD
El dispositivo puede reiniciarse en modo fastboot ( adb reboot bootloader ) pero todos los comandos se quedan colgados para siempre (excepto fastboot devices que sí detecta el dispositivo). He probado fastboot reboot fastboot Pero sólo se reinicia en el modo estándar del dispositivo y no entra en un modo de espacio de usuario fastboot (modo fastbootd) como algunos han sugerido que debería.
Heimdall
Al menos una persona ha dicho que puede parchear GSIs usando Heimdall: https://forum.xda-developers.com/t/can-i-flash-gsi-roms-with-odin.4029921/
Esa persona pudo flashear su GSI a la partición SYSTEM, pero mi dispositivo no tiene una partición SYSTEM. Las particiones son como SUPER, PRISM, etc.
No consigo que Heimdall funcione correctamente en Windows 10. He probado con WinUSB, libusb0 y libusbK, pero en todos ellos ocurre lo mismo. Después de reiniciar el dispositivo en modo ODIN, se puede detectar el dispositivo con heimdall detect pero no puedo hacer nada más, incluyendo heimdall print-pit Ya que obtengo un error "Failed to access device. libusb error: -12".
Me las arreglé para configurar Heimdall en una instancia de Ubuntu de WSL y mapear el USB usando USBIPD. Dentro de WSL, heimdall print-pit funciona pero no puedo llegar a flashear nada (intenté flashear el GSI a SUPER, no estoy seguro de que fuera una buena idea pero de todas formas falló) ya que me sale un error de "¡Inicialización de protocolo fallida!
Odin
No estoy seguro de que Odin soporte los GSIs y no puedo encontrar a nadie que diga que los soporta. He intentado flashear el GSI como un AP en Odin 3.12, 3.13, 3.14 y el 3.14 parcheado que elimina las comprobaciones de firma. Pero cada vez que falla.
Recuperación personalizada
También hay que tener en cuenta que parece que ninguna de las recuperaciones personalizadas (TWRP, SHRP, Orangefox, etc.) es compatible con la Tab Active3, o podría haber intentado flashearlas usando Heimdall/Odin y luego usarlas para flashear la GSI. Pero creo que es probable que hubiera tenido los mismos problemas, al menos con Heimdall.
EDIT: Heimdall en Linux nativo
@Robert en los comentarios de abajo me sugirió que ejecutara Heimdall en Linux nativo en lugar de en WSL o en la versión de Windows. Esto funcionó mejor y solucionó los problemas que tenía antes con Heimdall.
Luego traté de flashear VBMETA (el que se incluye con el GSI) usando Heimdall que funcionó, sin embargo mi dispositivo es ahora soft-bricked, sólo puede arrancar en modo de descarga, y da el siguiente 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 en los comentarios había sugerido flashear un VBMETA generado a partir de avbtool en su lugar; probé esto también, pero obtuve casi la misma situación y una salida de error muy ligeramente diferente:
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 en WSL de nuevo, hallazgos de VBMETA, y cómo conseguí que DSU funcionara
He descubierto que tanto Heimdall en Linux nativo como Heimdall en WSL sufren el mismo problema. Sólo se puede enviar un comando al dispositivo, luego los comandos subsiguientes fallan con "falla en la inicialización del protocolo". En WSL estaba haciendo cosas como heimdall print-pit --no-reboot y por eso tenía problemas al flashear. Básicamente, si se produce un fallo en la inicialización del protocolo, reinicie el dispositivo y debería funcionar.
Los dispositivos Samsung parecen hacer una comprobación de la firma en VBMETA y sólo aceptan las firmadas oficialmente por Samsung. He encontrado dos imágenes VBMETA diferentes en mi ROM de stock - vbmeta.img y vbmeta_samsung.img . Me di cuenta de que vbmeta_samsung.img tiene el mismo tamaño de archivo que las imágenes desactivadas de vbmeta. Para cuando tuve esto arreglado ya había flasheado vbmeta_samsung.img y luego hacer un restablecimiento de fábrica. No estoy seguro de si esto era estrictamente necesario, sin embargo, como después de flashear vbmeta.img todavía funcionaba. No estoy seguro de si volver a cargar el stock original vbmeta.img habrá vuelto a habilitar el AVB sin embargo. Aunque yo diría que es poco probable, ya que hasta el propio Google dice que hay que desactivar AVB para poder usar DSU.
Cómo conseguí arreglar el DSU finalmente (aparte de lo anterior) - Había cometido un error realmente estúpido al ejecutar el comando DSU. Para KEY_SYSTEM_SIZE Estaba pasando el tamaño del sistema gzipped, no el tamaño de la imagen del sistema original. Por eso la instalación siempre fallaba después del 50%, porque sólo instalaba el 50% de la imagen del sistema. También otra cosa realmente importante a tener en cuenta es que después de ejecutar DSU, tienes que reiniciar el sistema desde la notificación de DSU y no desde el menú de encendido normal del dispositivo.
0 votos
Los comentarios no son para ampliar la discusión; esta conversación ha sido trasladado al chat .