Jak zbudować Android SDK z dostępnymi ukrytymi i wewnętrznymi interfejsami API?

Chcę przebudować Android SDK (a raczej tylko android.jar), aby zawierał ukryte i wewnętrzne interfejsy API.

Nie mogłem znaleźć żadnej dokumentacji ani dyskusji, jak się do tego zabrać. Mam już skonfigurowane środowisko kompilacji Ubuntu CyanogenMod, które jest w stanie zbudować cm7.

Teraz czytałem, że make SDK zbuduje SDK, ale chcę zbudować SDK, który zawiera metody i pola, które są oznaczone jako ukryte za pomocą @hide. czy to możliwe?

To, co chcę zrobić, to wprowadzić zmiany w aplikacji, która korzysta z ukrytego API i aby ją przebudować, chciałbym użyć zmodyfikowanego SDK.

To jest to, co zawsze robię, aby używać ukrytego interfejsu API.

1. Zbuduj repozytorium lub pobierz słoiki z https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
2. skopiuj out / target / common / obj / JAVA_LIBRARIES / framework_intermediates / classes.jar (lepiej zmienić nazwę na coś takiego jak framework_all.jar)
3. Skonfiguruj ścieżkę kompilacji projektu -> biblioteki -> dodaj te zewnętrzne pliki JAR. W sekcji Order and Export przenieś ją w górę, a przed android.jar

Zbadałem to trochę i mój wniosek jest prosty: nie da się tego zrobić bez dużej ilości pracy. Przeczytaj resztę tej odpowiedzi, aby uzyskać szczegółowe informacje na temat tego, co znalazłem.

android.jarw rzeczywistości składa się z „publicznego interfejsu API” programu framework.jari core.jarznajduje się w system/frameworks/urządzeniu. android.jarjest rodzajem tego, co nazwałbym nagłówkiem biblioteki Java, wszystkie implementacje w rzeczywistym kodzie bajtowym są po prostu a throw new RuntimeException("stub");, to pozwala na kompilację android.jar(np. w Eclipse), ale wykonanie musi być wykonane na urządzeniu lub emulatorze.

Publiczny interfejs API zestawu Android SDK jest definiowany przez klasy / metody / pola, które nie są poprzedzone @{hide}adnotacją javadoc. To znaczy wszystko, co nie jest opisane, jest zawarte w SDK.

android.jarjest zbudowany ze źródeł, w out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediatesktórych sam jest generowany przez narzędzie DroidDoc znajdujące się w build/tools/droiddoc.

DroidDoc to narzędzie (prawdopodobnie zaadaptowane z javadoc lub używające javadoc), które generuje rzeczywistą dokumentację Android SDK. Jako efekt uboczny i prawdopodobnie dlatego, że już analizuje cały javadoc, wypluwa również kody pośredniczące Androida, które są następnie kompilowane do tego, android.jarktóry jest dystrybuowany w SDK.

Aby uwzględnić ukryte elementy, możesz, jeśli chcesz uwzględnić tylko określone części, po prostu usuń @hideadnotację i przebuduj SDK.

Jeśli jednak chcesz uwzględnić wszystkie ukryte części, sprawy stają się znacznie bardziej skomplikowane. Możesz zmodyfikować DroidDoc (odpowiednie źródło jest w build/tools/droiddoc/src/Stubs.java) tak, aby nic nie było wykrywane jako ukryte. Jest to dość trywialne i próbowałem tego, jednak generowane wówczas kody pośredniczące w ogóle się nie kompilują.

Mój wniosek jest teraz taki, że jest to po prostu niewykonalne. Stopy wygenerowane po usunięciu części DroidDoc, która wykrywa ukryte adnotacje, są po prostu niekompilowalne i wymagałyby sporo pracy, aby je poprawnie skompilować.

Tak więc moja odpowiedź na Twoje pytania brzmi: Nie, nie da się tego zrobić bez dużego nakładu pracy. Przepraszam.

