Jeśli publikujesz aplikację w Google Play, musisz utworzyć i przesłać pakiet aplikacji na Androida. Gdy to zrobisz, Google Play automatycznie wygeneruje i prześle zoptymalizowane pliki APK dla każdej konfiguracji urządzenia użytkownika, aby pobrać tylko kod i zasoby potrzebne do uruchomienia aplikacji. Publikowanie wielu plików APK jest przydatne, jeśli nie publikujesz w Google Play, ale musisz samodzielnie tworzyć, podpisywać i zarządzać poszczególnymi plikami APK.
Przy programowaniu aplikacji na Androida, które będą korzystać z wielu pakietów APK w Google Play, warto od razu stosować pewne sprawdzone metody, by uniknąć niepotrzebnych problemów w trakcie programowania. Z tego filmu dowiesz się, jak utworzyć kilka plików APK aplikacji, z których każdy będzie obsługiwał inny podzbiór formatów tekstur OpenGL. Otrzymasz też narzędzia niezbędne do jak najłatwiejszego zarządzania kodem źródłowym wielu APK-ów.
Potwierdź, że potrzebujesz kilku plików APK
Tworząc aplikację, która działa na wszystkich dostępnych urządzeniach z Androidem, jest naturalne, że zależy Ci na tym, by wyglądała jak najlepiej na każdym urządzeniu, niezależnie od tego, że nie wszystkie obsługują ten sam zestaw tekstur GL. Na pierwszy rzut oka może się wydawać, że obsługa wielu plików APK jest najlepszym rozwiązaniem, ale często tak nie jest. W sekcji Używanie pojedynczego pliku APK w przewodniku dla deweloperów dotyczącym wielu plików APK znajdziesz przydatne informacje o tym, jak to zrobić za pomocą pojedynczego pliku APK, w tym o wykrywanie obsługiwanych formatów tekstur w czasie wykonywania. W zależności od sytuacji może być łatwiej załączyć wszystkie formaty w aplikacji i wybrać, którego użyć w czasie działania.
Jeśli możesz to zrobić, ograniczenie aplikacji do jednego pliku APK ma kilka zalet, w tym:
- Łatwiej publikować i testować
- Trzeba utrzymywać tylko jedną bazę kodu
- Aplikacja może dostosowywać się do zmian w konfiguracji urządzenia
- Przywracanie aplikacji na różnych urządzeniach działa bezproblemowo.
- Nie musisz się martwić preferencjami rynkowymi, zachowaniem po „uaktualnieniu” z jednego pliku APK na inny ani tym, który plik APK pasuje do której klasy urządzeń.
W pozostałych częściach tej lekcji zakładamy, że zapoznałeś/zapoznałaś się z tematem, dokładnie przeanalizowałeś/przeanalizowałaś materiały z linków i uznałeś/uznano, że w przypadku Twojej aplikacji najlepszym rozwiązaniem jest użycie wielu plików APK.
Wymagania w postaci wykresu
Przewodnik dla programistów aplikacji na Androida zawiera przydatne omówienie niektórych popularnych obsługiwanych tekstur na stronie supports-gl-texture. Znajdziesz tam też wskazówki dotyczące tego, które telefony (lub rodziny telefonów) obsługują określone formaty tekstur. Zazwyczaj warto, aby jeden z plików APK obsługiwał format ETC1, ponieważ jest on obsługiwany na wszystkich urządzeniach z Androidem, które obsługują specyfikację OpenGL ES 2.0.
Większość urządzeń z Androidem obsługuje więcej niż jeden format tekstur, więc musisz ustalić kolejność preferencji. Utwórz wykres zawierający wszystkie formaty, które będzie obsługiwać Twoja aplikacja. Komórka znajdująca się najdalej w lewo będzie miała najniższy priorytet (prawdopodobnie będzie to ETC1, czyli naprawdę solidny domyślny format pod względem wydajności i zgodności). Następnie pokoloruj wykres tak, aby każda komórka odpowiadała plikowi APK.
| ETC1 | ATI | PowerVR |
Kolory na wykresie nie tylko sprawiają, że ten przewodnik nie jest monochromatyczny. Ułatwiają też komunikację w zespole. Teraz możesz po prostu odwoływać się do poszczególnych plików APK jako „niebieski”, „zielony” lub „czerwony”, zamiast „ten, który obsługuje formaty tekstur ETC1” itp.
umieszczanie całego wspólnego kodu i zasobów w projekcie biblioteki,
Niezależnie od tego, czy modyfikujesz istniejącą aplikację na Androida, czy tworzysz ją od zera, jest to pierwsza rzecz, którą musisz zrobić w bazie kodu. Wszystko, co wchodzi w skład projektu bibliotecznego, trzeba zaktualizować tylko raz (np. zlokalizowane na różne języki ciągi, motywy kolorystyczne, naprawione błędy w wspólnym kodzie), co skraca czas programowania i zmniejsza prawdopodobieństwo pomyłek, których można łatwo uniknąć.
Uwaga: szczegóły dotyczące tworzenia i uwzględniania projektów biblioteki wykraczają poza zakres tego samouczka, ale możesz się z nimi zapoznać w artykule Tworzenie biblioteki na Androida.
Jeśli konwertujesz istniejącą aplikację, aby korzystała z wielu plików APK, przeszukaj bazę kodu pod kątem każdego pliku ze zlokalizowanymi ciągami znaków, listy wartości, kolorów motywów, ikon menu i układu, które nie ulegną zmianie w różnych plikach APK, a potem umieść to wszystko w projekcie biblioteki. Kod, który nie ulegnie znacznym zmianom, powinien również znaleźć się w projekcie biblioteki. Prawdopodobnie będziesz musiał rozszerzyć te klasy, aby dodać jedną lub dwie metody z pliku APK.
Jeśli natomiast tworzysz aplikację od podstaw, najpierw staraj się pisać kod w projekcie biblioteki, a potem w razie potrzeby przenoś go do osobnego pliku APK. Na dłuższą metę o wiele łatwiej zarządzać tym blokiem niż dodawanie do jednego, potem kolejnego i kolejnego, a potem kilka miesięcy później próbując ustalić, czy ten obiekt blob da się przenieść do sekcji biblioteki bez korygowania wszystkiego.
Tworzenie nowych projektów plików APK
Do każdego pakietu APK, który zamierzasz opublikować, powinien istnieć oddzielny projekt na Androida. Aby ułatwić sobie organizację, umieść projekt biblioteki i wszystkie powiązane projekty plików APK w tym samym folderze nadrzędnym. Pamiętaj też, że każdy plik APK musi mieć tę samą nazwę pakietu, ale nie musi być ona taka sama jak nazwa biblioteki. Jeśli masz 3 pliki APK zgodnie ze schematem opisanym wcześniej, katalog główny może wyglądać tak:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
Po utworzeniu projektów dodaj projekt biblioteki jako odwołanie do każdego projektu APK. Jeśli to możliwe, zdefiniuj początkową aktywność w projekcie biblioteki, a potem rozszerz tę aktywność w projekcie APK. Zdefiniowanie w projekcie biblioteki aktywności początkowej umożliwia umieszczenie wszystkich zadań inicjujących aplikację w jednym miejscu, dzięki czemu w każdym pliku APK nie trzeba będzie ponownie implementować „uniwersalnych” zadań, takich jak inicjowanie Analytics, sprawdzanie licencji i inne procedury inicjowania, które nie zmieniają się znacząco w poszczególnych plikach APK.
Dostosuj pliki manifestu
Gdy użytkownik pobiera z Google Play aplikację, która korzysta z wielu plików APK, właściwy plik APK dobiera pakiet na podstawie kilku prostych reguł:
- Plik manifestu musi wskazywać, że dany plik APK spełnia wymagania.
- Wśród kwalifikujących się plików APK wygrywa plik z najwyższym numerem wersji.
- Jeśli cokolwiek z formatów tekstur wymienionych w pliku APK jest obsługiwane przez dostępne na rynku urządzenie, to urządzenie jest uznawane za odpowiednie.
W przypadku tekstur GL ostatnie reguła jest ważna. Oznacza to, że na przykład bardzo uważnie musisz używać różnych formatów GL w tej samej aplikacji. Jeśli korzystano z technologii PowerVR w 99% przypadków, ale w przypadku ekranu powitalnego – ETC1... W takim przypadku manifest musi wskazywać obsługę obu formatów. Urządzenie, które tylko obsługuje ETC1, zostanie uznane za zgodne, aplikacja zostanie pobrana, a użytkownik zobaczy ekscytujące komunikaty o awarii. Jeśli używasz wielu plików APK, aby dostosować aplikację do różnych urządzeń na podstawie obsługi tekstur GL, zwykle będzie to jeden format tekstury na plik APK.
W związku z tym obsługa tekstur jest nieco inna niż w przypadku pozostałych wymiarów pliku APK, poziomu interfejsu API i rozmiaru ekranu. Każde urządzenie ma tylko jeden poziom interfejsu API i jeden rozmiar ekranu, a to, czy plik APK obsługuje różne poziomy i rozmiary, zależy od dewelopera. W przypadku tekstur plik APK zwykle obsługuje jedną teksturę, a urządzenie – wiele. Często występuje nakładanie się plików APK na jednym urządzeniu, ale rozwiązanie jest takie samo: kody wersji.
Na przykład weź kilka urządzeń i sprawdź, ile z zdefiniowanych wcześniej plików APK pasuje do każdego z nich.
| FooPhone | Nexus S | Evo |
| ETC1 | elektroniczny pobór opłat drogowych 1 | ETC1 |
| PowerVR | ATI TC |
Zakładając, że formaty PowerVR i ATI są preferowane przed ETC1, jeśli w każdym pliku APK ustawimy atrybut versionCode tak, aby czerwony ≥ zielony ≥ niebieski, to na urządzeniach, które obsługują te formaty, zawsze będzie wybierany czerwony i zielony zamiast niebieskiego. Jeśli pojawi się urządzenie, które obsługuje zarówno czerwony, jak i zielony, wybrany zostanie czerwony.
Aby wszystkie pliki APK były na osobnych „ścieżkach”, ważne jest, aby mieć dobry kod wersji. Zalecany kod znajdziesz w sekcji Kody wersji w naszym przewodniku dla programistów. Ponieważ przykładowy zestaw plików APK obejmuje tylko 1 z 3 możliwych wymiarów, wystarczy oddzielić każdy plik APK o 1000 i od tej liczby zwiększać go o 1000. Może to wyglądać tak:
Niebieski: 1001, 1002, 1003, 1004...
Zielony: 2001, 2002, 2003, 2004…
Czerwony:3001, 3002, 3003, 3004...
Po połączeniu wszystkich tych elementów pliki manifestu Androida będą wyglądać mniej więcej tak:
Niebieski:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
...
Zielony:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
...
Czerwony:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
...
Sprawdzanie listy kontrolnej przed opublikowaniem
Zanim prześlesz aplikację do Google Play, sprawdź te kwestie. Pamiętaj, że dotyczą one wielu plików APK i nie stanowią pełnej listy kontrolnej dla wszystkich aplikacji przesyłanych do Google Play.
- Wszystkie pliki APK muszą mieć tę samą nazwę pakietu
- Wszystkie pliki APK muszą być podpisane tym samym certyfikatem.
- Dokładnie sprawdź filtry manifestu pod kątem sprzecznych informacji (plik APK, który obsługuje tylko babeczki na ekranach XLARGE, nie będzie dla nikogo widoczny).
- Każdy plik manifestu pliku APK musi być unikalny w obrębie co najmniej 1 obsługiwanego ekranu, tekstury OpenGL lub wersji platformy
- Spróbuj przetestować każdy pakiet APK na co najmniej 1 urządzeniu. W przeciwnym razie masz na swoim komputerze deweloperskim jeden z najbardziej konfigurowalnych emulatorów urządzeń na rynku. Do dzieła!
Przed opublikowaniem aplikacji w Google Play warto też sprawdzić skompilowany plik APK, aby upewnić się, że nie zawiera on żadnych niespodzianek, które mogłyby uniemożliwić wyświetlanie aplikacji w Google Play. To dość proste, jeśli użyjesz narzędzia „aapt”. Aapt (narzędzie Android Asset Packaging) jest częścią procesu kompilacji, który służy do tworzenia i pakowania aplikacji na Androida. Jest też bardzo przydatnym narzędziem do ich sprawdzania.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Podczas sprawdzania danych wyjściowych aapt sprawdź, czy nie ma sprzecznych wartości w przypadku atrybutów supports-screens i compatible-screens oraz czy nie ma niezamierzonych wartości atrybutu „uses-feature”, które zostały dodane w ramach uprawnień ustawionych w pliku manifestu. W przykładzie powyżej plik APK będzie niewidoczny dla większości, jeśli nie wszystkich, urządzeń.
Dlaczego? Dodanie wymaganego uprawnienia SEND_SMS spowodowało dodanie wymaganej funkcji android.hardware.telephony. Większość (jeśli nie wszystkie) bardzo duże urządzenia to tablety bez dodatkowego sprzętu telefonicznego, dlatego Google Play będzie odfiltrowywać ten plik APK w takich przypadkach, dopóki nie pojawią się nowe urządzenia, które będą na tyle duże, by można je było wyświetlać jako bardzo duże ekrany, i będą wyposażone w sprzęt telefoniczny.
Na szczęście można to łatwo naprawić, dodając do pliku manifestu:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Wymaganie android.hardware.touchscreen jest też dodawane domyślnie. Jeśli chcesz, aby plik APK był widoczny na telewizorach, które nie mają ekranu dotykowego, dodaj do pliku manifestu:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Po wypełnieniu listy kontrolnej przed opublikowaniem przesyłaj pliki APK do Google Play. Może minąć trochę czasu, zanim aplikacja pojawi się w Google Play, ale gdy to nastąpi, wykonaj jeszcze jedną kontrolę. Pobierz aplikację na dowolne urządzenia testowe, aby mieć pewność, że pliki APK są kierowane na odpowiednie urządzenia. Gratulacje, wszystko gotowe.