¿Cómo separar apk y odex en el sistema odex?

Si desea el sistema odex, primero debe procesar los archivos jar en /system/framework/, seguido del apk y jar en /system/app.

En otras palabras:

Si los archivos bajo el marco no están odexados y son todos archivos jar separados, incluso si hay archivos odex en otros lugares del sistema, como / sistema/aplicación Debería no ser válido.

Si los archivos bajo el marco han sido odexados, entonces apk y jar en otros lugares pueden ejecutarse normalmente con o sin odex.

El paquete 0901 es inicialmente deodex, es decir, todas las apks están fusionadas y no existen archivos odex. Si desea el sistema odex, puede ejecutar el odex.bat descomprimido de ese paquete para lograr el objetivo.

odex.bat llama principalmente a los dos scripts /system/xbin/odex_framework y /system/xbin/odex_app. (También debería ser posible ejecutar estos dos scripts directamente en el teléfono móvil usando un emulador de terminal, lo que significa que el proceso de odexing no debería depender de una computadora)

Odex_framework y odex_app requieren togetherbox y dexopt- wrapper, zip, zipalign y otros comandos, por lo que estas herramientas deben prepararse con anticipación. (Estas herramientas de línea de comandos de terceros en el paquete 0901 se encuentran básicamente en el directorio /system/xbin. Es mejor usar software relacionado para instalar Busybox. Simplemente copie los otros comandos y cambie los permisos).

Lo siguiente es mirar directamente el script /system/xbin/odex_framework. Es responsable de odexar archivos bajo el marco. El contenido es el siguiente. Las líneas que comienzan con ### son todas instrucciones escritas por mí.

#!/system/bin/sh

### Monte la partición del sistema como legible y grabable, y cambie el directorio a /system/framework.

busybox mount -o rw, remount /system

cd /system/framework

### El comando dexopt-wrapper se usa directamente para generar archivos odex . Por ejemplo, dexopt-wrapper /system/framework/core.jar /system/framework/core.odex genera core.odex a partir de core.jar.

### Además, el archivo odex bajo el marco tiene requisitos de orden. El orden específico se puede encontrar en el archivo init.rc en el directorio raíz del teléfono móvil. busque la línea BOOTCLASSPATH, seguida de Listar algunos archivos jar, luego el orden de nuestro odex aquí debe seguir el orden indicado. El orden puede ser diferente para cada modelo y versión, por lo que el orden debe organizarse de acuerdo con la situación real; de lo contrario, es probable que el odex generado no se inicie.

### Procesa un archivo por línea y ejecútalos en orden.

dexopt-wrapper /system/framework/core.jar /system/framework/core.odex

dexopt-wrapper /system/framework/core-junit.jar /system/framework /core-junit.odex

dexopt-wrapper /system/framework/bouncycastle.jar /system/framework/bouncycastle.odex

dexopt-wrapper /system/framework/ext.jar /system/framework/ext.odex

dexopt-wrapper /system/framework/framework.jar /system/framework/framework.odex

dexopt-wrapper /system/framework/android .policy.jar /system/framework/android.policy.odex

dexopt-wrapper /system/framework/services.jar /system/framework/services.odex

dexopt-wrapper /system/framework/apache-xml.jar /system/framework/apache-xml.odex

dexopt-wrapper /system/framework/filterfw.jar /system/framework/filterfw.odex

### Una vez procesados ​​los archivos que deben procesarse en orden, no es necesario preocuparse por el orden de otros archivos. Simplemente use una declaración for para procesarlos de manera uniforme.

para j en /system/framework/*.jar

do

odexj=`echo $j | odex/g'`

if [ -f $odexj ]; entonces

echo " "

echo "$odexj ya existe, omitiendo"

echo " "

else

echo "dexopt-wrapper $j $odex"

dexopt-wrapper $j $odexj

fi

hecho

### En este punto, todos los archivos han generado los archivos odex correspondientes. El siguiente paso es eliminar las clases en el archivo jar y el archivo originales. Optimización de zipalign, este paso no debería ser necesario pero se recomienda solucionarlo. También lo maneja de manera uniforme la declaración for. El comando zip es responsable de eliminar el empaquetado de clases.dex y el comando zipalign es responsable de la optimización de zipalign.

para el nombre de archivo en `find . -name '*.jar'`

realiza

# paso 1: ¿logramos odexar con éxito?

if [ -f `echo $nombredearchivo | sed 's/\(.*\.\)jar/\1odex/'` ]

entonces

# paso 2 - eliminar el files.dex del jar

zip -d $filename schools.dex

# paso 3 - zipalign, por si acaso

zipalign -f - v 4 $nombrearchivo $nombrearchivo.nuevo

mv $nombrearchivo.nuevo $nombrearchivo

fi

hecho

### Par solo framework-res.apk realiza la optimización zipalign porque la declaración anterior es solo para archivos jar. Y no hay ningún archivoclasses.dex en framework-res.apk, por lo que no necesita procesamiento odex.

zipalign -f -v 4 framework-res.apk framework-res.apk.new

mv framework-res.apk.new framework-res.apk

### Cambie los permisos de todos los archivos bajo el marco.

chmod 644 /system/framework/*

### Borre el caché dalvik del sistema y salga del script.

busybox rm -f /data/dalvik-cache/*

salir 0

Los archivos bajo el marco de script anterior han sido odexados, a continuación se puede procesar archivos en /system/app. Por supuesto, debería poder ejecutarse normalmente sin procesar archivos en app.

odex_app procesa archivos bajo la aplicación. El formato es similar a odex_framework y más simple, porque los archivos internos no tienen requisitos de orden.