-writable-system
para el emulador
Cuando se inicia el emulador después de compilarlo, debes usar:
. build/envsetup.sh
lunch aosp_x86_64-eng
emulator -show-kernel -verbose -writable-system
Luego, para ejecuciones futuras, debes mantener la opción -writable-system
, de lo contrario los cambios en la imagen no serán visibles:
emulator -show-kernel -verbose -writable-system
-verbose
nos muestra que el emulador cambia desde el -drive
por defecto:
if=none,index=0,id=system,file=/path/to/aosp/8.1.0_r60/out/target/product/generic_x86_64/system-qemu.img,read-only
a:
if=none,index=0,id=system,file=/path/to/aosp/8.1.0_r60/out/target/product/generic_x86_64/system-qemu.img.qcow2,overlap-check=none,cache=unsafe,l2-cache-size=1048576
Por lo tanto:
-
elimina ,read-only
-
usa system-qemu.img.qcow2
en lugar de system-qemu.img
.
Esto implica que los cambios solo serán visibles si pasas -writable-sytem
en los arranques futuros después de que se haya realizado el cambio!
Vemos que la imagen qcow2 es simplemente una pequeña superposición sobre la imagen base ya que:
qemu-img info /path/to/aosp/8.1.0_r60/out/target/product/generic_x86_64/system-qemu.img.qcow2
contiene:
backing file: /path/to/aosp/8.1.0_r60/out/target/product/generic_x86_64/system-qemu.img
El comando -help
del emulador también confirma esto:
emulator -help
contiene:
-writable-system hacer que la imagen del sistema y del proveedor sea escribible después de 'adb remount'
adb remount
+ adb root
Creo que esto es simplemente un atajo para mount
como se menciona en https://android.stackexchange.com/a/110928/126934, pero es muy conveniente:
adb root
adb remount
adb shell
adb help
contiene:
root reiniciar adbd con permisos de root
remount
remontar las particiones /system, /vendor y /oem como de escritura
Restaurar la imagen del sistema original
Igual que para userdata: elimina la superposición .qcow2
y vuelve a generarla manualmente: https://stackoverflow.com/questions/54446680/how-to-reset-the-userdata-image-when-building-android-aosp-and-running-it-on-the