Wie erstelle ich das Android SDK mit versteckten und internen APIs?

Ich möchte das Android SDK (oder besser nur die android.jar) neu erstellen, um versteckte und interne APIs einzuschließen.

Ich konnte keine Dokumentation oder Diskussion darüber finden, wie ich vorgehen sollte. Ich habe bereits eine Ubuntu CyanogenMod-Build-Umgebung eingerichtet, die cm7 erstellen kann.

Jetzt habe ich gelesen, dass make SDK das SDK erstellt, aber ich möchte ein SDK erstellen, das Methoden und Felder enthält, die mit @hide als ausgeblendet markiert sind. Ist das möglich?

Ich möchte Änderungen an einer Anwendung vornehmen, die eine versteckte API verwendet. Um sie neu zu erstellen, möchte ich das geänderte SDK verwenden.

Dies ist, was ich immer tue, um versteckte API zu verwenden.

1. Erstellen Sie das Repo oder laden Sie die Gläser von https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong herunter
2. Kopieren Sie out / target / common / obj / JAVA_LIBRARIES / framework_intermediates / classes.jar (besser umbenennen in etwas wie framework_all.jar).
3. Konfigurieren Sie Ihren Projekterstellungspfad -> Bibliotheken -> fügen Sie diese externen Jars hinzu. Verschieben Sie es in Order and Export nach oben und vor android.jar

Ich habe einige Nachforschungen angestellt, und meine Schlussfolgerung lautet einfach: Dies kann nicht ohne viel Arbeit geschehen. Lesen Sie den Rest dieser Antwort, um Einzelheiten zu dem zu erfahren, was ich gefunden habe.

android.jarbesteht eigentlich aus der "öffentlichen API" von framework.jarund core.jardie sich system/frameworks/auf dem Gerät befindet. android.jarist eine Art von dem, was ich als Java-Bibliotheksheader bezeichnen würde. Alle Implementierungen im eigentlichen Bytecode sind nur a throw new RuntimeException("stub");. Dies ermöglicht es Ihnen, dagegen zu bauen android.jar(z. B. in Eclipse), aber die Ausführung muss auf einem Gerät oder Emulator durchgeführt werden.

Die öffentliche API des Android SDK wird durch Klassen / Methoden / Felder definiert, denen die Javadoc-Annotation nicht vorangestellt ist @{hide}. Dh alles, was nicht kommentiert ist, ist im SDK enthalten.

android.jarwird aus den Quellen erstellt, in out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediatesdenen sich das Tool DroidDoc befindet build/tools/droiddoc.

DroidDoc ist das Tool (wahrscheinlich aus Javadoc angepasst oder mithilfe von Javadoc), das die eigentliche Android SDK-Dokumentation generiert. Als Nebeneffekt und wahrscheinlich, weil es bereits alle Javadoc analysiert, spuckt es auch die Android-Stubs aus, die dann in das kompiliert werdenandroid.jar im SDK verteilten .

Um das verborgene Material einzuschließen, können Sie, wenn Sie nur bestimmte Teile einschließen möchten, einfach das entfernen @hide Anmerkung und das SDK neu erstellen.

Wenn Sie jedoch alle versteckten Teile einbeziehen möchten, werden die Dinge viel komplizierter. Sie können DroidDoc ändern (die entsprechende Quelle befindet sich inbuild/tools/droiddoc/src/Stubs.java ) so dass nichts als versteckt erkannt wird. Dies ist ziemlich trivial und ich habe es versucht, aber die Stubs, die dann generiert werden, werden überhaupt nicht kompiliert.

Mein Fazit ist inzwischen, dass dies einfach nicht machbar ist. Die Stubs, die generiert werden, wenn Sie den Teil von DroidDoc entfernen, der versteckte Anmerkungen erkennt, sind einfach nicht kompilierbar und erfordern eine Menge Arbeit, um korrekt zu kompilieren.

Meine Antwort auf Ihre Fragen lautet also: Nein, dies kann nicht ohne viel Arbeit geschehen. Es tut uns leid.

