¿Cómo creo el SDK de Android con API internas y ocultas disponibles?

Quiero reconstruir el SDK de Android (o más bien solo el android.jar) para incluir API ocultas e internas.

No pude encontrar ninguna documentación o discusión sobre cómo hacer esto. Tengo un entorno de compilación Ubuntu CyanogenMod ya configurado que puede compilar cm7.

Ahora, leí que make SDK creará el SDK, pero quiero crear un SDK que incluya métodos y campos marcados como ocultos con @hide. es posible?

Lo que quiero hacer es realizar cambios en una aplicación que usa una API oculta y para reconstruirla me gustaría usar el SDK modificado.

Esto es lo que siempre hago para usar una API oculta.

1. Cree el repositorio o descargue los archivos jar desde https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
2. copiar / target / common / obj / JAVA_LIBRARIES / framework_intermediates / classes.jar (mejor renombrarlo como algo como framework_all.jar)
3. configure la ruta de construcción de su proyecto -> bibliotecas -> agregue estos frascos externos. En Order and Export, muévalo hacia arriba y antes de android.jar

He investigado un poco sobre esto y mi conclusión es sencilla: esto no se puede hacer sin bastante trabajo. Lea el resto de esta respuesta para obtener detalles sobre lo que he encontrado.

android.jaren realidad está compuesto por la "API pública" de framework.jary core.jarque se encuentra en system/frameworks/el dispositivo. android.jares una especie de lo que yo llamaría el encabezado de la biblioteca de Java, todas las implementaciones en el código de bytes real son solo una throw new RuntimeException("stub");, esto le permite construir contraandroid.jar (por ejemplo, en Eclipse), pero la ejecución debe realizarse en un dispositivo o emulador.

La API pública del SDK de Android se define mediante clases / métodos / campos que no tienen como prefijo la @{hide}anotación javadoc. Es decir todo lo que no es anotado está incluido en el SDK.

android.jarse construye a partir de las fuentes ubicadas en las out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediatesque se genera la herramienta DroidDoc ubicada enbuild/tools/droiddoc .

DroidDoc es la herramienta (probablemente adaptada de javadoc o usando javadoc) que genera la documentación real del SDK de Android. Como efecto secundario, y probablemente porque ya está analizando todo el javadoc, también arroja los stubs de Android que luego se compilan en elandroid.jar que se distribuye en el SDK.

Entonces, para incluir las cosas que están ocultas, podría, si solo desea incluir partes específicas, simplemente elimine el @hide anotación y reconstruya el SDK.

Sin embargo, si desea incluir todas las partes ocultas, las cosas se complican mucho más. Puede modificar DroidDoc (la fuente relevante está enbuild/tools/droiddoc/src/Stubs.java ) de modo que no se detecte nada como oculto. Esto es bastante trivial y lo he intentado, sin embargo, los stubs que luego se generan no se compilan en absoluto.

Mi conclusión a estas alturas es que esto simplemente no es factible. Los stubs generados si elimina la parte de DroidDoc que detecta anotaciones ocultas, simplemente no son compilables y requerirían bastante trabajo para compilarse correctamente.

Entonces, mi respuesta a sus preguntas es: No, esto no se puede hacer sin hacer mucho trabajo. Lo siento.

Una nota al margen sobre la mkstubsherramienta. mkstubsse utilizan cuando crea un complemento de SDK , es decir, los complementos que puede encontrar en el administrador de SDK de Android de los proveedores, por ejemplo, Samsung le proporciona una API adicional para cosas específicas de los teléfonos Samsung. mkstubshace lo mismo que el proceso de generación de stubs de DroidDoc, sin embargo, no usa @hideanotaciones, usa un .defsarchivo que describe qué paquetes / clases / campos incluir o excluir de su complemento SDK.

Sin embargo, todo esto es irrelevante para la pregunta, ya que la compilación del SDK de Android no usa la mkstubsherramienta. (Desafortunadamente.)

Podríamos reconstruir los archivos * .jar desde la plataforma Android.

Primero, conecte ADB a su dispositivo. Entonces corre:

adb pull /system/framework/core.jar .
adb pull /system/framework/framework.jar .

El core.jarcontienen las bibliotecas estándar de Java ( java.*) y la framework.jarcontienen las bibliotecas Android ( android.*). Esto aún no se puede utilizar, ya que los archivos reales están en formato DEX, no en formato JAR.

Podríamos convertir estos archivos * .jar con formato DEX en archivos JAR reales utilizando herramientas como dex2jar :

dex2jar core.jar
dex2jar framework.jar

Luego, extraiga estos frascos con "Agregar archivos JAR externos ..." (suponiendo que esté usando Eclipse ADT)

• haga clic derecho en Project → Properties → Java Build Path → Libraries → Add External JARs... → (Elija core-dex2jar.jary framework-dex2jar.jardesde arriba).

Esto le permitirá utilizar la API interna y algunas API de Java 7. (El APK generado, por lo que puedo ver, no contiene ningún código real de los JAR).

Para Lollipop, el flujo es un poco diferente:

1. Obtenga /system/framework/arm/boot.oat desde el dispositivo lollipop

2. Utilice 'java -jar oat2dex.jar boot boot.oat'

3. Obtendrá dos carpetas: dex y odex. Vaya a dex y haga 'java -jar dex2jar.jar framework.dex'
4. Cambie el nombre del framework.jar resultante a .zip, extraiga y busque las clases que necesita
5. Vaya a [sdk_path] / platform / [target_platform] y extraiga android.jar (primero cámbiele el nombre a zip).
6. Copie los archivos del marco extraído al android.jar extraído. Luego comprime a zip y cambia el nombre a .jar :)

