Tutorial Translacja (tłumaczenia) aplikacji Androida

[Wall-E]

[chapter]Wstęp[/chapter]
Umówmy się, że to już jest taka nowa świecka tradycja w moim wykonaniu. Pisałem już jak się tłumaczy programy dla Windows Mobile, więc i w przypadku Androida nie pozwolę sobie na odpuszczenie tego tematu.

Na samym wstępie zalecam przestudiowanie całej treści niejako "na sucho" - by zaznajomić się z warunkami i wymaganiami zadania, którego się podjęliśmy. W razie wątpliwości co do konkretnych aspektów proszę o kontakt - czy to w wątku czy to przez PW.

Zacznijmy od tego, że w przeciwieństwie do programów dla WM, aplikacje androidowe wymagają od tłumacza dużo więcej poświęcenia - przynajmniej na pierwszym etapie pracy. Tu nie wystarczy mieć jeden program do edycji zasobów...

Druga bardzo ważna uwaga:
Opis dotyczy TYLKO ZWYKŁYCH APLIKACJI - tzw. zewnętrznych. W przypadku APLIKACJI SYSTEMOWYCH zachodzą jeszcze inne zależności wymagające dodatkowych metod i sposobów - tym NIE BĘDZIEMY się tutaj zajmować.

No, ale do rzeczy.

[chapter]Co musimy mieć...[/chapter]
1. JAVA

Jak pewnie wiele osób przynajmniej kojarzy, Java jest obiektowym językiem programowania na którym opiera się cały Android. Nie ma tu sensu wnikać co i jak - to nie jest potrzebne. Wystarczy tylko wiedzieć, że Java jest nam niezbędna i tyla.

Jak się domyślam, Java jest obecna na waszych PC-tach - choćby z powodu przeglądania stron internetowych. Domyślam się również, że jest to środowisko JRE (Java Runtime Environment) - czyli wersja najprostsza, pozwalająca jedynie na "odtwarzanie" javowych elementów.
Ja sugeruję użycie do naszych celów wersji bardziej zaawansowanej, pozwalającej również na tworzenie obiektów, czyli wersji JDK (Java Development Kit).

JDK 6

Dla Windows x86

Kod:

http://download.oracle.com/otn-pub/java/jdk/6u34-b04/jdk-6u34-windows-i586.exe

Dla Windows x64

Kod:

http://download.oracle.com/otn-pub/java/jdk/6u34-b04/jdk-6u34-windows-x64.exe

Globalna strona pobierania JDK

Kod:

http://www.oracle.com/technetwork/java/javase/downloads/jdk6-downloads-1637591.html

JDK 7

Dla Windows x86

Kod:

http://download.oracle.com/otn-pub/java/jdk/7/jdk-7-windows-i586.exe

Dla Windows x64

Kod:

http://download.oracle.com/otn-pub/java/jdk/7/jdk-7-windows-x64.exe

Globalna strona pobierania JDK

Kod:

http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html

O ile Windows XP pozwala nam na bezstresowe używanie środowiska Java zawsze i wszędzie, o tyle Windows Vista/7 (x86/64) już może nam przysporzyć nieco siwych włosów.
Aby zachować swój naturalny kolor owłosienia, po instalacji Javy należy wykonać następujące kroki (dotyczy systemów Windows Vista/7 x86/64):

1. Otwieramy Menu Start i za pomocą prawokliku na Komputer wywołujemy menu tegoż elementu,
   
2. Wybieramy i klikamy pozycję Właściwości
   
3. W oknie, które nam się pojawi, szukamy pozycji Zaawansowane ustawienia systemu - po lewej stronie, ostatnia pozycja,
   
4. W kolejnym oknie (Właściwości systemu) namierzamy przycisk Zmienne środowiskowe... - jest na dole - i klikamy go,
   
5. Teraz przechodzimy do bloku Zmienne systemowe i za pomocą suwaka szukamy w oknie wyrażenia Path (kolumna: "Zmienna"),
   
6. Teraz można użyć dwóch sposobów:
   
   1. Kliknij i podświetl w oknie zmienną Path po czym użyj przycisku Edytuj...
      
   2. Dwukrotnie kliknij na zmienną Path
      Oba sposoby doprowadzą nas do tego co potrzebujemy, czyli do okna edycji wartości zmiennej Path ("Edytowanie zmiennej systemowej")
