Comment créer le SDK Android avec les API cachées et internes disponibles?

Je veux reconstruire le SDK Android (ou plutôt uniquement le fichier Android.jar) pour inclure les API cachées et internes.

Je n’ai trouvé aucune documentation ou discussion sur la façon de procéder. J’ai déjà un environnement de construction Ubuntu CyanogenMod qui est capable de générer cm7.

Maintenant, je lis que make SDK va construire le SDK, mais je veux créer un SDK qui inclut des méthodes et des champs marqués comme masqués à l’aide de @hide. Est-ce possible?

Ce que je veux faire, c’est apporter des modifications à une application qui utilise une API cachée et, pour la reconstruire, j’aimerais utiliser le SDK modifié.

C’est ce que je fais toujours pour utiliser l’API caché.

  1. Construisez les référentiels ou téléchargez les fichiers à partir de https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
  2. copier vers / target / common / obj / JAVA_LIBRARIES / framework_intermediates / classes.jar (mieux vaut le renommer comme framework_all.jar)
  3. configurez votre chemin de construction de projet -> bibliothèques -> ajoutez ces jars externes. Dans Order and Export, déplacez-le vers le haut et avant android.jar

J’ai fait quelques recherches à ce sujet, et ma conclusion est simple: cela ne peut se faire sans beaucoup de travail. Lisez le rest de cette réponse pour plus de détails sur ce que j’ai trouvé.


android.jar est en fait composé de “public api” de framework.jar et core.jar qui se trouve dans system/frameworks/ sur le périphérique. android.jar est une sorte de ce que j’appellerais un en-tête de bibliothèque Java, toute l’implémentation dans le code d’octet réel est juste une throw new RuntimeException("stub"); , cela vous permet de construire avec android.jar (par exemple dans Eclipse), mais l’exécution doit être effectuée sur un périphérique ou un émulateur.

L’API publique du SDK Android est définie par des classes / méthodes / champs non préfixés par l’annotation @{hide} javadoc. C’est-à-dire que tout ce qui n’est pas annoté est inclus dans le SDK.

android.jar est construit à partir des sources situées dans out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediates lui-même généré par l’outil DroidDoc situé dans build/tools/droiddoc .

DroidDoc est l’outil (probablement adapté de javadoc ou utilisant javadoc) qui génère la documentation du SDK Android. Comme effet secondaire, et probablement parce qu’il est déjà en train d’parsingr tout le javadoc, il éjecte aussi les stubs android qui sont ensuite compilés dans android.jar qui est dissortingbué dans le SDK.

Donc, pour inclure ce qui est caché, vous pouvez, si vous voulez seulement inclure des parties spécifiques, supprimer l’annotation @hide et reconstruire le SDK.

Cependant, si vous souhaitez inclure toutes les parties cachées, les choses se compliquent beaucoup. Vous pouvez modifier DroidDoc (la source appropriée est dans build/tools/droiddoc/src/Stubs.java ) de sorte que rien ne soit détecté comme caché. C’est assez sortingvial et j’ai essayé ceci, cependant les stubs qui sont alors générés ne comstacknt pas du tout.

Ma conclusion est que ce n’est tout simplement pas réalisable. Les stubs générés si vous supprimez la partie de DroidDoc qui détecte les annotations cachées, ne sont tout simplement pas compilables, et il faudrait beaucoup de travail pour les comstackr correctement.

Donc, ma réponse à vos questions est la suivante: non, cela ne peut pas être fait sans beaucoup de travail. Pardon.


Une remarque sur l’outil mkstubs . mkstubs est utilisé lorsque vous mkstubs un addon SDK , c.-à-d. les addons que vous pouvez trouver dans le gestionnaire de SDK Android auprès des fournisseurs, par exemple Samsung vous fournissant une API supplémentaire pour les éléments spécifiques aux téléphones Samsung. mkstubs fait beaucoup comme le processus de génération de stubs DroidDoc, mais n’utilise pas les annotations @hide , il utilise un fichier .defs décrivant les paquets / classes / champs à inclure ou à exclure de votre addon SDK.

Cependant, tout cela n’est pas pertinent pour la question, car la version du SDK Android n’utilise pas l’outil mkstubs . (Malheureusement.)

Nous pourrions reconstruire les fichiers * .jar à partir de la plate-forme Android.

Tout d’abord, connectez ADB à votre appareil. Puis lancez:

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

Le core.jar contient les bibliothèques Java standard ( java.* ) Et le framework.jar contient les bibliothèques Android ( android.* ). Ce n’est pas encore utilisable, car les fichiers réels sont au format DEX, pas au format JAR.

Nous pourrions convertir ces * .jars au format DEX en véritables fichiers JAR en utilisant des outils tels que dex2jar :

 dex2jar core.jar dex2jar framework.jar 

