Jeśli publikujesz aplikację w Google Play, musisz utworzyć i przesłać plik Android App Bundle Gdy to zrobisz, Google Play automatycznie generuje i udostępnia zoptymalizowane pliki APK dla konfiguracji urządzenia każdego użytkownika, a potem pobiera tylko kod i zasoby potrzebne do uruchomienia aplikacji. Publikowanie wielu plików APK przydaje się, jeśli: nie możesz publikować w Google Play, ale musisz samodzielnie utworzyć i podpisać każdy plik APK oraz nim zarządzać.
Tworząc aplikację na Androida, która korzysta z wielu plików APK w Google Play, Ważne jest, by stosować kilka sprawdzonych metod od samego początku, aby uniknąć niepotrzebnych problemów na dalszy rozwój procesu programowania. Z tej lekcji dowiesz się, jak utworzyć wiele plików APK i obsługiwać różne rozmiary ekranów w aplikacjach. Zyskasz też dostęp do narzędzi, które pomogą Ci jak najłatwiej zarządzać bazą kodu z wielu plików APK.
Potwierdź, że potrzebujesz wielu plików APK
Kiedy próbujesz stworzyć aplikację, która współpracuje z wieloma urządzeniami z Androidem urządzeń, zależy Ci na tym, aby Twoja aplikacja jak najlepiej prezentowała się na każdym z nich. Chcesz wykorzystać przestrzeń na dużych ekranach, ale nadal pracować na małych, używać nowych funkcji interfejsu API Androida lub tekstur wizualnych dostępnych na najnowszych urządzeniach, ale nie rezygnować z tych starszych. Może wydaje się, że najlepszym rozwiązaniem jest obsługa wielu plików APK, ale często nie jest to tych kwestii. Korzystanie z Pojedynczy pakiet APK w przewodniku po wielu plikach APK zawiera przydatne informacje o tym, wszystko to można zrobić za pomocą jednego pliku APK, w tym naszej biblioteki pomocy, i linki do zasobów w przewodniku dla programistów aplikacji na Androida.
Jeśli możesz sobie z tym poradzić, ograniczenie aplikacji do jednego pliku APK ma wiele 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 po prostu działa
- Nie musisz martwić się o preferencje rynkowe ani działanie związane z uaktualnieniami. z jednego pakietu APK do Następnie lub z jakiej klasy urządzeń korzysta się z pakietu APK
W pozostałej części tej lekcji zakładamy, że udało Ci się dokładnie przyswoić ten temat materiałów w powiązanych zasobach i ustalić, że odpowiednią ścieżką dla pliku APK jest kilka plików APK aplikacji.
Przedstaw swoje wymagania
Zacznij od utworzenia prostego wykresu, by szybko określić, ile plików APK potrzebujesz i na jakim ekranie. rozmiary poszczególnych plików APK. Na szczęście możesz szybko i łatwo sporządzić schemat swoich wymagań, aby móc do niego wrócić w przyszłości. Załóżmy, że chcesz podzielić pliki APK na 2 wymiary: interfejs API i rozmiaru ekranu. Utwórz tabelę z wierszem i kolumną dla każdej możliwej pary wartości, a także kolor w niektórych „blobach”, każdy kolor reprezentuje jeden plik APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| mały | |||||||||||
| normalna | |||||||||||
| duży | |||||||||||
| bardzo duża |
Powyżej znajduje się przykład z czterema plikami APK. Niebieski oznacza wszystkie urządzenia z małym i normalnym ekranem, a zielony – duży urządzeń z ekranami, a czerwony – dla urządzeń z dużymi ekranami, z interfejsami API w zakresie 3–10. Fioletowy to zwłaszcza w przypadku wszystkich rozmiarów ekranu, ale tylko w przypadku interfejsu API w wersji 11 i nowszych. Co ważniejsze, w pobliżu patrząc na ten wykres, od razu wiesz, który plik APK obejmuje daną kombinację interfejsu API/rozmiaru ekranu. Do Każdy z nich ma też elegancki kryptonim, bo „przetestowaliśmy wersję czerwonych to dużo jest łatwiejsze niż pytanie „Czy przetestowaliśmy pakiet APK o rozmiarze 3–10 razy większym z Xoomem?” Wydrukuj to i przekaż go każdej osobie pracującej nad Twoją bazą kodu. Życie stało się dużo łatwiejsze.
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 zera, pierwszą rzeczą, którą należy zrobić w przypadku bazy kodu, i zdecydowanie najważniejszą. Wszystko, co wchodzi w skład projektu biblioteki, musi być aktualizowane tylko raz (np. łańcuchy znaków zlokalizowane na potrzeby różnych języków, motywy kolorów, błędy poprawione w podzielonym kodzie), co skraca czas rozwoju i zmniejsza prawdopodobieństwo popełnienia błędów, których można było łatwo uniknąć.
Uwaga: chociaż szczegóły implementacji dotyczące tworzenia uwzględnianie projektów z biblioteki wykraczających poza zakres tej lekcji, Przeczytaj artykuł Tworzenie biblioteki Androida.
Jeśli konwertujesz istniejącą aplikację tak, aby obsługiwała wiele plików APK, przeszukaj bazę kodu pod kątem każdego zlokalizowanego pliku z ciągami znaków, listy wartości, motywu kolorów, ikon menu i układu, które nie zmienią się w plikach APK. w projekcie bibliotecznym. Kod, który nie ulegnie znaczącej zmianie, powinien w projekcie bibliotecznym. Być może rozszerzysz te klas, by dodać metodę (lub dwie) z pliku APK do pliku APK.
Jeśli natomiast tworzysz aplikację od zera, spróbuj użyć metody aby napisać kod w projekcie biblioteki, najpierw, a potem przenieść go tylko 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. Łatwe należy umieścić projekt biblioteki i wszystkie powiązane z nim projekty APK w tym samym folderze nadrzędnym. Pamiętaj też, że każdy plik APK musi mieć tę samą nazwę pakietu, choć nie zawsze musisz udostępnić bibliotekę nazwy pakietu. Jeśli masz 3 pliki APK zgodne ze schematem Twój katalog główny może wyglądać tak:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
Po utworzeniu projektów dodaj projekt z biblioteki jako odwołanie do każdego projektu APK. Jeśli określ aktywność początkową w projekcie biblioteki i rozszerzaj ją w pakiecie APK w projektach AI. Ustalenie działania początkowe w projekcie bibliotecznym pozwala umieścić wszystkie inicjowanie aplikacji w jednym miejscu, dzięki czemu nie trzeba ponowne wdrożenie „uniwersalnego” m.in. inicjowanie Analytics, sprawdzanie licencji procedury inicjowania, które nie zmieniają się znacząco między APK.
Dostosuj pliki manifestu
Jeśli użytkownik pobiera z Google Play aplikację, która korzysta z wielu plików APK, poprawny parametr Przy wyborze pliku APK do użycia są 2 proste reguły:
- Plik manifestu musi pokazywać, że dany plik APK spełnia wymagania
- Spośród kwalifikujących się plików APK wygrywa największy numer wersji.
Dla przykładu przyjrzyjmy się zestawowi wielu pakietów APK opisanych wcześniej i zakładamy, że każdy Plik APK został skonfigurowany do obsługi wszystkich rozmiarów ekranów większych niż docelowy rozmiaru ekranu. Przyjrzyjmy się przykładowy wykres z poprzedniej części:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| mały | |||||||||||
| normalna | |||||||||||
| duży | |||||||||||
| bardzo duża |
Ponieważ pokrycie może się nakładać, możemy opisać obszar objęty każdym APK w ten sposób:
- Niebieski dotyczy wszystkich ekranów, minSDK 3.
- Zielony kolor obejmuje ekrany duże i większe, minimalna wersja pakietu SDK 3.
- Czerwony dotyczy bardzo dużych ekranów (zwykle tabletów), a pakiet minSDK w wersji 9.
- Fioletowy obejmuje wszystkie ekrany, minSDK w wersji 11.
Pamiętaj, że te zasady bardzo się pokrywają. Na przykład XLarge na urządzeniu z interfejsem API 11 może w rzeczywistości uruchomić dowolny z 4 wymienionych plików APK. Jednak przy użyciu „najwyższego numeru wersji wygrywa” możemy więc ustawić kolejność w następujący sposób:
Fioletowy ≥ czerwony ≥ zielony ≥ niebieski
Po co zezwolić na wszystkie nakładające się segmenty? Przyjmijmy, że w przypadku fioletowego pakietu APK wymagane jest a pozostałe – nie. Strona Filtry w Google Play w przewodniku dla programistów aplikacji na Androida. Przyjrzyjmy się przykładowo. załóżmy, że kolor fioletowy wymaga aparatu przedniego. Fioletowym celem jest korzysta z rozrywek dzięki przednim aparatem. Okazuje się jednak, że nie wszystkie urządzenia z interfejsem API 11 lub nowszym mają nawet przedni aparat! Horror!
Na szczęście, jeśli użytkownik przegląda Google Play na takim urządzeniu, Uwaga: Purple wymienia przedni aparat jako wymaganie i dyskretnie go zignoruj. po ustaleniu, że urządzenie Purple i to urządzenie nie pasują do siebie w cyfrowym niebie. W tym przypadku zobaczysz, że Red jest zgodny nie tylko z urządzeniami xlarge, ale też nie ma znaczenia, czy mają one przedni aparat. Użytkownik nadal może pobrać aplikację z Google Play, Bo pomimo tego, że przedni aparat nie działał prawidłowo, nadal był plik APK, który go obsługiwał. poziom interfejsu API.
Aby wszystkie pliki APK mieć oddzielne „ścieżki”, ważne jest, by stworzyć dobry kod wersji oszustw. Zalecany kod znajdziesz w sekcji Kody wersji w naszym przewodniku dla programistów. Warto przeczytać całą sekcję, ale podstawowe informacje o tym zestawie plików APK, użyjemy 2 cyfr do określenia parametru minSDK, dwóch reprezentujących minimalny/maksymalny rozmiar ekranu oraz 3 reprezentujący numer kompilacji. Dzięki temu po uaktualnieniu urządzenia do nowej wersji Androida, (na przykład od 10 do 11) wszystkich plików APK, które kwalifikują się i preferowane są zamiast obecnie zainstalowanych. jest postrzegana przez urządzenie jako „uaktualnienie”. Schemat numeru wersji w przypadku zastosowania w przykładzie pakietu APK, może wyglądać tak:
Niebieski: 0304001, 0304002, 0304003...
Zielony: 0334001, 0334002, 0334003
Czerwony: 0344001, 0344002, 0344003...
Fioletowy: 1104001, 1104002, 1104003...
Po połączeniu wszystkich plików manifestu Androida pliki manifestu będą wyglądały mniej więcej tak: :
Niebieski:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<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="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<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="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Fioletowy:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Pamiętaj, że z technicznego punktu widzenia wiele plików APK będzie działać z tagiem Support-screen lub tagiem tagu zgodnych ekranów. W ogóle zalecamy użycie atrybutu Supports-screens, a używanie obu atrybutów jest zwykle bardzo złym pomysłem, ponieważ skomplikuje to niepotrzebnie proces i zwiększy prawdopodobieństwo wystąpienia błędów. Należy również pamiętać, że zamiast korzystać z wartości domyślnych (małe i normalne są zawsze Prawda), domyślnie), pliki manifestu jawnie określają wartość dla każdego rozmiaru ekranu. To oszczędność problemów – na przykład plik manifestu z docelowym pakietem SDK < 9 będzie mieć bardzo duże automatycznie ma wartość Fałsz, ponieważ taki rozmiar jeszcze nie istniał. Pisz dosłownie!
Przejrzyj listę kontrolną przed opublikowaniem
Zanim prześlesz pliki do Google Play, dokładnie sprawdź te elementy. Pamiętaj, że są to w odniesieniu do wielu plików APK i w żaden sposób nie stanowią pełnej listy kontrolnej dla wszystkich 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 nakładają się na wersje platformy, plik z wyższą wartością parametru minSdkVersion musi mieć parametr wyższy kod wersji.
- Dla każdego rozmiaru ekranu, który ma obsługiwać plik APK, w pliku manifestu ustaw wartość „true”. Każdy rozmiar ekranu ma unikać, ustaw wartość false (fałsz).
- Dokładnie sprawdź filtry manifestu pod kątem sprzecznych informacji (plik APK, który obsługuje tylko babeczki na ekranach XLARGE nikt nie zobaczy)
- Każdy plik manifestu musi być unikalny w obrębie co najmniej jednego obsługiwanego ekranu, tekstury OpenGL lub wersji platformy.
- Spróbuj przetestować każdy pakiet APK na co najmniej 1 urządzeniu. Oprócz tego jest to jedna z najciekawszych i konfigurowalnych emulatorów urządzeń na komputerze. 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 całkiem proste – „aapt” . Aapt (narzędzie Android Asset Packaging) jest częścią procesu tworzenia aplikacji do systemu Android i jest 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'
Analizując dane wyjściowe narzędzia aapt, upewnij się, że nie występują sprzeczne wartości dla obsługuje ekrany i zgodne ekrany oraz upewnij się, że nie ma w nich niezamierzonego parametru „uses-feature”. wartości dodane w wyniku 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 wymaganych uprawnień SEND_SMS sprawiło, że domyślnie dodaliśmy wymagania dotyczące funkcji android.hardware.telephony. Większość (jeśli nie wszystkie) bardzo duże urządzenia to tablety bez 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 mogły służyć do raportowania jako bardzo duże ekrany, i będą wyposażone w sprzęt telefoniczny.
Na szczęście ten problem można łatwo rozwiązać, dodając ten kod 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 wykonaniu czynności z listy kontrolnej przed opublikowaniem prześlij pliki APK do Google Play. Zanim aplikacja pojawi się w Google Play, może minąć trochę czasu, ale gdy już się pojawi, sprawdź jeszcze raz. Pobierz aplikację na urządzenia testowe, by upewnić się, że pliki APK są kierowane na odpowiednie urządzenia. Gratulacje, to już wszystko!