7. W polu Wartość zmiennej: przechodzimy do samego końca łańcucha znaków i umieszczamy tam w kolejności:
   
   1. znak średnika " ; ",
      
   2. ścieżkę dostępu do folderu zawierającego plik java.exe
      Jeśli podczas instalacji Javy nie mieszałeś w parametrach instalacyjnych to owa ścieżka powinna wyglądać mniej-więcej tak:
      
      
      Kod:

      C:\Program Files\Java\jdk1.7.0_01\bin\
      
      Proszę pamiętać, że powyższa ścieżka jest tylko zasadą a jej dokładny wygląd zależy od zainstalowanej wersji Javy - każdy musi ją sobie osobiście sprawdzić.
8. Całość zapisujemy i restartujemy PC-ta

UWAGA (taka wskazówka na zaś)
W przypadku problemów z detekcją Javy przez program de/kompilujący pliki apk w systemach x64 (bardzo częste zjawisko), sugeruję dodatkowe zainstalowanie środowiska Java w wersji x86.


2. SDK Androida

SDK systemu Android (Software Development Kit) to, moim zdaniem, dosyć ważny warunek wykonywania jakichkolwiek operacji na jakichkolwiek plikach Androida.

Istnieją dosyć poważne argumenty, że SDK niekoniecznie jest potrzebne do naszych celów... Być może i niewykluczone. Jednak ja wolę się oprzeć na swoich doświadczeniach.
Jeśli chcesz spróbować bez SDK to nic nie stoi na przeszkodzie.

Tak czy owak opiszę i ten punkt.

SDK Androida pobieramy z poniższego linku:

Kod:

http://developer.android.com/sdk/index.html

Pobrany program instalujemy na PC-cie.
W tym miejscu sugeruję zainstalowanie SDK bezpośrednio na C:\ - nie w Program Files czy gdzie tam... a właśnie bezpośrednio na C:\ (C:\android-sdk\)
Z własnych doświadczeń wynika mi, że SDK zdecydowanie nie lubi być plasowane przesadnie głęboko w drzewie folderów. Ma to szczególne znaczenie w przypadku systemów 64-bitowych gdzie ścieżka typu C:\Program Files (x86)\android-sdk\ (SDK to program 32-bitowy) w wielu przypadkach jest mało strawna dla naszych narzędzi.
OK. SDK jest zainstalowane. Jednak to jeszcze nie wszystko. Teraz mamy tylko "bazę", która sama w sobie jest mało przydatna. Aby spełniała ona swoje zadanie należy ją zaktualizować - chodzi tu o aktualizację jej elementów.
Tu nie będę się rozdrabniał które elementy należy zaktualizować, to temat na osobną książkę - polecimy globalnie.
Tak więc, przechodzimy do folderu instalacyjnego SDK, uruchamiamy plik SDK Manager.exe i z dostępnej listy wybieramy wszystko co ma opis "Not installed" lub "Update available: ...".
Klikamy przycisk Instal X packages... i cierpliwie czekamy na pobranie i instalację komponentów - cała operacja może potrwać nawet kilka godzin w zależności od przepustowości naszego łącza.
Część wybranych komponentów nie zostanie pobrana i zainstalowana, ale tym nie trzeba się przejmować - to co nam potrzebne zostanie zainstalowane.

UWAGA:
W przypadku systemów Windows Vista/7, po instalacji i aktualizacji SDK sugeruję postąpić z nim tak jak ze środowiskiem Java, czyli dopisać ścieżkę SDK do zmiennych systemowych.
Np:

Kod:

C:\android-sdk\platform-tools\

Pamiętać należy oczywiście by dopisując ową ścieżkę do zmiennych systemowych poprzedzić ją znakiem średnika (" ; ").


3. APK Tool

Kolejnym narzędziem w które musimy się zaopatrzyć to de/kompilator plików APK.
W sieci można znaleźć multum tego typu gadżetów: APK Tool, APK MultiTool... To podstawowe hasła do wyszukania narzędzia w Internecie - a na XDA w szczególności.
Ja osobiście korzystam z narzędzia poleconego mi przez - jak zawsze nieocenionego w tym temacie - Toldo:

