Comment puis-je construire le SDK Android avec des API internes et cachées disponibles?

C'est ce que je fais toujours pour utiliser l'api cachée.

1. construisez les pots de repo ou de téléchargement de https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
2. copy out/target/common/obj/JAVA_LIBRARIES/framork_intermediates / classes.jar (mieux vaut le renommer comme quelque chose comme cadrork_all.jar)
3. config de votre projet de construction chemin-->bibliothèques --> ajouter un externe pots. Dans L'ordre et L'exportation, déplacer vers le haut et avant android.jar

j'ai fait quelques recherches à ce sujet, et ma conclusion est simplement: cela ne peut pas être fait sans un peu de travail. Lire le reste de cette réponse pour plus de détails sur ce que j'ai trouvé.

android.jar est en fait constitué de l '" api publique "de framework.jar et core.jar qui se trouve dans system/frameworks/ sur l'appareil. android.jar est une sorte d'en-tête de bibliothèque Java, tous implémentation dans le code octet actuel sont juste un throw new RuntimeException("stub"); , cela vous permet de construire contre android.jar (par exemple dans Eclipse), mais l'exécution doit être effectuée sur un appareil ou un émulateur.

L'API publique du SDK Android est défini par les classes/méthodes/champs qui sont et non préfixé avec l'annotation @{hide} javadoc. C'est-à-dire: tout ce qui est et non 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 qui elle-même est générée par l'outil DroidDoc situé dans build/tools/droiddoc .

DroidDoc est l'outil (probablement adapté de javadoc, ou en utilisant javadoc) qui génère la documentation SDK Android réelle. Comme effet secondaire, et probablement parce qu'il analyse déjà tout le javadoc, il recrache aussi les stubs android qui sont alors compilés dans le android.jar qui est distribué dans le SDK.

donc pour inclure les choses qui sont cachées vous pouvez, si vous voulez seulement inclure des pièces spécifiques, il suffit de supprimer l'annotation @hide et de reconstruire le SDK.

cependant si vous voulez inclure toutes les parties cachées choses deviennent beaucoup plus compliquées. Vous pouvez modifier DroidDoc (la source pertinente est dans build/tools/droiddoc/src/Stubs.java ) de sorte que rien n'est détecté comme caché. Ce est assez trivial et j'ai essayé cela, cependant les stubs qui sont alors générés ne compilent pas du tout.

ma conclusion est maintenant que ce n'est tout simplement pas faisable. Les talons 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 nécessiteraient un travail considérable pour compiler correctement.

donc ma réponse à vos questions est: non, cela ne peut pas être fait, sans faire beaucoup de travail. Désolé.

Une note de côté sur le mkstubs de l'outil. mkstubs sont utilisés lorsque vous construisez un SDK addon , c'est-à-dire les addons que vous pouvez trouver dans le gestionnaire SDK Android de vendeurs, par exemple Samsung vous fournir une API supplémentaire pour les choses spécifiques aux téléphones Samsung. mkstubs fait à peu près la même chose que le processus de production de stubs de DroidDoc, mais il n'utilise pas les annotations @hide , il utilise un .defs fichier décrivant les paquets/classes / champs à inclure ou à exclure de votre addon SDK.

cependant, tout cela n'est pas pertinent à la question, car la construction SDK Android ne pas utiliser l'outil mkstubs . (Malheureusement.)

nous pourrions reconstruire le *.les fichiers jar de la plate-forme Android.

d'abord, connectez ADB à votre appareil. Puis exécuter:

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 actuels sont au format DEX, pas au format JAR.

nous pourrions convertir ces DEX-formaté *.pots en réel Bocaux utilisant des outils tels que dex2jar :

dex2jar core.jar
dex2jar framework.jar

puis tirer dans ces pots en utilisant " ajouter des pots externes..."(en supposant que vous utilisez Eclipse ADT)

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

cela vous permettra d'utiliser les API internes et certaines Java 7. (L'APK générée, pour autant que je puisse voir, ne contient pas code réel des bocaux.)

pour Lollipop le flux est peu différent:

1. Get /system/framework/arm/boot.oat du dispositif de sucette

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

