intronauta
28/11/10, 23:29:40
La idea del tutorial es profundizar en la syntaxis de los update.zip, más que nada porque parece que no está publicada oficialmente o no es de fácil acceso. Tampoco tiene como finalidad instalar un rom completa desde 0, para la que habría que jugar con permisos, symlinks y un sin fin de comandos pero al final daremos un repaso a un update-script común a día de hoy (DocROM_JP) y veresmos como se estucturan que pasos siguen. Lo mejor es hurgar en los update.zip existentes de roms como tayutama, doc rambone y mucho ensayo y error. Googleando me sorprende la cantidad de cocineros que conozco que han aprendido así. ¿por qué demonios no estará publicado?. :enfadadisimo:
En la primer aparte veremos cuales son los comandos más comunes utilizados y las posibilidades que ofrecen, lo que nos permitirá automatizar ciertos procesos que más de uno solemos hacer religiosamente en cada flasheo, como eliminar sistemáticamente ciertas apps, cambiar csc o copiar launchers a /system/app por ejemplo. También puede interesarte para flashear un zImage, modem, s-pbl,... realizar ciertos backups-restore de carpetas, fotos, etc desde el propio recovery sin tener que hacer backup de todo el sistema.
Además, como no es necesario firmarlos para flashear desde un CWM o 2e recovery, es bastante más cómodo, los podrías hacer desde androzip!.
Las posibilidades dependen de tus necesidades, paciencia e imaginación X-D
Estructura de un update.zip
Lo más importante es la carpeta /META-INF, que contiene unos archivos genéricos con certificados y demás y sobre todo un archivo llamado "update-script" que es el que nosotros mofificaremos. Sería algo como esto:
update.zip/META-INF/
/META-INF/CERT.RSA
/META-INF/CERT.SF
/META-INF/MANIFEST.MF
/META-INF/com/google/android/update-script
/data
/system
/xxx
....
/data es la recomendada para contener los archivos que queremos incluir en /data (mem.interna) y lo mismo para /system. Puedes darles el nombre que quieras pero para tenerlo todo organizado y por comodidad manten los nombres genéricos, No es obligatoria crearlas si no las vamos a necesitar, es más, podríamos crear un update.zip solo con la carpeta META-INF.
Al final del post encontrarás una plantilla de un update.zip "update-template.zip" con algunas carpetas genéricas.
Comandos para crear tu update.script
este tutorial solo sirve para trabajar con update-script y no con updater-script! Estos últimos los verás en algunos update.zip y enseguida notarás las diferencias. Son una versión más avanzada que precisa de un binario adjunto llamado update-binary y usa otra sintaxis. Incluso en algunos verás un update-binay+update-script+updater-script! :oh: . Al final son parecidos aunque con los updater-script puedes crear graficos ascii art http://twitpic.com/3af8hy (http://twitpic.com/3af8hy). Una pena que con los update-script no podamos, pero por lo que he visto al final con ambos se puede hacer lo mismo o más habitual.
respeta los espacios, mayúsculas, minúsculas, etc.... si no quieres ver un "syntax error" al flashear.
Copiar archivos a la memoria interna
Copiar archivos contenidos dentro de la carpeta "system" del update.zip a /system/app
copy_dir PACKAGE:system SYSTEM:app
Copiar archivos contenidos dentro de la carpeta "data" del update.zip a /data/app
copy_dir PACKAGE:data DATA:app
Borrar archivos o carpetas de la memoria interna
Borrar /system/app/Maps.apk y Maps.odex (no olvidar los .odex si existen!)delete SYSTEM:app/Maps.apk
delete SYSTEM:app/Maps.odexBorrar /data/app/Maps.apkdelete DATA:app/Maps.apkBorrar carpetas (por ejemplo /data/dalvik-cache)delete_recursive DATA:dalvik-cache
Formatear (format)
format SYSTEM:
format DATA:
format DATADATA: (DATADATA es el equivalente de DBDATA)
format CACHE:
format SDCARD:
format SDEXT:
format SDCARD:./android_secure (necesario para borrar apps2sd)
Barra de progreso (show progress)
show_progress 0.1 0 (porción del total, inicio de "subporción" :P )
...
show_progress 0.1 10 (final de subporción)
show_progress 0.2 0
...
show_progress 0.2 10Bueno, con show_progress tengo un dilema. "Teóricamente" con esto controlamos la barra de progreso asignando para cada proceso o grupo de procesos una porción del total de la barra y con qué frecuencia se actualizará, teniendo en cuenta que en el primer valor 1 es el 100% de la barra y en el segundo 0 es el inicio y 10 el final del periodo. La recomendación es que si creas un update-script con un solo comando al menos pongas un show_progress 0.1 0 al principio, pero por lo que he probado no es obligatorio y observando los update-script que tenemos a mano la verdad es que es un poco cachondeo y no veo un criterio establecido, parece que se hace a ojo :S
Ejecutar un shell script (run_program)
Hay dos formas de ejecutar un shell script, una ejecutándolo desde el propio update.zip (con las operaciones básicas busybox) o volcándolo a /TMP.
TMP es un pequeño espacio incluido en el propio recovery.img muy útil para poder copiar scripts e incluso binarios ejecutables que deben ser llamados desde la mem interna.
Ejecutar un script.sh que tenemos dentro de la raíz de nuestro update.zip.
run_program PACKAGE:script.sh
Ejecutar un shell script que tenemos dentro de la carpeta /mi_script volcándolo a TMP antes:
copy_dir PACKAGE:mi_script TMP:/script (<-creará la carpeta si no existe)
set_perm 0 0 755 TMP:/script/script.sh (damos permisos ejecución)
run_program /tmp/script/script.sh sh /script/script.sh
(Atento al shell script!! -> #!/system/bin/sh)
Si queremos escribir sobre las BLM protegidas y flashear un kernel, modem, p-sbl, etc. desde el recovery necesitaremos ejecutar un binario llamado redbend_ua desde TMP:redbend_ua
Adjunto al final del post el binario comprimido.
Con redbend_ua y zImage, sbl.bin, modem.bin,.. dentro de la carpeta "updates" de nuestro update.zip:show_progress 0.1 0
copy_dir PACKAGE:updates TMP:/updates (copiamos a TMP/updates)
set_perm 0 0 755 TMP:/updates/redbend_ua (damos permisos de ejecucción a redbend_ua)
show_progress 0.1 10
show_progress 0.2 0 (inicia la seguna parte)
run_program /tmp/updates/redbend_ua restore /tmp/updates/zImage /dev/block/bml7
show_progress 0.2 10
show_progress 0.3 0
run_program /tmp/updates/redbend_ua restore /tmp/updates/modem.bin /dev/block/bml12
show_progress 0.3 10
show_progress 0.4 0
run_program /tmp/updates/redbend_ua restore /tmp/updates/Sbl.bin /dev/block/bml4
show_progress 0.4 10
He incluido varios show_progress para que se entienda mejor el uso que tiene aunque no parece obligatorio.
Ejemplos básicos de un "update-script":
Este update-script es el que utilizo yo para eliminar casi todas las aplicaciones de samsung además de Maps (ya que está desactualizado y solo ocupa espacio) dejando nuestra stock rom casi como una versión "Lite", y añadirá a /system/app la Galery3D alternativa y TouchwizGTG Launcher v.1.1.1 modificado (touchwizGTG launcher v.1.1.1).
show_progress 0.1 0
delete SYSTEM:app/aldiko-standard-1.2.6.1-samsung-s1.apk
delete SYSTEM:app/BuddiesNow.apk
delete SYSTEM:app/BuddiesNow.odex
delete SYSTEM:app/Days.apk
delete SYSTEM:app/Days.odex
delete SYSTEM:app/DualClock.apk
delete SYSTEM:app/DualClock.odex
delete SYSTEM:app/Email.apk
delete SYSTEM:app/Email.odex
delete SYSTEM:app/Gallery3D.apk
delete SYSTEM:app/Gallery3D.odex
delete SYSTEM:app/InfoAlarm.apk
delete SYSTEM:app/InfoAlarm.odex
delete SYSTEM:app/Layar-samsung.apk
delete SYSTEM:app/MagicSmokeWallpapers.apk
delete SYSTEM:app/MagicSmokeWallpapers.odex
delete SYSTEM:app/Maps.apk
delete SYSTEM:app/MiniDiary.apk
delete SYSTEM:app/MiniDiary.odex
delete SYSTEM:app/PressReader.apk
delete SYSTEM:app/SamsungApps.apk
delete SYSTEM:app/SamsungWidget_CalendarClock.apk
delete SYSTEM:app/SamsungWidget_CalendarClock.odex
delete SYSTEM:app/SamsungWidget_FeedAndUpdate.apk
delete SYSTEM:app/SamsungWidget_FeedAndUpdate.odex
delete SYSTEM:app/SamsungWidget_ProgramMonitor.apk
delete SYSTEM:app/SamsungWidget_ProgramMonitor.odex
delete SYSTEM:app/SamsungWidget_StockClock.apk
delete SYSTEM:app/SamsungWidget_StockClock.odex
delete SYSTEM:app/SamsungWidget_WeatherClock.apk
delete SYSTEM:app/SamsungWidget_WeatherClock.odex
delete SYSTEM:app/TATLiveWallpapersAurora.apk
delete SYSTEM:app/TATLiveWallpapersAurora.odex
delete SYSTEM:app/TATLiveWallpapersBlueSea.apk
delete SYSTEM:app/TATLiveWallpapersBlueSea.odex
delete SYSTEM:app/TATLiveWallpapersDandelion.apk
delete SYSTEM:app/TATLiveWallpapersDandelion.odex
delete SYSTEM:app/TouchWiz30Launcher.apk
delete SYSTEM:app/TouchWiz30Launcher.odex
delete SYSTEM:app/UnifiedInbox.apk
delete SYSTEM:app/UnifiedInbox.odex
delete SYSTEM:app/VisualizationWallpapers.apk
delete SYSTEM:app/VisualizationWallpapers.odex
delete SYSTEM:app/WriteandGo.apk
delete SYSTEM:app/WriteandGo.odex
show_progress 0.1 10
show_progress 0.2 0
copy_dir PACKAGE:system SYSTEM:app
show_progress 0.2 10Ya solo faltaría incluir en la carpeta /system del update.zip el Touchwiz30Launcher.apk y el Galery3D.apk modificados, comprimir las carpetas /system y /META-INF en un zip y directo a la raiz de ls sd interna.
(adjunto este ejemplo "Stock2Lite.zip")
**
Este otro equivaldría a un wipe factory-reset. Es un poco absurdo ya que el propio recovery tiene la función, pero es solo un ejemplo de lo simple que es ;)
show_progress 0.1 0
format DATA:
format DATADATA:
format CACHE:
format SDEXT:
format SDCARD:./android_secure
Recordar que podemos ponerle el nombre que queramos al update.zip, cuanto más descriptivo mejor.
Update-script en custom roms.
Vamos a analizar en este caso el de una DocROM v3.1.0
show_progress 0.1 0---> (iniciamos el proceso e iniciamos barra de progreso)
format SYSTEM: ---> (formatear SYSTEM)
delete_recursive SYSTEM:---> (borrar SYSTEM y todas sus subcarpetas recursivamente. Es redundante después de un format)
copy_dir PACKAGE:system SYSTEM: ---> (copiar nuestra carpeta system a SYSTEM)
Ahora eliminamos unos binarios que supongo están compilados por samsung y que probablemente vengan "capados" y utilizaremos toolbox, que es un mini-busybox que viene por defecto en Android, pero puede realizar operaciones que busybox es incapaz, como por ejemplo “sh” para ser root. Entonces los sustituimos por un elnace simbólico a "toolbox":
symlink toolbox SYSTEM:bin/cat
symlink toolbox SYSTEM:bin/chmod
symlink toolbox SYSTEM:bin/chown
symlink toolbox SYSTEM:bin/cmp [/quote]
...
...
show_progress 0.1 10
Ahora debemos asignar los permisos adecuados a las carpetas del sistema para que funcione adecuadamente:
set_perm usuario grupo permisos RUTA por ejemplo, root=0, shell=2000,...
**para saber más sobre permisos: http://es.wikipedia.org/wiki/Chmod (http://es.wikipedia.org/wiki/Chmod)
show_progress 0.2 0
set_perm_recursive 0 0 0755 0644 SYSTEM:---> (permisos recursivos para todo SYSTEM y subcarpetas)
set_perm_recursive 0 2000 0755 0755 SYSTEM:bin ---> (permisos específicos para /system/bin)
set_perm_recursive 0 0 0755 0755 SYSTEM:etc---> (idem para /system/etc)
set_perm 0 3003 02755 SYSTEM:bin/netcfg---> (idem para el archivo /system/bin/netcfg)
set_perm 0 3004 02755 SYSTEM:bin/ping---> (etc.)
set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluetooth
set_perm 0 0 0755 SYSTEM:etc/bluetooth
set_perm 1002 1002 0440 SYSTEM:etc/dbus.conf
set_perm 1014 2000 0550 SYSTEM:etc/dhcpcd/dhcpcd-run-hooks
set_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh
set_perm_recursive 0 0 0777 0777 SYSTEM:etc/init.d ---> (Aquí damos permisos a /system/etc/init.d para poder ejecutar scripts en el inicio. El init.rc (http://source.android.com/porting/bring_up.html) compilado en el kernel debe tener habilitado run-parts desde busybox para que funcione. En general todos los custom kernel lo llevan habilitado)
set_perm 0 0 04755 SYSTEM:xbin/su
set_perm 0 0 04755 SYSTEM:xbin/busybox
show_progress 0.2 10
Esta parte en un principio se mantiene así ROM tras ROM, la mayoría son genéricos para cualquier sistema android.
show_progress 0.3 0
symlink /system/xbin/su SYSTEM:bin/su ---> (crea un enlace simbólico de xbin/su a bin/su)
run_program PACKAGE:root --->(ejecuta un shell script que dará permisos a /bin/su e instalará busybox)
run_program PACKAGE:dalvik---> (ejecuta un script que hace un wipe a dalvik-cache, innecesario ya que luego formatearemos /data)
show_progress 0.3 10
Ya tenemos /system completo.
show_progress 0.4 0
format CACHE: --->(formatea CACHE)
format DATADATA: --->(formatea DBDATA)
format DATA: --->(formatea DATA)
copy_dir PACKAGE:data DATA: ---> (copia nuestra carpeta /data/ a /data/app)
set_perm 1000 1000 0771 DATA:app --->(da permisos específicos /data/app)
copy_dir PACKAGE:sdcard SDCARD:--->(copia nuestra carpeta /sdcard a SDCARD)
Con esto tenemos todos los archivos y herramientas básicas instaladas.
Ahora instalar un kernel y un modem.bin copiando el binario redbend_ua, el zImge y modem.bin a TMP, y ejecutandolo
copy_dir PACKAGE:updates TMP:/updates
set_perm 0 0 755 TMP:/updates/redbend_ua
run_program /tmp/updates/redbend_ua restore /tmp/updates/modem.bin /dev/block/bml12
run_program /tmp/updates/redbend_ua restore /tmp/updates/zImage /dev/block/bml7
show_progress 0.4 10
Y poco más, no tiene tampoco mucho misterio
** Solo en el caso de que necesites flashear desde un recovery que requiera verificación de firma: "E:signature verification failed" y sea compatible con "testkeys" (no compatible con recovery 3e o 2e "oficial").
Método 1:
Descargar testsign.zip adjunto y descomprimir en tu sdk/tools (asegúrate de tener el path añadido a tu sistema)
En linux necesitarás darle permisos: chmod u+x testsign.jar
Firmar: java -classpath testsign.jar testsign update.zip update-signed.zip
Puedes cambiarle el nombre de update-signed.zip a update.zip nuevamente para hacerlo compatible con recovery que solo detecten un update.zip en la raiz de la sdcard, pero no modificarlo internamente, en ese caso tendrías que volver a firmar.
Método 2:
Otra forma sería con aplicaciones Android como zipsigned o Signaptik, ambas disponibles en el market y muy sencillas de utilizar.
################################################## ########################################
Estaría bien que la gente compartiese sus update.zip personalizados ;)
Y poco más, bueno si, HACER NANDROID BACKUPS ANTES DE NADA! y tener en cuenta que desgraciadamente desde el recovery no tenemos acceso a la /sdcard :enfadadisimo:, así que si quieres hacer pruebas mejor prepara varios zip, de otra manera tendrás que reiniciar cada vez y es un auténtico coñazo.
ENJOY!
En la primer aparte veremos cuales son los comandos más comunes utilizados y las posibilidades que ofrecen, lo que nos permitirá automatizar ciertos procesos que más de uno solemos hacer religiosamente en cada flasheo, como eliminar sistemáticamente ciertas apps, cambiar csc o copiar launchers a /system/app por ejemplo. También puede interesarte para flashear un zImage, modem, s-pbl,... realizar ciertos backups-restore de carpetas, fotos, etc desde el propio recovery sin tener que hacer backup de todo el sistema.
Además, como no es necesario firmarlos para flashear desde un CWM o 2e recovery, es bastante más cómodo, los podrías hacer desde androzip!.
Las posibilidades dependen de tus necesidades, paciencia e imaginación X-D
Estructura de un update.zip
Lo más importante es la carpeta /META-INF, que contiene unos archivos genéricos con certificados y demás y sobre todo un archivo llamado "update-script" que es el que nosotros mofificaremos. Sería algo como esto:
update.zip/META-INF/
/META-INF/CERT.RSA
/META-INF/CERT.SF
/META-INF/MANIFEST.MF
/META-INF/com/google/android/update-script
/data
/system
/xxx
....
/data es la recomendada para contener los archivos que queremos incluir en /data (mem.interna) y lo mismo para /system. Puedes darles el nombre que quieras pero para tenerlo todo organizado y por comodidad manten los nombres genéricos, No es obligatoria crearlas si no las vamos a necesitar, es más, podríamos crear un update.zip solo con la carpeta META-INF.
Al final del post encontrarás una plantilla de un update.zip "update-template.zip" con algunas carpetas genéricas.
Comandos para crear tu update.script
este tutorial solo sirve para trabajar con update-script y no con updater-script! Estos últimos los verás en algunos update.zip y enseguida notarás las diferencias. Son una versión más avanzada que precisa de un binario adjunto llamado update-binary y usa otra sintaxis. Incluso en algunos verás un update-binay+update-script+updater-script! :oh: . Al final son parecidos aunque con los updater-script puedes crear graficos ascii art http://twitpic.com/3af8hy (http://twitpic.com/3af8hy). Una pena que con los update-script no podamos, pero por lo que he visto al final con ambos se puede hacer lo mismo o más habitual.
respeta los espacios, mayúsculas, minúsculas, etc.... si no quieres ver un "syntax error" al flashear.
Copiar archivos a la memoria interna
Copiar archivos contenidos dentro de la carpeta "system" del update.zip a /system/app
copy_dir PACKAGE:system SYSTEM:app
Copiar archivos contenidos dentro de la carpeta "data" del update.zip a /data/app
copy_dir PACKAGE:data DATA:app
Borrar archivos o carpetas de la memoria interna
Borrar /system/app/Maps.apk y Maps.odex (no olvidar los .odex si existen!)delete SYSTEM:app/Maps.apk
delete SYSTEM:app/Maps.odexBorrar /data/app/Maps.apkdelete DATA:app/Maps.apkBorrar carpetas (por ejemplo /data/dalvik-cache)delete_recursive DATA:dalvik-cache
Formatear (format)
format SYSTEM:
format DATA:
format DATADATA: (DATADATA es el equivalente de DBDATA)
format CACHE:
format SDCARD:
format SDEXT:
format SDCARD:./android_secure (necesario para borrar apps2sd)
Barra de progreso (show progress)
show_progress 0.1 0 (porción del total, inicio de "subporción" :P )
...
show_progress 0.1 10 (final de subporción)
show_progress 0.2 0
...
show_progress 0.2 10Bueno, con show_progress tengo un dilema. "Teóricamente" con esto controlamos la barra de progreso asignando para cada proceso o grupo de procesos una porción del total de la barra y con qué frecuencia se actualizará, teniendo en cuenta que en el primer valor 1 es el 100% de la barra y en el segundo 0 es el inicio y 10 el final del periodo. La recomendación es que si creas un update-script con un solo comando al menos pongas un show_progress 0.1 0 al principio, pero por lo que he probado no es obligatorio y observando los update-script que tenemos a mano la verdad es que es un poco cachondeo y no veo un criterio establecido, parece que se hace a ojo :S
Ejecutar un shell script (run_program)
Hay dos formas de ejecutar un shell script, una ejecutándolo desde el propio update.zip (con las operaciones básicas busybox) o volcándolo a /TMP.
TMP es un pequeño espacio incluido en el propio recovery.img muy útil para poder copiar scripts e incluso binarios ejecutables que deben ser llamados desde la mem interna.
Ejecutar un script.sh que tenemos dentro de la raíz de nuestro update.zip.
run_program PACKAGE:script.sh
Ejecutar un shell script que tenemos dentro de la carpeta /mi_script volcándolo a TMP antes:
copy_dir PACKAGE:mi_script TMP:/script (<-creará la carpeta si no existe)
set_perm 0 0 755 TMP:/script/script.sh (damos permisos ejecución)
run_program /tmp/script/script.sh sh /script/script.sh
(Atento al shell script!! -> #!/system/bin/sh)
Si queremos escribir sobre las BLM protegidas y flashear un kernel, modem, p-sbl, etc. desde el recovery necesitaremos ejecutar un binario llamado redbend_ua desde TMP:redbend_ua
Adjunto al final del post el binario comprimido.
Con redbend_ua y zImage, sbl.bin, modem.bin,.. dentro de la carpeta "updates" de nuestro update.zip:show_progress 0.1 0
copy_dir PACKAGE:updates TMP:/updates (copiamos a TMP/updates)
set_perm 0 0 755 TMP:/updates/redbend_ua (damos permisos de ejecucción a redbend_ua)
show_progress 0.1 10
show_progress 0.2 0 (inicia la seguna parte)
run_program /tmp/updates/redbend_ua restore /tmp/updates/zImage /dev/block/bml7
show_progress 0.2 10
show_progress 0.3 0
run_program /tmp/updates/redbend_ua restore /tmp/updates/modem.bin /dev/block/bml12
show_progress 0.3 10
show_progress 0.4 0
run_program /tmp/updates/redbend_ua restore /tmp/updates/Sbl.bin /dev/block/bml4
show_progress 0.4 10
He incluido varios show_progress para que se entienda mejor el uso que tiene aunque no parece obligatorio.
Ejemplos básicos de un "update-script":
Este update-script es el que utilizo yo para eliminar casi todas las aplicaciones de samsung además de Maps (ya que está desactualizado y solo ocupa espacio) dejando nuestra stock rom casi como una versión "Lite", y añadirá a /system/app la Galery3D alternativa y TouchwizGTG Launcher v.1.1.1 modificado (touchwizGTG launcher v.1.1.1).
show_progress 0.1 0
delete SYSTEM:app/aldiko-standard-1.2.6.1-samsung-s1.apk
delete SYSTEM:app/BuddiesNow.apk
delete SYSTEM:app/BuddiesNow.odex
delete SYSTEM:app/Days.apk
delete SYSTEM:app/Days.odex
delete SYSTEM:app/DualClock.apk
delete SYSTEM:app/DualClock.odex
delete SYSTEM:app/Email.apk
delete SYSTEM:app/Email.odex
delete SYSTEM:app/Gallery3D.apk
delete SYSTEM:app/Gallery3D.odex
delete SYSTEM:app/InfoAlarm.apk
delete SYSTEM:app/InfoAlarm.odex
delete SYSTEM:app/Layar-samsung.apk
delete SYSTEM:app/MagicSmokeWallpapers.apk
delete SYSTEM:app/MagicSmokeWallpapers.odex
delete SYSTEM:app/Maps.apk
delete SYSTEM:app/MiniDiary.apk
delete SYSTEM:app/MiniDiary.odex
delete SYSTEM:app/PressReader.apk
delete SYSTEM:app/SamsungApps.apk
delete SYSTEM:app/SamsungWidget_CalendarClock.apk
delete SYSTEM:app/SamsungWidget_CalendarClock.odex
delete SYSTEM:app/SamsungWidget_FeedAndUpdate.apk
delete SYSTEM:app/SamsungWidget_FeedAndUpdate.odex
delete SYSTEM:app/SamsungWidget_ProgramMonitor.apk
delete SYSTEM:app/SamsungWidget_ProgramMonitor.odex
delete SYSTEM:app/SamsungWidget_StockClock.apk
delete SYSTEM:app/SamsungWidget_StockClock.odex
delete SYSTEM:app/SamsungWidget_WeatherClock.apk
delete SYSTEM:app/SamsungWidget_WeatherClock.odex
delete SYSTEM:app/TATLiveWallpapersAurora.apk
delete SYSTEM:app/TATLiveWallpapersAurora.odex
delete SYSTEM:app/TATLiveWallpapersBlueSea.apk
delete SYSTEM:app/TATLiveWallpapersBlueSea.odex
delete SYSTEM:app/TATLiveWallpapersDandelion.apk
delete SYSTEM:app/TATLiveWallpapersDandelion.odex
delete SYSTEM:app/TouchWiz30Launcher.apk
delete SYSTEM:app/TouchWiz30Launcher.odex
delete SYSTEM:app/UnifiedInbox.apk
delete SYSTEM:app/UnifiedInbox.odex
delete SYSTEM:app/VisualizationWallpapers.apk
delete SYSTEM:app/VisualizationWallpapers.odex
delete SYSTEM:app/WriteandGo.apk
delete SYSTEM:app/WriteandGo.odex
show_progress 0.1 10
show_progress 0.2 0
copy_dir PACKAGE:system SYSTEM:app
show_progress 0.2 10Ya solo faltaría incluir en la carpeta /system del update.zip el Touchwiz30Launcher.apk y el Galery3D.apk modificados, comprimir las carpetas /system y /META-INF en un zip y directo a la raiz de ls sd interna.
(adjunto este ejemplo "Stock2Lite.zip")
**
Este otro equivaldría a un wipe factory-reset. Es un poco absurdo ya que el propio recovery tiene la función, pero es solo un ejemplo de lo simple que es ;)
show_progress 0.1 0
format DATA:
format DATADATA:
format CACHE:
format SDEXT:
format SDCARD:./android_secure
Recordar que podemos ponerle el nombre que queramos al update.zip, cuanto más descriptivo mejor.
Update-script en custom roms.
Vamos a analizar en este caso el de una DocROM v3.1.0
show_progress 0.1 0---> (iniciamos el proceso e iniciamos barra de progreso)
format SYSTEM: ---> (formatear SYSTEM)
delete_recursive SYSTEM:---> (borrar SYSTEM y todas sus subcarpetas recursivamente. Es redundante después de un format)
copy_dir PACKAGE:system SYSTEM: ---> (copiar nuestra carpeta system a SYSTEM)
Ahora eliminamos unos binarios que supongo están compilados por samsung y que probablemente vengan "capados" y utilizaremos toolbox, que es un mini-busybox que viene por defecto en Android, pero puede realizar operaciones que busybox es incapaz, como por ejemplo “sh” para ser root. Entonces los sustituimos por un elnace simbólico a "toolbox":
symlink toolbox SYSTEM:bin/cat
symlink toolbox SYSTEM:bin/chmod
symlink toolbox SYSTEM:bin/chown
symlink toolbox SYSTEM:bin/cmp [/quote]
...
...
show_progress 0.1 10
Ahora debemos asignar los permisos adecuados a las carpetas del sistema para que funcione adecuadamente:
set_perm usuario grupo permisos RUTA por ejemplo, root=0, shell=2000,...
**para saber más sobre permisos: http://es.wikipedia.org/wiki/Chmod (http://es.wikipedia.org/wiki/Chmod)
show_progress 0.2 0
set_perm_recursive 0 0 0755 0644 SYSTEM:---> (permisos recursivos para todo SYSTEM y subcarpetas)
set_perm_recursive 0 2000 0755 0755 SYSTEM:bin ---> (permisos específicos para /system/bin)
set_perm_recursive 0 0 0755 0755 SYSTEM:etc---> (idem para /system/etc)
set_perm 0 3003 02755 SYSTEM:bin/netcfg---> (idem para el archivo /system/bin/netcfg)
set_perm 0 3004 02755 SYSTEM:bin/ping---> (etc.)
set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluetooth
set_perm 0 0 0755 SYSTEM:etc/bluetooth
set_perm 1002 1002 0440 SYSTEM:etc/dbus.conf
set_perm 1014 2000 0550 SYSTEM:etc/dhcpcd/dhcpcd-run-hooks
set_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh
set_perm_recursive 0 0 0777 0777 SYSTEM:etc/init.d ---> (Aquí damos permisos a /system/etc/init.d para poder ejecutar scripts en el inicio. El init.rc (http://source.android.com/porting/bring_up.html) compilado en el kernel debe tener habilitado run-parts desde busybox para que funcione. En general todos los custom kernel lo llevan habilitado)
set_perm 0 0 04755 SYSTEM:xbin/su
set_perm 0 0 04755 SYSTEM:xbin/busybox
show_progress 0.2 10
Esta parte en un principio se mantiene así ROM tras ROM, la mayoría son genéricos para cualquier sistema android.
show_progress 0.3 0
symlink /system/xbin/su SYSTEM:bin/su ---> (crea un enlace simbólico de xbin/su a bin/su)
run_program PACKAGE:root --->(ejecuta un shell script que dará permisos a /bin/su e instalará busybox)
run_program PACKAGE:dalvik---> (ejecuta un script que hace un wipe a dalvik-cache, innecesario ya que luego formatearemos /data)
show_progress 0.3 10
Ya tenemos /system completo.
show_progress 0.4 0
format CACHE: --->(formatea CACHE)
format DATADATA: --->(formatea DBDATA)
format DATA: --->(formatea DATA)
copy_dir PACKAGE:data DATA: ---> (copia nuestra carpeta /data/ a /data/app)
set_perm 1000 1000 0771 DATA:app --->(da permisos específicos /data/app)
copy_dir PACKAGE:sdcard SDCARD:--->(copia nuestra carpeta /sdcard a SDCARD)
Con esto tenemos todos los archivos y herramientas básicas instaladas.
Ahora instalar un kernel y un modem.bin copiando el binario redbend_ua, el zImge y modem.bin a TMP, y ejecutandolo
copy_dir PACKAGE:updates TMP:/updates
set_perm 0 0 755 TMP:/updates/redbend_ua
run_program /tmp/updates/redbend_ua restore /tmp/updates/modem.bin /dev/block/bml12
run_program /tmp/updates/redbend_ua restore /tmp/updates/zImage /dev/block/bml7
show_progress 0.4 10
Y poco más, no tiene tampoco mucho misterio
** Solo en el caso de que necesites flashear desde un recovery que requiera verificación de firma: "E:signature verification failed" y sea compatible con "testkeys" (no compatible con recovery 3e o 2e "oficial").
Método 1:
Descargar testsign.zip adjunto y descomprimir en tu sdk/tools (asegúrate de tener el path añadido a tu sistema)
En linux necesitarás darle permisos: chmod u+x testsign.jar
Firmar: java -classpath testsign.jar testsign update.zip update-signed.zip
Puedes cambiarle el nombre de update-signed.zip a update.zip nuevamente para hacerlo compatible con recovery que solo detecten un update.zip en la raiz de la sdcard, pero no modificarlo internamente, en ese caso tendrías que volver a firmar.
Método 2:
Otra forma sería con aplicaciones Android como zipsigned o Signaptik, ambas disponibles en el market y muy sencillas de utilizar.
################################################## ########################################
Estaría bien que la gente compartiese sus update.zip personalizados ;)
Y poco más, bueno si, HACER NANDROID BACKUPS ANTES DE NADA! y tener en cuenta que desgraciadamente desde el recovery no tenemos acceso a la /sdcard :enfadadisimo:, así que si quieres hacer pruebas mejor prepara varios zip, de otra manera tendrás que reiniciar cada vez y es un auténtico coñazo.
ENJOY!