Kod:

http://www.mediafire.com/?il54020r00uiffr

Zawartość archiwum - czyli folder istniejący w archiwum - należy wypakować as-is (tak jak jest) do lokalizacji C:\

No !! Teraz mamy wszystko co nam jest potrzebne.

Wiem i mam świadomość, że sam proces przygotowania jest nieco skomplikowany, ale to już poniekąd od Nas nie zależy. Wszystkie powyższe komponenty w systemie mieć trzeba - co więcej, ca mieszać nimi do chwili aż całość wespół w zespół zadziała.

[chapter]Dekompilacja pliku apk...[/chapter]
Pozwólcie, że skupię się na narzędziu, którego sam używam.
Jak pisałem wcześniej, podobnych narzędzi jest milion i jeden - nie dam rady ogarnąć ich wszystkich. To, moje, narzędzie działa i jemu poświęcę ów opis.

Tak więc...

Narzędzie, które pobierzesz z podanego przeze mnie linku służy do wielu innych bardziej zaawansowanych operacji na plikach apk niż tylko translacja UI aplikacji. Aby zapoznać się ze wszystkimi możliwościami narzędzia przeczytaj jego dokumentację - ja nie mam zamiaru - tu i teraz - dokonywać wiwisekcji owego narzędzia. Temat dotyczy translacji interfejsu aplikacji i na tym się skupię - nic więcej i nic mniej.

Zawartość folderu, który wypakowałeś z linkowanego wcześniej archiwum wygląda tak:

docs\
other\
place-apk-here-for-modding\
place-apk-here-for-signing\
place-apk-here-to-batch-optimize\
place-ogg-here\
projects\
themer\
adblog.txt
APK-Multi-Tool.log
APK Multi-Tool Uninstaller.exe
README
Script.bat
Setup.bat
setuplog.log

Nie przestraszaj się tym wyglądem. W brew pozorom, dla naszych celów, wszystko jest proste jak zęby od brony. I tak właśnie cały temat potraktujemy - bez zbędnych opisów i technicznego bełkotu.

1. Aplikację - plik apk - który chcesz edytować kopiujesz do folderu:
   ...\place-apk-here-for-modding\
   Jeśli mogę zasugerować... nazwę pliku najlepiej jest skrócić do minimum pozbywając się spacji, kropek i innych dziwnych znaków.
   Tyle i nic więcej.
   
2. Uruchamiasz kliknięciem plik Script.bat z folderu roboczego narzędzia - czekasz na pojawienie się shell-owego (dosowego) okna z mnóstwem "krzaczków".
   Klikasz w którykolwiek guziol (any key ) na klawiaturze i dostajesz to co potrzebujesz - okno z opisanymi opcjami do użycia.
   
3. By zdekompilować plik apk wbijasz w linię "Please make your decision:" wartość 9 (Decompile apk) [enter] - czekasz aż zniknie z linii poleceń wartość "test"...
   Jeśli wiersz poleceń jest "czysty" - to możesz przejść do dalszej "obróbki" pliku.
   Jeśli pojawiły się komunikaty błędów... należy je przeczytać, zrozumieć i naprawić - tu nie ma jednej standardowej instrukcji. Niestety.

Jeśli plik został zdekompilowany poprawnie, to efekt tego znajdziesz w folderze:

.../projects

w podfolderze o nazwie zgodnej z dekompilowanym plikiem.

Dla przykładu, ja zdekompilowałem plik GOBackup13.apk - tak więc otrzymam podfolder: GOBackup13.apk w lokalizacji .../projects - i tutaj skupiam swoją uwagę.

UWAGA
Dosowe okno z opcjami zostawiamy aktywne - nie zamykamy go a jedynie MINIMALIZUJEMY.

[chapter]Translacja UI programu... Wreszcie !![/chapter]
Mając już zdekompilowany plik apk widzimy taką oto strukturę (najczęściej):

assets\
res\
smali\
AndroidManifest.xml
apktool.yml

Interesuje nas tylko to, co jest w folderze res.
Przykładowa struktura tego folderu poniżej (na postawie dekompilacji aplikacji GO Backup):

