Tworzenie wielu plików APK dla różnych poziomów interfejsu API

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 a każdy z nich obsługuje nieco inny zakres poziomów API. Zyskasz też dostęp do narzędzi, niezbędne do jak najszybszego utrzymywania bazy kodu z większą liczbą plików APK.

Potwierdź, że potrzebujesz wielu plików APK

Kiedy próbujesz stworzyć aplikację, która działa na różnych generacjach Androida, jest bardzo ważne, jest naturalne, że chcesz, aby aplikacja wykorzystywała nowe funkcje na nowych urządzeniach, bez poświęcania zgodności wstecznej. Na początku może się wydawać, że wiele plików APK pomoc jest najlepszym rozwiązaniem, ale nie zawsze. Korzystanie z pojedynczego pliku APK Zamiast tego w przewodniku dla programistów korzystających z wielu plików APK znajdziesz informacje o tym, aby to zrobić, korzystając z pojedynczego pakietu APK, również z naszej biblioteki pomocy. Warto też dowiedzieć się, jak: napisać w jednym pliku APK kod, który działa tylko na określonych poziomach interfejsu API, bez uciekania się drogie obliczeniowo techniki, takie jak odbicie z ten artykuł.

Jeśli możesz zarządzać aplikacją, ograniczenie aplikacji do jednego pliku APK wiąże się korzyści, 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 jakiego interfejsu API potrzebujesz. zakres obejmujący każdy plik APK. Przydatne informacje znajdziesz na stronie Wersje platformy w Witryna dla deweloperów aplikacji na Androida zawiera dane o względnej liczbie aktywnych urządzeń, na których działa dany wersji platformy Androida. Choć na pierwszy rzut oka wydaje się łatwe, śledzenie tego, który zestaw poziomów interfejsu API, na które kierowany jest każdy plik APK, staje się dość szybko trudne, zwłaszcza jeśli do pewnego stopnia nakładania się (często się zdarza). Na szczęście możesz szybko określić swoje wymagania z łatwością dostępnymi w późniejszym terminie.

Aby utworzyć wykres z wieloma pakietami APK, zacznij od wiersza komórek reprezentujących interfejsów API na różnych poziomach na platformie Android. Dorzuć na końcu dodatkową komórkę, która odzwierciedla przyszłość wersji Androida.

3 4 5 6 7 8 9 10 11 12 13 +

Teraz po prostu pokoloruj wykres, tak aby każdy kolor odpowiadał jednemu plikowi APK. Oto przykład, możesz zastosować każdy plik APK na określonym zakresie poziomów API.

3 4 5 6 7 8 9 10 11 12 13 +

Gdy utworzysz ten wykres, przekaż go swojemu zespołowi. Komunikacja zespołu dotycząca projektu od razu stało się to prostsze, ponieważ zamiast pytać „Jaki jest interfejs API dla poziomów 3–6? Android 1.x. Co słychać?” Wystarczy, że powiesz „Jak będzie wyglądać niebieski plik APK? razem?”

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

Przyjmijmy na przykład zestaw wielu opisanych wcześniej plików APK i zakładamy, że nie ustawić maksymalny poziom interfejsu API dla dowolnego pakietu APK. Rozpatrywane osobno, możliwy zakres każdego pliku APK byłby wygląda 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 +

Plik APK z większą wartością parametru minSdkVersion musi mieć również tag wyższy kod wersji, wiemy, że w przypadku wartości versionCode czerwony ≥ zielony ≥ niebieski. Dzięki temu wykres może wyglądać tak:

3 4 5 6 7 8 9 10 11 12 13 +

Przyjmijmy teraz, że czerwony pakiet APK ma pewne wymagania, których nie spełniają pozostałe 2 opcje. Na stronie Filtry w Google Play w przewodniku dla programistów aplikacji na Androida znajdziesz pełną listę potencjalnych infekcji. W przypadku atrybutu Załóżmy na przykład, że kolor czerwony wymaga użycia przedniego aparatu. Ogólnie rzecz biorąc, czerwony plik APK to połączenie przedniego aparatu ze słodkimi nowymi funkcjami dodanymi w interfejsie API. 11. Okazuje się jednak, że nie wszystkie urządzenia obsługujące interfejs API 11 mają przednie aparaty. horror!

Na szczęście, jeśli użytkownik przegląda Google Play na takim urządzeniu, pliku manifestu, czerwony wymieniony jest przedni aparat jako wymóg i dyskretnie go zignoruj, stwierdził, że Red z tym urządzeniem nie pasuje do cyfrowego nieba. Następnie zobaczy, że Zielony jest nie tylko zgodny z urządzeniami z interfejsem API 11 (ponieważ nie zdefiniowano parametru maxSdkVersion), ale nie ma znaczenia, czy jest tu przedni aparat. Nadal możesz pobrać tę aplikację przez użytkownika z Google Play, ponieważ mimo wadliwego przedniego aparatu Plik APK, który obsługiwał dany 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. Przykładowy zestaw plików APK obsługuje tylko jedną z trzech możliwych wymiarów, wystarczy podzielić każdy plik APK o 1000, ustaw kilka pierwszych cyfr na minSdkVersion dla konkretnego pliku APK i zwiększa go od tego poziomu. Może to wyglądać tak:

Niebieski: 03001, 03002, 03003, 03004...
Zielony: 07001, 07002, 07003, 07004...
Czerwony:11001, 11002, 11003, 11004...

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

Przejrzyj listę kontrolną przed opublikowaniem

Zanim prześlesz pliki do Google Play, dokładnie sprawdź te elementy. Pamiętaj, że dotyczą one 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 wersje plików APK nakładają się na siebie w wersji platformy, ten z większą wartością parametru minSdkVersion musi mieć wyższy kod wersji
  • 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 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. Oprócz tego na komputerze używanym do programowania jest jeden z najbardziej konfigurowalnych emulatorów urządzeń w firmie. 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: 'small' 'normal' 'large' '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 nie będą widoczne dla wielu urządzeń.

Dlaczego? Dodanie wymaganych uprawnień SEND_SMS sprawiło, że domyślnie dodaliśmy wymagania dotyczące funkcji android.hardware.telephony. Interfejs API 11 to Honeycomb (wersja Androida zoptymalizowana specjalnie pod kątem tabletów) i żadne urządzenia Honeycomb nie mają w nich żadnych elementów sprzętowych. Google Play będzie za każdym razem odfiltrowywać ten plik APK, dopóki nie pojawią się nowe urządzenia z wyższym poziomem interfejsu API ORAZ ze sprzętem do obsługi telefonicznej.

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 wszystkie używane urządzenia testowe, aby upewnić się, że pliki APK są kierowane na odpowiednie urządzenia. Gratulacje, to już wszystko!