Jeśli publikujesz aplikację w Google Play, musisz utworzyć i przesłać pakiet Android App Bundle. Gdy to zrobisz, Google Play będzie automatycznie generować i udostępniać zoptymalizowane pliki APK dla każdej konfiguracji urządzenia. Dzięki temu użytkownicy pobierają tylko kod i zasoby niezbędne do uruchomienia Twojej aplikacji. Publikowanie wielu plików APK jest przydatne, jeśli nie publikujesz w Google Play, ale musisz samodzielnie stworzyć i podpisać każdy plik APK oraz nim zarządzać.
Przy tworzeniu aplikacji na Androida, która ma korzystać z wielu pakietów APK dostępnych w Google Play, warto stosować sprawdzone metody od samego początku i uniknąć niepotrzebnych problemów w trakcie procesu programowania. Z tej lekcji dowiesz się, jak utworzyć wiele plików APK swojej aplikacji, z których każdy obejmuje inny rozmiar ekranu. Zyskasz też dostęp do narzędzi, dzięki którym obsługa bazy kodu z wieloma plikami APK będzie jak najbardziej prosta.
Potwierdzanie, że potrzebujesz wielu plików APK
Gdy próbujesz utworzyć aplikację, która działa na urządzeniach z Androidem o różnych rozmiarach, zwykle zależy Ci na wykorzystaniu całej dostępnej przestrzeni na większych urządzeniach bez uszczerbku dla zgodności i łatwości obsługi na mniejszych ekranach. Na początku może się wydawać, że obsługa wielu plików APK to najlepsze rozwiązanie, ale w rzeczywistości często tak nie jest. W sekcji Korzystanie z pojedynczego pliku APK w przewodniku dla programistów dla programistów tworzących wiele plików APK znajdziesz przydatne informacje o tym, jak można to zrobić za pomocą pojedynczego pliku APK oraz jak korzystać z naszej biblioteki pomocy. Zapoznaj się też z przewodnikiem po obsłudze wielu ekranów. Do dyspozycji masz nawet bibliotekę pomocy, którą możesz pobrać za pomocą pakietu Android SDK. Umożliwia ona używanie fragmentów na urządzeniach starszych niż Honeycomb (co znacznie ułatwia obsługę wielu ekranów w ramach jednego pliku APK).
Jeśli możesz nim zarządzać, ograniczenie aplikacji do jednego pliku APK ma kilka zalet, w tym:
- Publikowanie i testowanie jest łatwiejsze
- Trzeba zarządzać tylko jedną bazą kodu.
- Aplikacja może dostosowywać się do zmian konfiguracji urządzenia.
- Przywracanie aplikacji z różnych urządzeń po prostu działa
- Nie musisz martwić się o preferencje rynkowe, zachowanie użytkowników od momentu przejścia z jednego pakietu APK na kolejny ani który plik APK pasuje do danej klasy urządzeń.
W pozostałej części tej lekcji zakładamy, że znasz już temat, dokładnie wiesz, co znajduje się w powiązanych z nimi zasobach, i że stwierdzisz, że wiele plików APK to odpowiednia ścieżka dla Twojej aplikacji.
Pokaż swoje wymagania
Zacznij od utworzenia prostego wykresu, aby szybko określić, ile plików APK potrzebujesz i jakie rozmiary ekranów obejmuje każdy z nich. Na szczęście możesz szybko i łatwo przygotować listę swoich wymagań i zadbać o zastosowanie się do nich później. Zacznij od wiersza komórek reprezentujących różne rozmiary ekranu dostępne na platformie Androida.
| mały | normalny | duży | bardzo duża |
Teraz wystarczy pokolorować wykres, aby każdy kolor odpowiadał pakietowi APK. Oto przykład zastosowania każdego pliku APK na ekranach o określonych rozmiarach.
| mały | normalny | duży | bardzo duża |
W zależności od potrzeb możesz też mieć 2 pliki APK: „Mały i wszystko inne” lub „Bardzo duże i wszystkie pozostałe”. Kolorowanie na wykresie ułatwia też komunikację w zespole – teraz każdy plik APK może być określany jako „niebieski”, „zielony” lub „czerwony” niezależnie od tego, ile typów ekranów obejmuje.
Umieść cały wspólny kod i zasoby w projekcie biblioteki
Niezależnie od tego, czy modyfikujesz istniejącą aplikację na Androida, czy tworzysz ją od podstaw, jest to pierwsza i najważniejsza rzecz, którą należy zrobić w kodzie bazy kodu. Wszystko, co wchodzi w projekt biblioteki, trzeba zaktualizować tylko raz (np. tłumaczone teksty, motywy kolorystyczne, poprawki błędów we wspólnym kodzie), co skraca czas tworzenia aplikacji i zmniejsza ryzyko popełnienia pomyłek, których można było łatwo uniknąć.
Uwaga: chociaż szczegóły implementacji tworzenia i dołączania projektów bibliotecznych wykraczają poza zakres tej lekcji, aby dowiedzieć się więcej, przeczytaj artykuł Tworzenie biblioteki na Androida.
Jeśli konwertujesz istniejącą aplikację do obsługi wielu plików APK, przeszukaj bazę kodu w poszukiwaniu każdego zlokalizowanego pliku ciągu znaków, listy wartości, kolorów motywów, ikon menu i układu, które nie będą się zmieniać w różnych plikach APK, i umieść wszystko w projekcie biblioteki. Kod, który się nie zmieni, powinien trafić również do projektu bibliotecznego. Prawdopodobnie rozszerzysz te klasy, aby dodać metodę lub dwie metody z pliku APK do pliku APK.
Jeśli jednak tworzysz aplikację od podstaw, najpierw spróbuj napisać jak najwięcej kodu w projekcie bibliotecznym, a potem w razie potrzeby przenieś ją do pojedynczego pliku APK. W dłuższej perspektywie łatwiej jest zarządzać tym obiektem niż dodawać go do jednego, potem kolejnego, a potem kolejnego, a potem wielu miesięcy, próbując ustalić, czy ten obiekt blob można przenieść do sekcji biblioteki bez pomyłki.
Tworzenie nowych projektów APK
Każdy plik APK, który zamierzasz opublikować, powinien istnieć oddzielny projekt na Androida. Aby ułatwić porządkowanie, umieść projekt biblioteki i wszystkie powiązane projekty APK w tym samym folderze nadrzędnym. Pamiętaj też, że każdy plik APK musi mieć tę samą nazwę pakietu, ale niekoniecznie musi to być nazwa, która musi dzielić się z biblioteką. 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 i rozszerz ją w projekcie APK. Dzięki zdefiniowaniu działania początkowego w projekcie biblioteki możesz umieścić wszystkie inicjowanie aplikacji w jednym miejscu, dzięki czemu nie musisz ponownie wdrażać „uniwersalnych” zadań, takich jak inicjowanie Analytics, sprawdzanie licencji czy inne procedury inicjowania, które nie zmieniają się znacznie z pakietu APK na plik APK.
Dostosowywanie plików manifestu
Gdy użytkownik pobiera z Google Play aplikację, która korzysta z wielu plików APK, właściwy plik APK jest wybierany na podstawie 2 prostych reguł:
- Plik manifestu musi wskazywać, że dany plik APK spełnia wymagania.
- Spośród kwalifikujących się plików APK wygrana jest największa liczba wersji
Weźmy na przykład zbiór wielu plików APK opisanych wcześniej i załóżmy, że każdy z nich jest skonfigurowany do obsługi wszystkich rozmiarów ekranu większych niż „docelowy” rozmiar ekranu. Przy analizowaniu pojedynczych plików, możliwy zakres każdego pliku APK wyglądałby tak:
| mały | normalny | duży | bardzo duża |
| mały | normalny | duży | bardzo duża |
| mały | normalny | duży | bardzo duża |
Jeśli jednak w każdym pliku APK ustawisz atrybut versionCode w takiej sytuacji, że czerwony ≥ zielony ≥ niebieski – niebieski, użycie reguły „najwyższego numeru wersji wygrywa” spowoduje zwijanie wykresu w dół do tej wartości:
| mały | normalny | duży | bardzo duża |
Przyjmijmy teraz, że czerwony plik APK ma pewne wymagania, których nie ma w pozostałych. Pełną listę możliwych przyczyn znajdziesz na stronie Filtry w Google Play w przewodniku dla programistów aplikacji na Androida. Załóżmy na przykład, że kolor czerwony wymaga aparatu z przodu. Głównym elementem czerwonego pakietu APK jest wykorzystanie dodatkowego miejsca na ekranie do zabawy przednim aparatem. Okazuje się jednak, że nie wszystkie bardzo duże urządzenia mają przedni aparat. Co za strach!
Na szczęście, jeśli użytkownik przegląda Google Play na takim urządzeniu, Google Play sprawdzi plik manifestu, zauważy, że czerwony wskazuje, że przedni aparat jest wymagany, i zignoruje go, bo stwierdził, że czerwony i to urządzenie nie są dokładnie takie same jak w cyfrowym niebie. Dzięki temu stwierdzi, że kolor zielony jest nie tylko zgodny z bardzo dużymi urządzeniami, ale też nie ma znaczenia, czy znajdzie się przedni aparat. Użytkownik nadal może pobrać aplikację z Google Play, ponieważ mimo awarii przedniego aparatu nadal znajdował się plik APK obsługujący dany rozmiar ekranu.
Aby przechowywać wszystkie pliki APK na osobnych „ścieżkach”, musisz mieć dobry schemat kodu wersji. Zalecane kody znajdziesz w sekcji Kody wersji naszego przewodnika dla programistów. Ponieważ przykładowy zestaw plików APK obejmuje tylko 1 z 3 możliwych wymiarów, wystarczy oddzielić każdy z nich o 1000, a potem zwiększyć jego wartość. 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 Twój plik manifestu Androida wyglądałby 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-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Zielony:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Czerwony:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Pamiętaj, że technicznie wiele plików APK będzie działać z tagiem obsługiwanych ekranów lub tagiem zgodnych ekranów. Ogólnie zalecamy używanie ekranów z obsługą ekranów, a używanie obu tych tagów w tym samym pliku manifestu jest bardzo złe. Sprawia to, że cały proces nie jest potrzebny, i zwiększa ryzyko popełnienia. Pamiętaj też, że zamiast korzystać z wartości domyślnych (domyślnie „mały i normalny” mają zawsze wartość „prawda”), pliki manifestu jawnie określają wartość dla każdego rozmiaru ekranu. Dzięki temu możesz uwolnić się od problemów. Na przykład w pliku manifestu z docelowym pakietem SDK o wartości < 9 będzie automatycznie ustawiona wartość xlarge, ponieważ jeszcze nie istniał taki rozmiar. Unikaj więc dokładności.
Przejrzyj listę kontrolną przed opublikowaniem
Zanim prześlesz pliki do Google Play, dokładnie sprawdź te elementy. Pamiętaj, że odnoszą się one do wielu plików APK i nie stanowią pełnej listy kontrolnej dla wszystkich aplikacji przesyłanych do Google Play.
- Wszystkie pliki APK muszą mieć taką samą nazwę pakietu
- Wszystkie pliki APK muszą być podpisane za pomocą tego samego certyfikatu
- Każdy rozmiar ekranu, który ma obsługiwać pakiet APK, ustaw w pliku manifestu wartość „true”. Przy każdym rozmiarze ekranu, który ma unikać, ustaw wartość false
- Dokładnie sprawdź filtry pliku manifestu pod kątem sprzecznych informacji (plik APK, który obsługuje tylko babeczki na ekranach XLARGE, nikt nie zobaczy tego pliku).
- Każdy plik manifestu pakietu APK musi być unikalny na co najmniej 1 obsługiwanym ekranie, teksturze OpenGL lub wersji platformy.
- Przetestuj każdy plik APK na co najmniej jednym urządzeniu. Poza tym masz jeden z najbardziej dostępnych emulatorów urządzeń w branży, który jest dostępny na Twoim komputerze. Do szaleństwa!
Warto też sprawdzić skompilowany plik APK przed wprowadzeniem go na rynek, aby mieć pewność, że nie ma niespodzianek, które mogłyby ukryć aplikację w Google Play. To dość proste przy użyciu narzędzia „aapt”. Aapt (Android Asset Packaging Tool) jest częścią procesu 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 analizowania danych wyjściowych aapt sprawdź, czy nie ma sprzecznych wartości dla atrybutów „supports-screen” i „zgodności” oraz czy nie zostały dodane niezamierzone wartości „uses-feature” w wyniku uprawnień ustawionych w pliku manifestu. W przykładzie powyżej plik APK będzie niewidoczny dla większości lub na wszystkich urządzeniach.
Dlaczego? Dzięki dodaniu wymaganego uprawnienia SEND_SMS automatycznie dodaliśmy wymaganie funkcji android.hardware.telephony. Większość bardzo dużych urządzeń (o ile nie wszystkie) to tablety bez sprzętu telefonicznego, dlatego Google Play odfiltruje w takich przypadkach ten plik APK, dopóki nie pojawią się urządzenia, które będą na tyle duże, że mogą być traktowane jako duży ekran, i będą zawierać sprzęt telefoniczny.
Na szczęście ten problem można łatwo rozwiązać, dodając do pliku manifestu te wiersze:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Domyślnie dodawany jest też wymóg android.hardware.touchscreen. Jeśli chcesz, aby pakiet APK był widoczny na telewizorach nieobsługujących ekranu dotykowego, dodaj do pliku manifestu:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Gdy wykonasz czynności z listy kontrolnej przed opublikowaniem, prześlij swoje pakiety APK do Google Play. Może minąć trochę czasu, zanim aplikacja pojawi się podczas przeglądania Google Play, ale gdy już się pojawi, sprawdź jeszcze raz. Pobierz aplikację na ewentualne urządzenia testowe, aby upewnić się, że pliki APK są kierowane na odpowiednie urządzenia.
Więcej informacji o publikowaniu wielu plików APK w Google Play znajdziesz w artykule Obsługa wielu plików APK.