color\
drawable\
drawable-en-hdpi\
drawable-hdpi\
drawable-ldpi\
drawable-mdpi\
layout\
layout-v11\
menu\
raw\
values\
values-hdpi\
values-mdpi\
values-v11\
xml\

Zasoby językowe znajdziemy w folderze values - folder zawiera oryginalne, najczęściej angielskie zasoby językowe aplikacji.
Standardowa zawartość folderu poniżej:

arrays.xml
attrs.xml
colors.xml
dimens.xml
drawables.xml
ids.xml
public.xml
strings.xml
styles.xml

Teraz tak...
Cały folder values kopiujemy gdzie bądź. Zmieniamy jego nazwę na values-pl (*-pl to oznaczenie języka którym będzie się posługiwała aplikacja na podstawie ustawień regionalnych systemu) i z powrotem przenosimy do folderu zdekopilowanej aplikacji:

color\
drawable\
drawable-en-hdpi\
drawable-hdpi\
drawable-ldpi\
drawable-mdpi\
layout\
layout-v11\
menu\
raw\
values\
values-hdpi\
values-mdpi\
values-pl\
values-v11\
xml\

Z folderu values-pl usuwamy wszystko za wyjątkiem dwóch plików:
arrays.xml
strings.xml

Plik: arrays.xml - zawiera najczęściej wartości wszystkich list wyboru występujących w programie.
Plik: strings.xml - zawiera najczęściej wszystkie ciągi znakowe opisujące kontrolki, opcje i funkcje programu - czyli to, co użytkownik widzi a co można przetłumaczyć.

Używam określenia "najczęściej" bo nie zawsze owe pliki zawierają materiał dający się ucywilizować (spolszczyć) - ale o tym za chwilę.

Sama procedura spolszczania jest prosta.
Otwieramy plik xml i tłumaczymy wszystkie ciągi znaków pomiędzy znacznikami " > " i " < " - pokolorowany przykład fragmentu zawartości pliku strings.xml poniżej:

...
<string name="go_account_ok">Allow</string>
<string name="go_account_server_error">Connection timed out, please try again</string>
<string name="go_account_json_parse_error">Your session has expired, please sign in again</string>
<string name="go_account_another_error">Unknown error occurred, please try again later.</string>
<string name="go_account_password_error">Invalid username or password</string>
<string name="go_account_existed_error">Account has already exist</string>
<string name="go_account_accountMail_notSet_error">Email needed for GO account</string>
...

Ufam, że zasada została ogarnięta. Owa zasada dotyczy obu plików.

Jedak w przedstawionej powyżej zasadzie istnieją również wyjątki.
Tymi wyjątkami są stringi wartości systemowych reprezentowanych w poniższej formie:

...
<string name="key_delete_backuped_records">delete_backuped_records</string>
<string name="key_delete_cloud_backup">delete_cloud_backup</string>
<string name="key_only_backup_contacts_which_has_number">only_backup_contacts_which_has_number</string>
<string name="key_merge_duplicate_contacts">merge_duplicate_contacts</string>
<string name="key_contact_change_push">contact_change_push</string>
<string name="key_root_introduction">root_introduction</string>
<string name="key_backup_restore_app_data">backup_restore_app_data</string>
<string name="key_silently_install_app">silently_install_app</string>
...

Widać różnicę?
Dla mniej kumatych podpowiem, że różnicą jest znak podkreślenia (" _ ") występujący w strategicznej nazwie stringu. Te wartości zastępowane są w programie obiektami pobieranymi z innych miejsc w programie.
Wartości zaopatrzone w ten symbol można spokojnie usunąć zmniejszając tym samym rozmiary pliku i jednocześnie wprowadzając klarowność do jego zawartości. Można je również pozostawić - do wyboru, jak kto woli - jednak ogólnie przyjęta zasada tłumaczeń sugeruje usunięcie takich wartości.

Po przetłumaczeniu wszystkich ważnych ciągów pozostaje tylko zapisanie pliku/ów xml i ponowne skompilowanie pliku apk.

[chapter]Kompilacja zmodyfikowanego pliku apk...[/chapter]
W tym celu przywracamy wcześniej zminimalizowane okno de/kompilatora i...