Ensuite, insérez ces fichiers en utilisant “Ajouter des fichiers JAR externes …” (en supposant que vous utilisez Eclipse ADT)

  • Faites un clic droit sur Project → Properties → Java Build Path → Libraries → Add External JARs core-dex2jar.jar Project → Properties → Java Build Path → Libraries → Add External JARs … → (Choisissez les core-dex2jar.jar et framework-dex2jar.jar ci framework-dex2jar.jar dessus).

Cela vous permettra d’utiliser les API internes et certaines API Java 7. (Le APK généré, pour autant que je sache, ne contient aucun code réel des JAR.)

Pour Lollipop, le débit est peu différent:

  1. Obtenir /system/framework/arm/boot.oat à partir du périphérique sucette

  2. Utilisez ‘java -jar oat2dex.jar boot boot.oat’

  3. Vous aurez 2 dossiers: dex et odex. Aller à dex et faire ‘java -jar dex2jar.jar framework.dex’
  4. Renommez le framework.jar résultant en .zip, extrayez et trouvez les classes dont vous avez besoin
  5. Accédez à [sdk_path] / platform / [target_platform] et extrayez android.jar (renommez-le d’abord en zip).
  6. Copier les fichiers du framework extrait vers android.jar extrait. Ensuite, compressez pour compresser et renommer en .jar 🙂

ps: vous avez probablement besoin de répéter les étapes 4-6 pour ‘framework_classes2.dex’

DroidCon 2011

Erik Hellman de Sony Ericson explique ici comment accéder aux API Android cachées:

http://vimeo.com/30180393 (le lien Hmm ne semble pas fonctionner).

Aller à la page Web DroidCon Jour 2 faire défiler jusqu’à Utiliser les API cachés 10:15 et vous pouvez le regarder là.

Les liens meurent!

J’ai trouvé celui-ci: http://skillsmatter.com/podcast/os-mobile-server/hidden-api ne sais pas combien de temps ça va durer

Les API officielles du SDK Android sont généralement suffisantes pour la plupart des applications normales. Cependant, il arrive parfois qu’un développeur ait besoin d’accéder aux services système internes, aux API et aux ressources qui ne sont pas publiés dans les API officielles. Heureusement, ces API sont toujours disponibles grâce à des astuces intelligentes et peuvent souvent être utiles lors du développement de nouvelles solutions innovantes sur Android. Au cours de cette session, vous apprendrez comment accéder et utiliser ces API cachées et protégées, les limites de leur utilisation et quelques astuces pour les utiliser de manière sûre et contrôlée sur plusieurs appareils et versions d’Android. Le public verra plusieurs démos avancées que vous ne pouvez normalement pas faire avec Android. Attendez-vous à une session assez avancée avec de nombreuses informations sur les composants internes de la plate-forme Android.

Essayez de regarder ceci :

L’objective ultime de ces articles est de donner aux développeurs la puissance des API internes et cachées sans recourir à la reflection. Si vous terminez toutes les étapes décrites dans les parties suivantes, vous pourrez utiliser les API internes et cachées comme si elles étaient des API ouvertes publiques. Il n’y aura pas besoin de reflection.

Mais si vous utilisez ces API non publiques, vous devez savoir que votre application est très risquée. Fondamentalement, il n’y a aucune garantie que les API ne seront pas cassées avec la prochaine mise à jour du système d’exploitation Android. Il n’ya même aucune garantie de comportement cohérent sur les appareils de différents fournisseurs. Vous êtes complètement seul.

Vous pouvez suivre trois scénarios:

  1. Activer les API internes et cachées (scénario A)
  2. Activer uniquement les API masquées (scénario B)
  3. Activer uniquement l’ API interne (scénario C)

Le scénario A est la sum de B et de C. Le scénario B est le plus simple (ne nécessite aucune modification du plug-in ADT par éclipse).

Scénario A : lire les parties 1 , 2 , 3 , 4 , 5

Scénario B : lire les parties 1 , 2 , 3 , 5

Scénario C : lire les parties 1 , 2 , 3 , 4 , 5

Vous pouvez télécharger le fichier android.jar modifié à utiliser comme API masquée à partir de ce référentiel . Suivez les instructions ici.

Une fois, j’ai écrit des scripts Groovy pour extraire les fichiers java d’une caisse repo depuis http://source.android.com/ , puis les comstackr sans avoir besoin d’une chaîne d’outils complète pour comstackr toutes les sources Android, y compris les autres étapes nécessaires ( emballage, génération de ressources, etc.).

Ils peuvent être trouvés ici:

https://github.com/thoutbeckers/CollectAndroïde

Mais à coup sûr, cela nécessitera une mise à jour après Gingerbread, principalement en définissant les bons répertoires dans “rootdirs” dans le fichier de configuration (CollectConfig.groovy).

A l’époque, je l’utilisais régulièrement pour le développement avec toutes les API et sources cachées (également problématiques à l’époque) disponibles.

Comme mentionné ailleurs, com / android / internal / ** sera toujours caché dans les versions récentes d’ADT en raison de la règle d’access définie.