Dodatkowa uwaga na temat mkstubsnarzędzia. mkstubssą używane podczas budowania dodatku SDK , czyli dodatków, które można znaleźć w menedżerze Android SDK od dostawców, np. Samsunga udostępniającego dodatkowe API dla rzeczy specyficznych dla telefonów Samsung. mkstubsrobi to samo, co proces generowania kodów pośredniczących w DroidDoc, jednak nie używa @hideadnotacji, używa .defspliku opisującego, które pakiety / klasy / pola należy uwzględnić lub wykluczyć z dodatku SDK.

Jednak to wszystko nie ma znaczenia dla pytania, ponieważ kompilacja Android SDK nie korzysta z tego mkstubsnarzędzia. (Niestety.)

Mogliśmy zrekonstruować pliki * .jar z platformy Android.

Najpierw podłącz ADB do swojego urządzenia. Następnie uruchomić:

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

core.jarZawierać standardowe biblioteki Java ( java.*) i framework.jarzawierają biblioteki Androida (android.* ). Nie można tego jeszcze używać, ponieważ rzeczywiste pliki są w formacie DEX, a nie w formacie JAR.

Moglibyśmy przekonwertować te * .jary w formacie DEX na prawdziwe pliki JAR przy użyciu narzędzi takich jak dex2jar :

dex2jar core.jar
dex2jar framework.jar

Następnie ściągnij te słoiki za pomocą „Dodaj zewnętrzne pliki JAR ...” (zakładając, że używasz Eclipse ADT)

• kliknij prawym przyciskiem myszy Project → Properties → Java Build Path → Libraries → Add External JARs... → (Wybierz core-dex2jar.jariz framework-dex2jar.jargóry).

Umożliwi to korzystanie z wewnętrznego i niektórych interfejsów API Java 7. (Wygenerowany plik APK, o ile widzę, nie zawiera żadnego rzeczywistego kodu z plików JAR).

W przypadku Lollipopa przepływ jest nieco inny:

1. Pobierz /system/framework/arm/boot.oat z urządzenia Lollipop

2. Użyj 'java -jar oat2dex.jar boot boot.oat”

3. Otrzymasz dwa foldery: dex i odex. Przejdź do dex i utwórz 'java -jar dex2jar.jar framework.dex”
4. Zmień nazwę wynikowego pliku framework.jar na .zip, wyodrębnij i znajdź potrzebne klasy
5. Przejdź do [sdk_path] / platform / [target_platform] i wyodrębnij plik android.jar (najpierw zmień jego nazwę na zip).
6. Skopiuj pliki z wyodrębnionej platformy do wyodrębnionego pliku android.jar. Następnie skompresuj do zip i zmień nazwę na .jar :)

ps: prawdopodobnie musisz powtórzyć kroki 4-6 dla 'framework_classes2.dex'

Możesz pobrać zmodyfikowane android.jardo użycia jako ukryte API z tego repozytorium . Postępuj zgodnie z instrukcjami.

DroidCon 2011

Tutaj Erik Hellman z Sony Ericson wyjaśnia, jak uzyskać dostęp do ukrytych interfejsów API systemu Android:

http://vimeo.com/30180393 (Hmm link nie wydaje się działać).

Przejdź do strony internetowej DroidCon Dzień 2 przewiń w dół do sekcji Używanie ukrytych interfejsów API 10:15 i możesz ją tam obejrzeć.

Linki umierają!

Znalazłem ten: http://skillsmatter.com/podcast/os-mobile-server/hidden-api nie wiem, jak długo to będzie działać

Oficjalne interfejsy API w Android SDK są zwykle wystarczające dla większości zwykłych aplikacji. Czasami jednak zdarzają się sytuacje, w których programista potrzebuje dostępu do wewnętrznych usług systemowych, interfejsów API i zasobów, które nie są publikowane w oficjalnych interfejsach API. Na szczęście te interfejsy API są nadal dostępne dzięki sprytnym sztuczkom i często mogą być przydatne podczas opracowywania nowego i innowacyjnego rozwiązania na Androidzie. Podczas tej sesji dowiesz się, jak uzyskać dostęp do tych ukrytych i chronionych interfejsów API i jak z nich korzystać, a także dowiedzieć się, jakie są ograniczenia ich użytkowania, a także kilka wskazówek i sztuczek, jak z nich korzystać w bezpieczny i kontrolowany sposób na urządzeniach wielu dostawców i wersjach Androida. Widzowie zobaczą kilka zaawansowanych wersji demonstracyjnych, których normalnie nie można zrobić z systemem Android. Spodziewaj się dość zaawansowanej sesji z wieloma wglądami w wewnętrzne elementy platformy Android.