1. Wklepujemy w linię poleceń: 11 (Compile apk) [enter] po czym czekamy aż plik apk zostanie przetworzony (Building apk),
   
2. Na pytanie "It this a system apk (y/n)" wklepujemy "n" (nie) [enter] - bo to nie jest apka systemowa. W przypadku aplikacji systemowych, procedura jest nieco bardziej skomplikowana i dlatego nie będziemy się tym tutaj zajmować,
   
3. W odpowiedzi na następne "długie" pytanie, wklepujemy "y" (tak) [enter],
   
4. Po czym, zgodnie z poleceniem, wdusiamy dowolny klawisz.

Tym sposobem uzyskujemy zmodyfikowaną wersję pliku apk dostępną w folderze źródłowym, czyli w .../place-apk-here-for-modding - zmodyfikowaną, ale NIEPODPISANĄ.

Teraz należy wbić w oknie programu wartość: 12 (Sign apk) [enter] - czyli elektronicznie podpisać plik apk. Bez tego system już na początku instalacji odrzuci nasz nowy plik.
Dopiero teraz uzyskujemy to, co chcemy mieć a co jest użyteczne w systemie - czyli zmodyfikowany językowo i podpisany cyfrowo plik apk.

Efekt naszej pracy wydobędziemy z folderu .../place-apk-here-for-modding.
Nazwa pliku finalnego będzie się zaczynała od znaków: "signed ..." po których nastąpi nazwa aplikacji modyfikowanej.
Jeśli plik tłumaczony posiadał nazwę oryginalną np: "GOBackup13.apk" to plik finalny będzie miał nazwę "signedGOBackup13.apk".

W sumie to by było na tyle odnośnie standardowej procedury...

Aha... to jeszcze nie wszystko...
Jak słusznie przypomniał mi Phenom, na proces kompilacji pliku i na jego późniejsze działanie wpływa również stopień jego kompresji.
W tym przypadku zasada jest prosta i znana - mocniejsze upakowanie pliku zmniejsza jego ogólną objętość, ale jednocześnie powoduje większe zajęcie pamięci RAM podczas jego działania. Zbyt duży stopień kompresji może spowodować również najzwyklejsze niedziałanie aplikacji.
Ponoć domyślnym stopniem kompresji pliku apk jest poziom 6, używany przeze mnie APK Multitool domyślnie kompresuje na poziomie 9...
Szczerze powiem, że najzwyczajniej zapomniałem o tym elemencie kompilacji pliku... Ale przetworzone apki działały, więc nie miałem powodu o tym pamiętać...

[chapter]Wyjątki od reguły...[/chapter]
To, co zostało opisane powyżej stanowi niejako standard.
Nie mniej trafiają się przypadki, gdzie autor aplikacji nie przewidział translacji na inne - niż założone przez niego - języki.
Nie przewidział, nie umiał tego zrobić, miał to we du*pie... Bez znaczenia - to jego sprawa.
Powyższy "tumiwisizm" autora apki objawia się tym, że zawartość plików:
- arrays.xml
- strings.xml
jest bardzo skromna - ogranicza się do jednego... może dwóch nic nie mówiących wartości tekstowych albo w inny sposób nie zawiera wartości dających się przetłumaczyć.
W takim przypadku tworzenie translacji metodą opisaną powyżej mija się z celem bo pomimo naszego poświęcenia nic z tego nie wyjdzie.

W tym miejscu możemy mieć do czynienia z dwoma przypadkami "zaszycia" wartości tekstowych:

Przypadek 1 - Stringi językowe są rozrzucone po innych plikach xml w aplikacji.

Ten przypadek wymaga by przetrzepać wszystkie pliki xml - w każdym folderze - pod kątem występowania wartości android:title: lub android:text:.
Jeśli ciągi tekstowe w powyższych wartościach ewidentnie stanowią "język zrozumiały", oznacza to, że możemy je spokojnie tłumaczyć.

Przykłady ciągów na jakie możemy się natknąć:

- Ciąg, którego nie tłumaczymy - zawiera zmienną a nie interesujący nas tekst
android:title="@string/export_contacts"

- Ciąg, który tłumaczymy:
android:title="Export Contacts"