Eine Randnotiz zum mkstubsTool. mkstubswerden verwendet, wenn Sie ein SDK-Addon erstellen , dh die Addons, die Sie im Android SDK-Manager von Anbietern finden, z. B. Samsung, das Ihnen eine zusätzliche API für Dinge bereitstellt, die für Samsung-Telefone spezifisch sind. mkstubsFunktioniert ähnlich wie beim Generieren von DroidDoc-Stubs, verwendet jedoch keine @hideAnmerkungen, sondern eine .defsDatei, die beschreibt, welche Pakete / Klassen / Felder in Ihr SDK-Addon aufgenommen oder aus diesem ausgeschlossen werden sollen.

Dies ist jedoch für die Frage irrelevant, da der Android SDK-Build das Tool nicht verwendet mkstubs. (Unglücklicherweise.)

Wir könnten die * .jar-Dateien von der Android-Plattform rekonstruieren.

Schließen Sie zuerst ADB an Ihr Gerät an. Dann renne:

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

Sie core.jarenthalten die Standard-Java-Bibliotheken ( java.*) und framework.jardie Android-Bibliotheken ( android.*). Dies ist noch nicht verwendbar, da die tatsächlichen Dateien im DEX-Format und nicht im JAR-Format vorliegen.

Wir könnten diese DEX-formatierten * .jars mit Tools wie dex2jar in echte JARs konvertieren :

dex2jar core.jar
dex2jar framework.jar

Ziehen Sie diese Gläser dann mit "Externe JARs hinzufügen ..." ein (vorausgesetzt, Sie verwenden Eclipse ADT).

• Rechtsklick auf Project → Properties → Java Build Path → Libraries → Add External JARs... → (Wählen Sie das core-dex2jar.jarund framework-dex2jar.jarvon oben).

Auf diese Weise können Sie die internen und einige Java 7-APIs verwenden. (Die generierte APK enthält, soweit ich sehen kann, keinen tatsächlichen Code aus den JARs.)

Für Lollipop ist der Fluss etwas anders:

1. Holen Sie sich /system/framework/arm/boot.oat vom Lollipop-Gerät

2. Verwenden Sie 'java -jar oat2dex.jar boot boot.oat'

3. Sie erhalten zwei Ordner: dex und odex. Gehen Sie zu dex und machen Sie 'java -jar dex2jar.jar framework.dex'
4. Benennen Sie die resultierende Framework.jar in .zip um, extrahieren Sie sie und suchen Sie die gewünschten Klassen
5. Gehen Sie zu [sdk_path] / platform / [target_platform] und extrahieren Sie android.jar (benennen Sie es zuerst in zip um).
6. Kopieren Sie Dateien aus dem extrahierten Framework in die extrahierte Datei android.jar. Dann auf zip komprimieren und in .jar umbenennen :)

ps: wahrscheinlich musst du die Schritte 4-6 für 'framework_classes2.dex' wiederholen

DroidCon 2011

Hier erklärt Erik Hellman von Sony Ericson, wie man auf die versteckten Android-APIs zugreift:

http://vimeo.com/30180393 (Hmm-Link scheint nicht zu funktionieren).

Gehen Sie zur DroidCon-Webseite Tag 2 und scrollen Sie nach unten zu Using Hidden APIs 10:15 können Sie sie ansehen.

Links sterben!

Ich habe dieses gefunden: http://skillsmatter.com/podcast/os-mobile-server/hidden-api Keine Ahnung, wie lange es noch dauern wird

Die offiziellen APIs im Android SDK reichen normalerweise für die meisten normalen Anwendungen aus. Es gibt jedoch manchmal Situationen, in denen ein Entwickler Zugriff auf die internen Systemdienste, APIs und Ressourcen benötigt, die nicht in den offiziellen APIs veröffentlicht sind. Glücklicherweise sind diese APIs immer noch durch einige clevere Tricks verfügbar und können oft nützlich sein, wenn neue und innovative Lösungen auf Android entwickelt werden. In dieser Sitzung erfahren Sie, wie Sie auf diese versteckten und geschützten APIs zugreifen und sie verwenden, welche Einschränkungen sie verwenden und wie Sie sie auf Geräten und Android-Versionen mehrerer Anbieter sicher und kontrolliert verwenden können. Das Publikum wird mehrere erweiterte Demos sehen, die Sie normalerweise mit Android nicht machen können. Erwarten Sie eine ziemlich fortgeschrittene Sitzung mit vielen Einblicken in die Interna der Android-Plattform.