Spójrz na to :

Ostatecznym celem tych artykułów jest zapewnienie programistom możliwości wewnętrznych i ukrytych interfejsów API bez używania refleksji. Jeśli wykonasz wszystkie kroki opisane w kilku następnych częściach, będziesz mógł używać wewnętrznych i ukrytych interfejsów API, tak jakby były publicznymi otwartymi interfejsami API. Nie będzie potrzeby refleksji.

Ale jeśli używasz tych niepublicznych interfejsów API, powinieneś mieć świadomość, że Twoja aplikacja jest narażona na duże ryzyko. Zasadniczo nie ma gwarancji, że interfejsy API nie zostaną zerwane przy następnej aktualizacji systemu operacyjnego Android. Nie ma nawet gwarancji spójnego działania urządzeń różnych dostawców. Jesteś całkowicie sam.

Istnieją trzy scenariusze, które warto zastosować:

1. Włącz zarówno wewnętrzne, jak i ukryte interfejsy API (scenariusz A)
2. Włącz tylko ukryte API (scenariusz B)
3. Włącz tylko wewnętrzny interfejs API (scenariusz C)

Scenariusz A jest sumą B i C. Scenariusz B jest najłatwiejszy (nie wymaga modyfikacji wtyczki eclipse ADT).

Scenariusz A : przeczytaj części 1 , 2 , 3 , 4 , 5

Scenariusz B : przeczytaj części 1 , 2 , 3 , 5

Scenariusz C : przeczytaj części 1 , 2 , 3 , 4 , 5

Kiedyś napisałem kilka skryptów Groovy do wyodrębniania plików java z kasy repozytorium ze strony http://source.android.com/ a następnie kompilowania ich bez konieczności posiadania pełnego zestawu narzędzi do kompilacji wszystkich źródeł Androida, w tym potrzebnych innych kroków ( pakowanie, generowanie zasobów itp.).

Można je znaleźć tutaj:

https://github.com/thoutbeckers/CollectAndroid

Ale na pewno będzie to wymagało aktualizacji dla czegokolwiek po Gingerbread, głównie poprzez ustawienie właściwych katalogów w "rootdirs" w pliku konfiguracyjnym (CollectConfig.groovy).

W tamtym czasie regularnie używałem tego do programowania z wszystkimi dostępnymi ukrytymi API i źródłami (również problematycznymi w tym czasie).

Jak wspomniano w innym miejscu, com / android / internal / ** nadal będzie ukryty w ostatnich wersjach ADT z powodu zastosowanej reguły dostępu.

Odpowiedź Longa działała dla mnie, ale nadal brakowało mi niektórych zajęć, których potrzebowałem, w szczególności android.provider.Telephony. Udało mi się to dodać tak:

1. Wyodrębnij plik framework.jar

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

2. Zbuduj repozytorium Androida, które utworzy katalog out / target / common / obj / JAVA_LIBRARIES

3. Dowiedz się, gdzie są brakujące klasy

   $ 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. Dodaj nowe klasy i odbuduj plik JAR struktury

   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 .
   

Lub możesz po prostu być leniwy i dołączyć wszystkie klasy do jednego gigantycznego pliku jar:

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

Nie mogę komentować, ale jest to w zasadzie komentarz do @ KennyTM's ( https://stackoverflow.com/a/13550030/2923406 doskonałej odpowiedzi ):

Jeśli napotkasz następujący błąd w Eclipse:

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

(to znaczy, android.internal. * nie jest dostępny)

Wtedy jednym możliwym rozwiązaniem jest zastosowanie tej samej metody dla /system/framework/framework2.jar. Używając emulatora Androida dla SDK19 mam ten dodatkowy słoik. Na moim HTC One jest nawet plik framework3.jar.