Czy różnica pomiędzy nimi jest widoczna?

Owa metoda da ten sam efekt co opisana wyżej, jednak translacja programu będzie w tym przypadku dokonana "na tardo" - tylko dla języka wpisanego w stringi tekstowe plików.

Jednak w tym miejscu możemy się natknąć również na:

Przypadek 2 - Brak sensownych wartości tekstowych w jakimkolwiek pliku xml aplikacji.

Stwierdziwszy taki fakt, najzwyczajniej odstępujemy od próby przetłumaczenia UI aplikacji. Autor apki zaszył wszystko co się dało w innych plikach programu. Tutaj nie obędzie się już bez innych narzędzi, metod i sposobów - ale to historia na inną książkę.

[chapter]Uwagi dodatkowe[/chapter]
Nie gwarantuję, że powyższy przepis zadziała zawsze i u każdego.
Mnie, zgranie wszystkich elementów kosztowało sporo nerwów i siwych włosów na łepetynie... Nie miej mam nadzieję, że zasadę przedstawiłem jasno i klarownie dla każdego usera.




Podziękowania:

@KATwawa - za podstawy
@Toldo - za narzędzie, celne uwagi i cierpliwość
@XTeK - za kilka pożytecznych rozmów i cierpliwość
@Phenom - za sporo uwag natury technicznej

[Phenom]

Niby wszystko OK, ale opis zawiera trochę niedociągnięć :

Po pierwsze i najważniejsze podczas kompilowania apki systemowej trzeba udać się do folderu keep (przed ostatnim wduszeniem klawisza na odpowiedź "In the apk manager folder" ) i usunąć plik resources.arsc w przypadku edycji Valuesów lub classes.dex w przypadku edycji plików smali. Jeżeli tego nie zrobimy, w/w pliki zostaną zastąpione wersją oryginalną (modyfikacje szlak trafi)

Po drugie. Część urządzeń takich jak SGS czy Xperię muszą mieć oryginalne pliki manifestu, nowe wygenerowane przez apktool będą powodować FC re-kompilowanej aplikacji. Najprościej po skompilowaniu i podpisaniu naszej nowej zmodyfikowanej apki, kopiujemy z niej same pliki resources.arsc lub classes.dex do starej oryginalnej apki zastępując już tam istniejącą. Dzięki temu zachowamy oryginalne manifesty ze zmiennymi values,smali.

Po 3. Poziom kompresji kompilacji może wpływać na działanie lub nie działanie nowej apki, trzeba niestety testować na żywca.

Po 4. Android SDK nie jest do niczego potrzebny

Po 5. To już mało istotne dla większości ale podzielę się info, jeżeli postąpimy jak w pkt. 2 czyli ze starym manifestem będzie możliwy odex danej aplikacji, ale re-deodex już nie, wywali nam się niespójność manifestu/smali/valuses (nieznane adresowe)

[Wall-E]

@Phenom,

Wiem, że jesteś większym specjalistą ode mnie jeśli chodzi o dłubanie w plikach. Tego nie podważam.

Jednak bądź łaskawy przeczytać mój tekst dokładnie i ze zrozumieniem - gdzie ja tam piszę o apkach systemowych? To po pierwsze.

Po drugie...
Jaki folder "keep" i jakie usuwanie resources.arsc... Jak dotąd nic takiego nie robiłem w moim narzędziu i jak widać po wstawianych przeze mnie linkach - wszystko działa.

Po trzecie...
Jaka kompresja? O czym ty do mnie rozmawiasz?

Po czwarte...
Bez zainstalowania SDK i jego aktualizacji nie byłem w stanie zrobić NIC (słownie: N-I-C).

Po piąte i najważniejsze...
To co opisałem to MOJA PRAKTYKA - nie teoria, nie dywagacje a praktyka stosowana.

[malymon]

Obaj macie rację. Wszystko zależy od pliku wejściowego. Przynajmniej tak wynika z mojej skromnej praktyki

[Wall-E]

No dobra... Wszystko zależy od tego jak się leży.

Ja piszę ino tylko o translacji UI programu - ergo o edycji dwóch plików xml... No kurna... W czym ten cholerny problem?

[malymon]

