Comment créer le SDK Android SDK avec des API internes et cachées disponibles?
Je veux reconstruire le Android SDK (ou plutôt seulement le Android.jar) pour inclure les API cachées et internes.
Je n'ai trouvé aucune documentation ni discussion sur la façon de procéder. J'ai un environnement de construction Ubuntu CyanogenMod déjà configuré qui est capable de construire cm7.
Maintenant, j'ai lu que make SDK va construire le SDK mais je veux construire un SDK qui inclut des méthodes et des champs qui sont marqués comme masqués en utilisant @hide. Est-ce possible?
Ce que je veux faire, c'est apporter des modifications à une application qui utilise une API cachée et afin de la reconstruire, je voudrais utiliser le SDK modifié.
C'est ce que je fais toujours pour utiliser des API cachées.
- Créez le référentiel ou téléchargez les fichiers jar à partir de https://sites.google.com/site/hippunosource/home/Android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
- copier/target/common/obj/Java_LIBRARIES/framework_intermediates/classes.jar (il vaut mieux le renommer comme quelque chose comme framework_all.jar)
- configurez le chemin de construction de votre projet -> bibliothèques -> ajoutez ces pots externes. Dans Ordre et exportation, déplacez-le 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. Lisez le reste de cette réponse pour plus de détails sur ce que j'ai trouvé.
Android.jar Est en fait composé de l '"API publique" de framework.jar Et core.jar Qui se trouve dans system/frameworks/ Sur l'appareil. Android.jar Est une sorte de ce que j'appellerais Java, toute l'implémentation dans le code d'octets réel n'est qu'un throw new RuntimeException("stub");, cela vous permet contre 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 Android est définie par des classes/méthodes/champs qui ne sont pas préfixés du @{hide} Annotation javadoc, c'est-à-dire que tout ce qui 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 Qui lui-même est généré 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 véritable documentation Android SDK. En tant qu'effet secondaire, et probablement parce qu'il est déjà en analysant tous les javadoc, il crache également les Android stubs qui sont ensuite compilés dans le Android.jar qui est distribué dans le SDK.
Donc, pour inclure les éléments cachés, vous pouvez, si vous souhaitez uniquement inclure des parties spécifiques, supprimer simplement l'annotation @hide Et reconstruire le SDK.
Cependant, si vous souhaitez inclure toutes les parties cachées, les 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 ne soit détecté comme caché. C'est assez trivial et j'ai essayé, mais les stubs qui sont ensuite générés ne se compilent pas du tout.
Ma conclusion est 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, n'est tout simplement pas compilable et nécessiterait pas mal de travail pour être compilé correctement.
Donc ma réponse à vos questions est: non, cela ne peut pas être fait sans faire beaucoup de travail. Désolé.
Une note latérale sur l'outil mkstubs. mkstubs sont utilisés lorsque vous construisez un SDK addon, c'est-à-dire les addons que vous pouvez trouver dans le Android SDK manager de fournisseurs, par exemple Samsung vous une API supplémentaire pour les éléments spécifiques aux téléphones Samsung. mkstubs fait la même chose que le processus de génération de stubs DroidDoc, mais il n'utilise pas d'annotations @hide, il utilise un fichier .defs décrivant les packages/classes/champs à inclure ou à exclure de votre module SDK.
Cependant, cela n'est pas pertinent pour la question, car le Android SDK build n'utilise pas le mkstubs outil. (Malheureusement.)
Nous pourrions reconstruire les fichiers * .jar à partir de la plateforme Android.
Tout d'abord, connectez ADB à votre appareil. Exécutez ensuite:
adb pull /system/framework/core.jar .
adb pull /system/framework/framework.jar .
Le core.jar contient les bibliothèques standard Java (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 de vrais fichiers JAR en utilisant des outils tels que dex2jar :
dex2jar core.jar
dex2jar framework.jar
Tirez ensuite ces pots en utilisant "Ajouter des fichiers JAR externes ..." (en supposant que vous utilisez Eclipse ADT)
- clic droit sur
Project → Properties → Java Build Path → Libraries → Add External JARs... → (Choisissez lecore-dex2jar.jaretframework-dex2jar.jard'en haut).
Cela vous permettra d'utiliser les API internes et certaines Java 7. (Pour autant que je sache, l'APK généré ne contient pas de code réel provenant des JAR).)
Pour Lollipop, le flux est peu différent:
Obtenez /system/framework/arm/boot.oat à partir du périphérique Lollipop
Utilisez 'Java -jar oat2dex.jar boot boot.oat'
- Vous obtiendrez deux dossiers: dex et odex. Allez dans dex et faites 'Java -jar dex2jar.jar framework.dex'
- Renommez le framework.jar résultant en .Zip, extrayez et trouvez les classes dont vous avez besoin
- Accédez à [sdk_path]/plates-formes/[target_platform] et extrayez Android.jar (renommez-le d'abord en Zip).
- Copiez les fichiers du framework extrait vers Android.jar extrait. Compressez ensuite en Zip et renommez en .jar :)
ps: vous avez probablement besoin de répéter les étapes 4 à 6 pour 'framework_classes2.dex'
Ici Erik Hellman de Sony Ericson explique comment accéder aux API cachées Android:
http://vimeo.com/3018039 (Le lien Hmm ne semble pas fonctionner).
Allez au page Web DroidCon Jour 2 faites défiler jusqu'à en utilisant les API cachées 10:15 et vous pouvez le regarder là-bas.
Les liens meurent!
J'ai trouvé celui-ci: http://skillsmatter.com/podcast/os-mobile-server/hidden-api ne sais pas combien de temps cela durera
Les API officielles du SDK Android SDK sont généralement suffisantes pour la plupart des applications normales. Cependant, dans certains cas, un développeur doit avoir accès aux services système internes, aux API et aux ressources qui ne sont pas publiées dans le API officielles. Heureusement, ces API sont toujours disponibles grâce à des astuces astucieuses et peuvent souvent être utiles lors du développement de solutions nouvelles et innovantes par-dessus 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 et astuces sur la façon de les utiliser de manière sûre et contrôlée sur plusieurs appareils de fournisseurs et 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'informations sur les fonctionnalités internes de la plate-forme Android.
Essayez de regarder ceci :
L'objectif 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 effectuez toutes les étapes décrites dans les parties suivantes, vous pourrez utiliser les API Interne et Caché comme s'il s'agissait d'API ouvertes publiques. Il n'y aura pas besoin de réflexion.
Mais si vous utilisez ces API non publiques, sachez que votre application est en grand danger. Fondamentalement, il n'y a aucune garantie que les API ne seront pas rompues avec la prochaine mise à jour vers Android OS. Il n'y a même aucune garantie quant au comportement cohérent entre les appareils de différents fournisseurs. Vous êtes complètement seul.
Vous pouvez suivre trois scénarios:
- Activez les API interne et masqué (scénario A)
- Activer uniquement caché API (scénario B)
- 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 simple (ne nécessite aucune modification du plugin Eclipse ADT).
Scénario A : lire les parties 1 , 2 , , 4 , 5
Vous pouvez télécharger le Android.jar à utiliser comme API masquées de ce référentiel . Suivez les instructions qui s'y trouvent.
J'ai écrit une fois quelques scripts Groovy pour extraire les fichiers Java à partir d'un retrait repo de http://source.Android.com/ puis les compiler sans avoir besoin de 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 bien 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).
À 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 masqué dans les versions récentes d'ADT en raison de la règle d'accès ajoutée.
Réponse de Long a fonctionné pour moi, mais il me manquait encore certaines classes dont j'avais besoin, en particulier Android.provider.Telephony. J'ai pu l'ajouter comme ceci:
Trouvez où se trouve la classe
$ 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.classAjoutez les nouvelles classes et reconstruisez le fichier JAR du framework
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 simplement être paresseux et inclure toutes les classes dans un fichier bocal géant:
cd /path/to/temp/folder
cp -r /path/to/out/target/common/obj/Java_LIBRARIES/*/classes .
cd classes
jar cvf ../framework.jar .
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 retrouvez avec l'erreur suivante dans Eclipse:
The type com.Android.internal.util.Predicate cannot be resolved. It is indirectly referenced from required .class files
(autrement dit, Android.internal. * n'est pas disponible)
Ensuite, une solution possible consiste à appliquer la même méthode pour /system/framework/framework2.jar. En utilisant l'émetteur Android pour SDK19, j'ai ce pot supplémentaire. Sur mon HTC One, il y a même un framework3.jar.