ps: probablemente necesite repetir los pasos 4-6 para 'framework_classes2.dex'

Puede descargar la versión modificada android.jarpara usarla como API oculta desde este repositorio . Siga las instrucciones allí.

DroidCon 2011

Aquí Erik Hellman de Sony Ericson explica cómo acceder a las API ocultas de Android:

http://vimeo.com/30180393 (Hmm, el enlace no parece funcionar).

Ir a la Droidcon página web Día 2 abajo desplazarse a Utilización de las API Ocultos 10:15 y se puede ver allí.

¡Los enlaces están muriendo!

Encontré este: http://skillsmatter.com/podcast/os-mobile-server/hidden-api no sé cuánto tiempo estará activo

Las API oficiales del SDK de Android suelen ser suficientes para la mayoría de las aplicaciones normales. Sin embargo, a veces hay situaciones en las que un desarrollador necesita acceder a los servicios, API y recursos del sistema interno que no están publicados en las API oficiales. Afortunadamente, estas API todavía están disponibles a través de algunos trucos inteligentes y, a menudo, pueden ser útiles al desarrollar una solución nueva e innovadora sobre Android. En esta sesión, aprenderá cómo acceder y utilizar estas API ocultas y protegidas, las limitaciones de su uso y algunos trucos y consejos sobre cómo utilizarlas de forma segura y controlada en varios dispositivos de proveedores y versiones de Android. La audiencia verá varias demostraciones avanzadas que normalmente no puede hacer con Android. Espere una sesión bastante avanzada con muchos conocimientos sobre los aspectos internos de la plataforma Android.

Intenta mirar esto :

El objetivo final de estos artículos es brindar a los desarrolladores el poder de las API internas y ocultas sin usar la reflexión. Si completa todos los pasos descritos en las siguientes partes, podrá utilizar las API internas y ocultas como si fueran API públicas abiertas. No habrá necesidad de reflexionar.

Pero si está utilizando estas API no públicas, debe tener en cuenta que su aplicación corre un gran riesgo. Básicamente, no hay garantías de que las API no se rompan con la próxima actualización del sistema operativo Android. Incluso no hay garantías sobre un comportamiento consistente en dispositivos de diferentes proveedores. Estás completamente por tu cuenta.

Hay tres escenarios que puede querer seguir:

1. Habilite las API internas y ocultas (escenario A)
2. Habilite solo API oculta (escenario B)
3. Habilitar solo API interna (escenario C)

El escenario A es una suma de B y C. El escenario B es el más fácil (no requiere modificaciones en el complemento ADT de eclipse).

Escenario A : lea las partes 1 , 2 , 3 , 4 , 5

Escenario B : lea las partes 1 , 2 , 3 , 5

Escenario C : lea las partes 1 , 2 , 3 , 4 , 5

Una vez escribí algunos scripts Groovy para extraer los archivos java de un pago de repositorio de http://source.android.com/ y luego compilarlos sin la necesidad de una cadena de herramientas completa para compilar todas las fuentes de Android, incluidos los otros pasos necesarios ( embalaje, generación de recursos, etc.).

Pueden ser encontrados aquí:

https://github.com/thoutbeckers/CollectAndroid

Pero seguro que será necesario actualizarlo para cualquier cosa posterior a Gingerbread, principalmente configurando los directorios correctos en "rootdirs" en el archivo de configuración (CollectConfig.groovy).

En ese momento, usé esto regularmente para el desarrollo con todas las API y fuentes ocultas (también problemáticas en ese momento) disponibles.

Como se mencionó en otra parte, com / android / internal / ** todavía estará oculto en las versiones recientes de ADT debido a la regla de acceso agregada.

La respuesta de Long funcionó para mí, pero todavía me faltaban algunas clases que necesitaba, en particular android.provider.Telephony. Pude agregarlo así:

1. Extraiga el archivo framework.jar

   mkdir /tmp/framework
   cp framework.jar /tmp
   cd /tmp/framework
   jar xvf ../framework.jar
   mv android classes
   

2. Construya el repositorio de Android, que creará el directorio out / target / common / obj / JAVA_LIBRARIES

3. Encuentra dónde están las clases que faltan

   $ cd /path/to/out/target/common/obj/JAVA_LIBRARIES
   $ find . | grep "/Telephony.class"
   ./telephony-common_intermediates/classes/android/provider/Telephony.class
   ./android_stubs_current_intermediates/classes/android/provider/Telephony.class
   

4. Agregue las nuevas clases y reconstruya el archivo JAR del marco

   cd /tmp/framework
   cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes .
   cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/telephony-common_intermediates/classes .
   cd classes
   jar cvf ../framework.jar .
   

O simplemente puede ser perezoso e incluir todas las clases en un archivo jar gigante:

cd /tmp/framework
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/*/classes .
cd classes
jar cvf ../framework.jar .

No puedo comentar, pero esto es básicamente un comentario para la excelente respuesta de @ KennyTM ( https://stackoverflow.com/a/13550030/2923406 ):

Si se encuentra con el siguiente error en Eclipse:

The type com.android.internal.util.Predicate cannot be resolved. It is indirectly referenced from required .class   files

(es decir, android.internal. * no está disponible)

Entonces, una posible solución es aplicar el mismo método para /system/framework/framework2.jar. Usando el emulador de Android para SDK19 tengo este frasco adicional. En mi HTC One hay incluso un framework3.jar.