3. vous aurez 2 dossiers: dex et odex. Aller à dex et faire 'java-jar dex2jar.jar cadre de.dex '
4. renommer resulting Framework.jar .zip, extraire et trouver les classes dont vous avez besoin
5. aller à[sdk_path]/plates-formes/[target_platform] et extraire android.pot (d'abord renommer en zip).
6. copie des fichiers du framework extrait à android extrait.pot. Puis compresser en zip et renommer en .jar:)

ps: vous devez probablement répéter les étapes 4-6 pour 'framork_classes2.dex '

DroidCon 2011

ici Erik Hellman de Sony Ericson explique comment accéder à l'API Android cachée:

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

allez à la page jour 2 faites défiler jusqu'à en utilisant les API cachées 10:15 et vous pouvez le regarder là.

sont en train de mourir!

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

les API officielles dans le SDK Android est généralement suffisant pour la plupart des applications normales. Toutefois, il arrive parfois qu'un développeur ait besoin d'accéder aux services internes du système, aux API et aux ressources qui ne sont pas publiées dans les API officielles. Heureusement, ces API sont encore disponible grâce à quelques astuces astucieuses et peut souvent être utile lors du développement de solution nouvelle et innovante sur Android. Dans cette session, vous apprendrez comment accéder et utiliser ces API cachées et protégées, les limites de leur utilisation et quelques conseils sur la façon de les utiliser d'une manière sûre et contrôlée sur les appareils de plusieurs fournisseurs et les versions 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 beaucoup d'idées dans les internes de la plate-forme Android.

Essayez de regarder ce :

le but ultime de ces articles est de donner aux développeurs la puissance des API internes et cachées sans utiliser la réflexion. Si vous suivez toutes les étapes décrites dans les prochaines parties, vous pourrez utiliser les API internes et cachées comme s'il s'agissait d'API ouvertes au public. Il n'y aura pas besoin de réflexion.

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 sera pas cassé avec la prochaine mise à jour à Android OS. Il n'y a même pas de garanties sur un comportement cohérent entre les appareils de différents fournisseurs. Vous êtes complètement sur votre propre.

il y a trois scénarios que vous pourriez vouloir suivre:

1. permettent à la fois interne et caché APIs (scénario a)
2. Activer uniquement caché API (scénario B)
3. Activer uniquement interne API (scénario C)

le scénario A est une somme de B et C. Le Scénario B est le plus facile (ne nécessite aucune modification de plugin ADT eclipse).

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

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

scénario c : lire parties 1 , 2 , 3 , 4 , 5

vous pouvez télécharger le android.jar modifié pour être utilisé comme APIs caché de ce dépôt . Suivez les instructions.

j'ai un jour écrit quelques scripts Groovy pour extraire les fichiers java d'une caisse de pension de http://source.android.com / et les compiler ensuite sans avoir besoin d'une chaîne d'outils complète pour compiler toutes les sources android, y compris les autres étapes nécessaires (empaquetage, génération de ressources, etc.).

ils peuvent être trouvés ici:

https://github.com/thoutbeckers/CollectAndroid

mais pour sûr il faudra mettre à jour pour tout ce qui suit Gingerbread, principalement en définissant les répertoires corrects dans "rootdirs" dans le fichier de configuration (CollectConfig.groovy).

à 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 / ** seront toujours cachés dans les versions récentes de L'ADT en raison de la règle d'accès aded.

Il y a un post de blog sur le Sony Ericsson page web avec Erik Hellmans parler et de code et quelques références qui je pense sera utile pour vous.

salutations

/Johan

Je ne peux pas commenter mais c'est essentiellement un commentaire à @Kennytm's ( https://stackoverflow.com/a/13550030/2923406 ) excellente réponse:

si vous vous trouvez avec L'erreur suivante dans Eclipse:

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

(c'est-à-dire androïde.interne.* n'est pas disponible)

alors une solution possible est d'appliquer la même méthode pour /system/framework/cadre2.pot. Utilisation de L'émulateur Android pour SDK19 J'ai ce pot. Sur mon HTC One il y a même un cadre3.pot.

la réponse de Long a fonctionné pour moi, mais je manquais encore quelques cours dont j'avais besoin, en particulier android.Fournisseur.Téléphonie. J'ai pu l'ajouter ainsi:

1. trouver où la classe est

   $ 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
   

2. Ajouter de nouvelles classes et de reconstruire le cadre de fichier JAR

   cd /path/to/temp/folder
   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 .
   

ou vous pouvez juste être paresseux et inclure tous des classes en un seul fichier jar géant:

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