Jeśli publikujesz aplikację w Google Play, musisz utworzyć i przesłać pakiet aplikacji na Androida. Gdy to zrobisz, Google Play automatycznie wygeneruje i udostępni pliki APK zoptymalizowane pod kątem konfiguracji urządzenia każdego użytkownika, dzięki czemu pobiorą one 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ć plikami APK.
Podczas tworzenia aplikacji na Androida, która ma korzystać z wielu plików APK w Google Play, ważne jest, aby od razu zastosować dobre praktyki, aby uniknąć niepotrzebnych problemów na dalszych etapach procesu tworzenia. W tej lekcji pokazujemy, jak utworzyć kilka plików APK aplikacji, z których każdy będzie obsługiwał nieco inny zakres poziomów interfejsu API. Dostaniesz też narzędzia, które ułatwią zarządzanie kodem źródłowym wielu APK.
Potwierdź, że potrzebujesz kilku plików APK
Jeśli chcesz utworzyć aplikację, która będzie działać na różnych generacjach platformy Android, z pewnością zależy Ci na tym, aby korzystała z nowych funkcji na nowych urządzeniach, nie tracąc przy tym zgodności wstecznej. 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 użyciu naszej biblioteki pomocniczej. Możesz też dowiedzieć się, jak pisać kod, który działa tylko na określonych poziomach interfejsu API w pojedynczym pliku APK, bez stosowania kosztownych pod względem obliczeniowym technik, takich jak odbicie lustrzane, opisanych w tym artykule.
Jeśli możesz to zrobić, ograniczenie aplikacji do jednego pliku APK ma kilka zalet, takich jak:
- Łatwiej publikować i testować
- Trzeba utrzymywać tylko 1 kod źródłowy
- Aplikacja może dostosowywać się do zmian w konfiguracji urządzenia
- Przywracanie aplikacji na różnych urządzeniach działa bez zarzutu.
- 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łej części tej lekcji zakładamy, że zapoznałeś/zapoznałaś się z tematem, dokładnie przeanalizowałeś/przeanalizowałaś materiały z połączonych zasobów i uznałeś/uznano, że w przypadku Twojej aplikacji odpowiednim rozwiązaniem jest użycie wielu plików APK.
Wymagania w postaci wykresu
Najpierw utwórz prosty wykres, aby szybko określić, ile plików APK potrzebujesz i jaki zakres interfejsu API pokrywa każdy z nich. Na stronie Wersje platformy na stronie dewelopera Androida znajdziesz dane o względnej liczbie aktywnych urządzeń z określoną wersją platformy Android. Poza tym, choć na początku może się to wydawać proste, śledzenie, do których poziomów interfejsu API kieruje się każdy plik APK, dość szybko staje się trudne, zwłaszcza jeśli występuje pewne nakładanie się (często tak jest). Na szczęście można szybko i łatwo stworzyć schemat wymagań, aby później łatwo się do niego odnieść.
Aby utworzyć wykres z wieloma pakietami APK, zacznij od wiersza komórek reprezentujących różne poziomy interfejsu API platformy Android. Dodaj na końcu dodatkową komórkę, aby reprezentować przyszłe wersje Androida.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Teraz pokoloruj wykres tak, aby każdy kolor odpowiadał jednemu plikowi APK. Oto przykład zastosowania poszczególnych plików APK do określonego zakresu poziomów interfejsu API.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Po utworzeniu tego wykresu rozpowszechnij go wśród członków zespołu. Komunikacja w zespole dotycząca projektu stała się łatwiejsza, ponieważ zamiast pytać „Jak wygląda APK dla poziomów interfejsu API 3–6, czyli Androida 1.x?”, Jak to idzie? Wystarczy powiedzieć „Jak idzie z tworzeniem pliku APK Blue?”.
umieszczanie całego wspólnego kodu i zasobów w projekcie biblioteki,
Niezależnie od tego, czy modyfikujesz już istniejącą aplikację na Androida, czy tworzysz ją od podstaw, jest to pierwsza i najważniejsza rzecz, którą należy zrobić z bazą kodu. Wszystko, co wchodzi w skład projektu biblioteki, musi zostać zaktualizowane tylko raz (np. łańcuchy znaków zlokalizowane na potrzeby różnych języków, motywy kolorów, błędy poprawione w kodzie współdzielonym), co skraca czas rozwoju i zmniejsza prawdopodobieństwo popełnienia błędów, których można było łatwo uniknąć.
Uwaga: szczegóły implementacji 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ące aplikacje, aby obsługiwały wiele pakietów APK, przeszukaj kod pod kątem każdego zlokalizowanego pliku z wierszami, listy wartości, motywów, kolorów, ikon menu i układów, które nie będą się zmieniać w różnych pakietach APK, i umieścić je w projekcie biblioteki. Kod, który nie ulegnie znacznym zmianom, powinien również znajdować się w projekcie biblioteki. Prawdopodobnie będziesz musiał rozszerzyć te klasy, aby dodać do pliku APK jedną lub 2 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 poszczególnych plików APK. Długofalowo jest to znacznie łatwiejsze niż dodawanie do jednej, potem do drugiej, potem do kolejnej, a potem po kilku miesiącach próbowanie ustalić, czy ten blob można przenieść do sekcji biblioteki bez niszczenia czegokolwiek.
Tworzenie nowych projektów APK
Dla każdego pliku APK, który chcesz opublikować, powinien istnieć osobny 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 zgodne 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 początkowej czynności umożliwia zebranie 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 przypadku kolejnych plików APK.
Dostosowywanie plików manifestu
Gdy użytkownik pobiera aplikację, która korzysta z kilku plików APK, Google Play wybiera odpowiedni plik APK na podstawie 2 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.
Weźmy na przykład zestaw kilku opisanych wcześniej plików APK i zakładamy, że nie ustawiliśmy maksymalnego poziomu interfejsu API dla żadnego z nich. W przypadku każdego pakietu APK zakres możliwych wartości wyglądałby tak:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Ponieważ plik APK z wyższą wartością parametru minSdkVersion musi mieć też wyższy kod wersji, wiemy, że pod względem wartości kodu wersji czerwony ≥ zielony ≥ niebieski. Dlatego możemy zwinąć wykres, aby wyglądał tak:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Załóżmy też, że plik APK o nazwie Red APK ma pewne wymagania, których nie mają 2 inne pliki. Na stronie Filtry w Google Play w przewodniku dla deweloperów Androida znajdziesz całą listę możliwych przyczyn. Załóżmy na potrzeby tego przykładu, że kolor czerwony wymaga użycia przedniego aparatu. Celem czerwonego pliku APK jest połączenie przedniej kamery z nowymi funkcjami dodanymi w interfejsie API 11. Okazuje się jednak, że nie wszystkie urządzenia, które obsługują interfejs API 11, mają nawet przednie kamery. Horror!
Na szczęście, jeśli użytkownik przegląda Google Play na takim urządzeniu, Google Play sprawdzi manifest, zauważy, że aplikacja Red wymaga przedniej kamery, i po cichu go zignoruje, ponieważ uzna, że Red i to urządzenie nie są stworzone dla siebie. W ten sposób zobaczysz, że Green jest zgodny z urządzeniami z interfejsem API 11 (ponieważ nie zdefiniowano wartości maxSdkVersion), ale też nie ma znaczenia, czy ma przednią kamerę. Użytkownik może nadal pobrać aplikację z Google Play, ponieważ pomimo całego zamieszania z przednią kamerą nadal istniał plik APK obsługujący ten poziom interfejsu API.
Aby wszystkie pliki APK były dostępne na osobnych „ścieżkach”, ważne jest, aby mieć odpowiedni schemat kodów wersji. Zalecane ustawienia znajdziesz w sekcji Kody wersji w poradniku dla deweloperów. Ponieważ przykładowy zestaw plików APK dotyczy tylko 1 z 3 możliwych wymiarów, wystarczy rozdzielić każdy plik APK o 1000, ustawić pierwsze 2 cyfry na wartość minSdkVersion danego pliku APK i od niej zwiększać. Może to wyglądać tak:
Niebieski: 03001, 03002, 03003, 03004…
Zielone: 07001, 07002, 07003, 07004…
Czerwony:11001, 11002, 11003, 11004...
Po połączeniu wszystkich tych elementów plik manifestu Androida będzie wyglądał mniej więcej tak:
Niebieski:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="03001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> ...
Zielony:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="07001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="7" /> ...
Czerwony:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="11001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> ...
Sprawdzanie listy kontrolnej przed opublikowaniem
Zanim prześlesz aplikację do Google Play, sprawdź te kwestie. Pamiętaj, że te informacje dotyczą wielu plików APK i w żaden sposób 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.
- Jeśli pliki APK pokrywają się pod względem wersji platformy, ten, który ma wyższą wartość parametru minSdkVersion, musi mieć wyższy kod wersji.
- Sprawdź, czy w filtrach pliku manifestu nie ma sprzecznych informacji (pliku APK, który obsługuje tylko wersję cupcake na ekranach XLARGE, nikt nie zobaczy).
- Plik manifestu każdego pliku APK musi być unikalny co najmniej w przypadku jednej z tych rzeczy: obsługiwanego ekranu, tekstury OpenGL lub wersji platformy.
- Spróbuj przetestować każdy plik APK na co najmniej 1 urządzeniu. Jeśli nie, masz na swoim komputerze deweloperskim jeden z najbardziej konfigurowalnych emulatorów urządzeń na rynku. Do dzieła!
Przed opublikowaniem na rynku warto też sprawdzić skompilowany plik APK, aby upewnić się, że nie zawiera on żadnych niespodzianek, które mogłyby ukryć aplikację w Google Play. To bardzo proste, jeśli użyjesz narzędzia „aapt”. Aapt (Android Asset Packaging Tool) jest częścią procesu kompilacji służącego 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: 'small' 'normal' 'large' '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, a także 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 wielu urządzeń.
Dlaczego? Dodanie wymaganego uprawnienia SEND_SMS spowodowało dodanie wymagań dotyczących funkcji android.hardware.telephony. Interfejs API 11 to Honeycomb (wersja Androida zoptymalizowana pod kątem tabletów), a żadne urządzenia z Honeycomb nie mają sprzętu telefonicznego. Google Play będzie więc odfiltrowywać ten plik APK we wszystkich przypadkach, dopóki nie pojawią się urządzenia z wyższym poziomem interfejsu API, które będą miały też 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, do pliku manifestu dodaj:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Po wypełnieniu listy kontrolnej przed udostępnieniem aplikacji prześlij 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 dostępne urządzenia testowe, aby mieć pewność, że pliki APK są kierowane na odpowiednie urządzenia. Gratulacje! Wszystko gotowe.