Sie können die geänderten android.jarAPIs als versteckte APIs aus diesem Repository herunterladen . Folgen Sie dort den Anweisungen.

Versuchen Sie , betrachten dies :

Das ultimative Ziel dieser Artikel ist es, Entwicklern die Leistung interner und versteckter APIs ohne Reflexion zu bieten. Wenn Sie alle in den nächsten Abschnitten beschriebenen Schritte ausführen, können Sie interne und versteckte APIs so verwenden, als wären sie öffentliche offene APIs. Es besteht kein Grund zur Reflexion.

Wenn Sie jedoch diese nicht öffentlichen APIs verwenden, sollten Sie sich bewusst sein, dass Ihre Anwendung einem hohen Risiko ausgesetzt ist. Grundsätzlich gibt es keine Garantie dafür, dass APIs beim nächsten Update auf Android OS nicht beschädigt werden. Es gibt sogar keine Garantie für ein konsistentes Verhalten zwischen Geräten verschiedener Hersteller. Sie sind ganz alleine.

Es gibt drei Szenarien, denen Sie folgen möchten:

1. Aktivieren Sie sowohl interne als auch versteckte APIs (Szenario A).
2. Nur versteckte API aktivieren (Szenario B)
3. Nur interne API aktivieren (Szenario C)

Szenario A ist eine Summe aus B und C. Szenario B ist das einfachste (erfordert keine Änderungen am Eclipse ADT-Plugin).

Szenario A : Lesen Sie die Teile 1 , 2 , 3 , 4 , 5

Szenario B : Lesen Sie die Teile 1 , 2 , 3 , 5

Szenario C : Lesen Sie die Teile 1 , 2 , 3 , 4 , 5

Ich habe einmal einige Groovy-Skripte geschrieben, um die Java-Dateien aus einem Repo-Checkout von http://source.android.com/ zu extrahieren und sie dann zu kompilieren, ohne dass eine vollständige Toolchain zum Kompilieren aller Android-Quellen erforderlich ist, einschließlich der erforderlichen anderen Schritte ( Verpackung, Erzeugung von Ressourcen usw.).

Sie finden sie hier:

https://github.com/thoutbeckers/CollectAndroid

Aber sicher muss dies für alles nach Gingerbread aktualisiert werden, hauptsächlich durch Festlegen der richtigen Verzeichnisse in "rootdirs" in der Konfigurationsdatei (CollectConfig.groovy).

Zu der Zeit habe ich dies regelmäßig für die Entwicklung verwendet, wobei alle versteckten APIs und Quellen (die zu dieser Zeit ebenfalls problematisch waren) verfügbar waren.

Wie an anderer Stelle erwähnt, wird com / android / internal / ** in neueren Versionen von ADT aufgrund der hinzugefügten Zugriffsregel weiterhin ausgeblendet.

Longs Antwort funktionierte für mich, aber mir fehlten noch einige Klassen, die ich brauchte, insbesondere android.provider.Telephony. Ich konnte es so hinzufügen:

1. Extrahieren Sie die Datei framework.jar

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

2. Erstellen Sie das Android-Repo, das das Verzeichnis out / target / common / obj / JAVA_LIBRARIES erstellt

3. Finden Sie heraus, wo die fehlenden Klassen sind

   $ 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. Fügen Sie die neuen Klassen hinzu und erstellen Sie die Framework-JAR-Datei neu

   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 .

Oder Sie können einfach faul sein und alle Klassen in eine riesige JAR-Datei aufnehmen:

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

Ich kann keinen Kommentar abgeben, aber dies ist im Grunde ein Kommentar zu @ KennyTMs ( https://stackoverflow.com/a/13550030/2923406 ) ausgezeichneter Antwort:

Wenn Sie den folgenden Fehler in Eclipse haben:

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

(das heißt, android.internal. * ist nicht verfügbar)

Eine mögliche Lösung besteht darin, dieselbe Methode für /system/framework/framework2.jar anzuwenden. Mit dem Android Emulator für SDK19 habe ich dieses zusätzliche Glas. Auf meinem HTC One gibt es sogar ein framework3.jar.