Problem nie istnieje, jak łyżka w Matrixie Pisz dalej, od czegoś trzeba zacząć

[Phenom]

Po pierwsze i najważniejsze podczas kompilowania apki systemowej trzeba udać się do folderu keep (przed ostatnim wduszeniem klawisza na odpowiedź "In the apk manager folder" ) i usunąć plik resources.arsc w przypadku edycji Valuesów lub classes.dex w przypadku edycji plików smali. Jeżeli tego nie zrobimy, w/w pliki zostaną zastąpione wersją oryginalną (modyfikacje szlak trafi)

Opis ten tyczy się wyłącznie aplikacji systemowych, czyli przy kompilacji na pierwsze pytanie odpowiadamy "Y". Gdy tłumaczymy aplikację system/app (systemowe, ustawieniowe,launcher itp)

Po drugie. Część urządzeń takich jak SGS czy Xperię muszą mieć oryginalne pliki manifestu, nowe wygenerowane przez apktool będą powodować FC re-kompilowanej aplikacji. Najprościej po skompilowaniu i podpisaniu naszej nowej zmodyfikowanej apki, kopiujemy z niej same pliki resources.arsc lub classes.dex do starej oryginalnej apki zastępując już tam istniejącą. Dzięki temu zachowamy oryginalne manifesty ze zmiennymi values,smali.

Takie błędy widziałem na SGS+ oraz wszystkich Xperiach po edycji aplikacji stockowych/systemowych

Po 3. Poziom kompresji kompilacji może wpływać na działanie lub nie działanie nowej apki, trzeba niestety testować na żywca.

W Apktool opcja nr. 20 , zakres od 0 do 9 ( 0 brak kompresji). Najprościej apktool kompresuje pliki arsc oraz dex by zajmowały mało miejsca w ROM. Czym większa kompresja tym mniejsza waga pliku .apk w ROM a większe użycie w RAM ( gdzieś musi się rozpakować). O ile framework może być bez kompresji o tyle inne aplikację najczęściej wymagają średniej (6) kompresji. Wpływa ona również na szybkość uruchamiania aplikacji, czym mniejsza kompresja tym szybciej się ładuje.

Po 4. Android SDK nie jest do niczego potrzebny

Nigdy nie miałem i apktool tego nie wymaga stąd moje spostrzeżenie, potrzeba jedynie javy.

Po 5. To już mało istotne dla większości ale podzielę się info, jeżeli postąpimy jak w pkt. 2 czyli ze starym manifestem będzie możliwy odex danej aplikacji, ale re-deodex już nie, wywali nam się niespójność manifestu/smali/valuses (nieznane adresowe)

Jeżeli re-kompilujemy apkę systemową w której nie można ruszyć manifestu, można ją odexować ale nie uda się ponownie deodexować, gdyż manifest nie będzie zawierał w sobie wcześniej dodanych linii kodu,plików.

w/w pierdoły są dla średnio zaawansowanego developera który w nie tylko zacznie tłumaczyć aplikację ale dodatkowo dopisuje w niej nowe linie kodu, funkcję itp itd.

[Wall-E]

No bardzo ładne uzupełnienie tematu.
Zawsze twierdziłem, że jak się uda sprowokować rzeczową dyskusję to tylko pożyteczne rzeczy z tego wychodzą

Nie mniej Ty opisałeś już bardziej zaawansowane czynności, które ja z premedytacją pominąłem żeby za bardzo nie mieszać... ale niech już będzie. Również i ten zakres tematu powinien zostać wreszcie wyczerpująco opisany.

W tym miejscu pozwolę sobie na kilka dodatkowych, w sumie drobnych, uwag i uzupełnień...

Po pierwsze [...]

Celna uwaga i odnośnik do niej umieszczę jako ciekawostkę w swoim tekście. "Jako ciekawostkę" bo w swoim opisie generalnie nie przewidywałem operacji na plikach systemowych - między innymi z powodów, które opisujesz, czyli z powodu większego poziomu komplikacji.

Po drugie [...]

