Tworzenie wielu plików APK o kilku wymiarach

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 wykorzystują przestrzeń dużych ekranów, ale nadal działają na małych, aby korzystać z nowego interfejsu API Androida funkcje czy tekstury wizualne dostępne na najnowszych urządzeniach, ale nie porzucić 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:

• Publikowanie i testowanie są łatwiejsze
• 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, łatwo określić, podyktuj je później. 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.

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 trafiające do projektu bibliotecznego można zaktualizować tylko raz (np. zlokalizowane na różne języki ciągi, motywy kolorystyczne i naprawione błędy we wspólnym kodzie), co pozwala skrócić czas programowania i pomyłki, których można ł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. Na dłuższą metę o wiele łatwiej nią zarządzać, potem kolejny, potem kolejny, kilka miesięcy później próbując ustalić, czy ten blob można przenieść w górę do biblioteki, nie odkręcając czegoś.

Tworzenie nowych projektów APK

Do każdego pliku APK, który zamierzasz opublikować, powinien istnieć oddzielny 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:

Pokrywające się zasięgi mogą się pokrywać, więc możemy opisać obszar objęty każdym plikiem APK w takiej postaci: czyli:

• Niebieski kolor obejmuje wszystkie ekrany, minSDK 3.
• Zielony dotyczy dużych ekranów i wyższych, minSDK 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 niektóre reguły w dużym stopniu 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. Zostanie wtedy Czerwony jest kompatybilny nie tylko z bardzo dużymi urządzeniami, ale nie ma znaczenia, czy jest aparat przedni! 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 obsługiwanych ekranów lub tagu zgodnych ekranów. Ogólnie preferujemy ekrany, ale ogólnie nie jest to dobrze koncepcja obu rozwiązań – komplikuje to niepotrzebnie i zwiększa ryzyko popełnienia 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. Zaszalej!

Warto też sprawdzić skompilowany plik APK przed jego wprowadzeniem na rynek, by mieć pewność, że nie zawiera żadnych niespodzianki, które mogą spowodować ukrycie 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 urządzeń, a nawet wszystkich.

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" />

Bezpośrednio dodaliśmy też wymaganie android.hardware.touchscreen. Jeśli chcesz, aby Twój pakiet APK był widoczny na telewizorach, które nie mają ekranu dotykowego, do pliku manifestu dodaj te elementy:

<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!