Zdaje sobie sprawę, że istnieją urządzenia kompatybilne i kompatybilniejsze - takie życie.
Co do urządzeń Xperia nie wypowiadam się - nie mam, nie używam, nie znam się... Jeśli chodzi o SGS+... To urządzenie moim zdaniem jest całkowitym ewenementem jeśli chodzi o urządzenia Samsunga - kwestia właśnie ogólnej kompatybilności z innymi swoimi "ziomalami" od tego producenta.
Enyłej... Jak się pewnie domyślasz nie jestem w stanie przetestować każdego rekompilowanego programu na każdym dostępnym urządzeniu - nierealne... Nie mniej przyjąłem założenie, że jeśli działa u mnie to będzie działało przynajmniej na większości dostępnych urządzeń. Założenie być może błędne jednak ja opieram/łem się na podnoszonych wszędzie generaliach, które mówią, że Android jest jeden, a jego wersje są ze sobą kompatybilne ever - bzdura jak każda inna, ale jakiś punkt wyjścia trzeba mieć.

Po 3. [...]

No właśnie byłeś mi łaskaw przypomnieć o tym aspekcie zagadnienia. Szczerze mówiąc zapomniałem o tym.
Jednak nie zmienia to faktu, że opcji związanych z kompresją nawet długim kijem nie tykałem - właśnie dlatego, że o nich zapomniałem. A co w tym wszystkim ważne, rekompilowane apki działały po obróbce programem z domyślnymi ustawieniami kompresji - może właśnie dlatego mi działały

Po 4. [...]

To jest jedyna kwestia, w której pozwolę sobie nie zgodzić się z Tobą - przynajmniej nie całkowicie.
Faktem jest, że sama operacji de/kompilacji plików apk wymaga - przynajmniej w teorii - tylko i wyłącznie Javy. Ale... !!
Jeśli dobrze się wczytać we wszystkie opisy różnych APK Tooli (zgeneralizuję nazwę narzędzia, ale wiadomo o co c'mon), oraz inne treści traktujące o modyfikacji plików apk, to praktycznie zawsze można trafić na większe lub mniejsze wzmianki o SDK Androida. W różnej formie i w różnym kontekście - nie mniej, wynika z nich, że posiadanie owego SDK jest może nie tyle niezbędne, co wskazane.
Wspominałem o tym wcześniej... Ja bez w pełni uaktualnionego SDK nie byłem w stanie zrobić w APK Toolsach nic - ciągle miałem komunikat o braku potrzebnych plików.
Generalnie oparłem się na zbieżności przyczynowo-skutkowej mającej miejsce w moim przypadku: APK Tool nie działał -> Reinstalacja i aktualizacja SDK -> APK Tool działał. Właśnie z tego wyciągnąłem wniosek, że był MI on w jakiś sposób potrzebny.

Po 5. [...]

Ta kwestia chyba dosyć mocno już wybiega poza samą tematykę wątku - jest ważna, owszem. Jednak tyczy się ona działań już na tyle specyficznych, że raczej przekracza granice wiedzy posiadanej przez średnio zaawansowanego użytkownika.


Reasumując...Wszystko co opisałem w pierwszym poscie (elementy software'owe, metody, sposoby i czynności) pozwoliło mi na bezproblemowe robienie tego, co zostało opisane - tylko tego i niczego więcej.

[Toldo]

A ja myślę że warto by oddzielić to o czym pisał Phenom do osobnego wątku pt. modyfikacja systemowych apków. Ten wątek skupiać się ma na tłumaczeniu apek zewnętrznych. Apki systemowe w znakomitej większości nie wymagają tłumaczenia, a kwestia modyfikacji ich w sposób inny niż tłumaczenie poleceń w dwóch xmlach to już wyższa szkoła jazdy i jestem zdania, że użytkownik prędzej przeczyta gotowy tutorial niż tą bądź co bądź bardzo wartościową dyskusję.

Wysyłane z mojego GT-I9000 za pomocą Tapatalk 2

[Wall-E]

A ja myślę że warto by oddzielić to o czym pisał Phenom do osobnego wątku pt. modyfikacja systemowych apków.

A i owszem - pomysł przedni.

Poczekajmy na autora materiału - przyjdzie, odłączy się od całości i przeedytuje nowego "pierwszego" posta.

Enyłej... Ja swój materiał nieco zedytowałm i dodałem pewne informacje na które zwrócił uwagę Toldo.