obsługa wielu plików APK,

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.

Obsługa wielu plików APK to funkcja Google Play, która umożliwia publikowanie różnych plików APK dla aplikacji, z których każdy jest kierowany na inną konfigurację urządzenia. Każdy plik APK jest kompletną i niezależną wersją aplikacji, ale wszystkie mają tę samą stronę aplikacji w Google Play i muszą mieć tę samą nazwę pakietu oraz być podpisane tym samym kluczem wersji. Ta funkcja jest przydatna w przypadku, gdy aplikacja nie może dotrzeć do wszystkich odpowiednich urządzeń za pomocą jednego pliku APK.

Urządzenia z Androidem mogą się różnić pod wieloma względami, a dla sukcesu aplikacji ważne jest, aby była ona dostępna na jak największej liczbie urządzeń. Aplikacje na Androida zwykle działają na większości zgodnych urządzeń z jednym plikiem APK, który zawiera alternatywne zasoby dla różnych konfiguracji (np. różne układy dla różnych rozmiarów ekranu). System Android wybiera odpowiednie zasoby dla urządzenia w czasie wykonywania. W niektórych przypadkach jeden plik APK nie może obsługiwać wszystkich konfiguracji urządzeń, ponieważ alternatywne zasoby powodują, że plik APK jest zbyt duży, lub inne problemy techniczne uniemożliwiają jego działanie na wszystkich urządzeniach.

Aby ułatwić Ci publikowanie aplikacji na jak największej liczbie urządzeń, Google Play umożliwia publikowanie wielu plików APK w ramach tej samej strony aplikacji. Następnie Google Play dostarcza pliki APK na odpowiednie urządzenia na podstawie obsługi konfiguracji zadeklarowanej w pliku manifestu każdego pliku APK.

Publikując aplikację za pomocą wielu plików APK, możesz:

• obsługa różnych formatów kompresji tekstur OpenGL w ramach każdego pliku APK;
• Obsługa różnych rozmiarów i gęstości ekranu w każdym pliku APK.
• Obsługa różnych zestawów funkcji urządzenia w ramach każdego pliku APK.
• Obsługa różnych wersji platformy w ramach każdego pliku APK.
• Obsługa różnych architektur procesora w poszczególnych plikach APK (np. ARM lub x86, gdy aplikacja korzysta z NDK Androida).
• Optymalizacja na potrzeby urządzeń podstawowej klasy, takich jak urządzenia z Androidem (wersja Go).

Obecnie są to jedyne cechy urządzenia, które Google Play obsługuje w przypadku publikowania wielu plików APK jako tej samej aplikacji.

Uwaga: aby dowiedzieć się więcej o przygotowywaniu i publikowaniu plików APK w Google Play, przeczytaj artykuł pomocy Przygotowywanie i wdrażanie wersji.

Jak działają liczne pliki APK

Koncepcja używania wielu plików APK w Google Play polega na tym, że w Google Play masz tylko 1 element dotyczący aplikacji, ale różne urządzenia mogą pobierać różne pliki APK. Oznacza to, że:

• Utrzymujesz tylko 1 zestaw informacji o produkcie (opis aplikacji, ikony, zrzuty ekranu itp.). Oznacza to też, że nie możesz pobierać różnych cen za różne pliki APK.
• Wszyscy użytkownicy widzą tylko jedną wersję aplikacji w Google Play, więc nie będą wiedzieć, że opublikowałeś różne wersje „na tablety” lub „na telefony”.
• Wszystkie recenzje użytkowników są stosowane do tej samej strony aplikacji, mimo że użytkownicy na różnych urządzeniach mogą mieć różne pliki APK.
• Jeśli opublikujesz różne pliki APK na różne wersje Androida (dla różnych poziomów interfejsu API), gdy użytkownik zaktualizuje system, co kwalifikuje go do korzystania z innego opublikowanego przez Ciebie pliku APK, Google Play zaktualizuje aplikację na plik APK przeznaczony dla nowszej wersji Androida. Wszystkie dane systemowe powiązane z aplikacją są zachowywane (tak samo jak w przypadku zwykłych aktualizacji aplikacji przy użyciu pojedynczego pliku APK).

Obsługiwane filtry

Które urządzenia otrzymują dany plik APK, zależy od filtrów Google Play określonych przez elementy w pliku manifestu każdego pliku APK. Google Play pozwala jednak publikować wiele plików APK tylko wtedy, gdy każdy z nich używa filtrów, aby obsługiwać różne wartości tych cech urządzenia:

• Formaty kompresji tekstur OpenGL

  Jest to zależne od elementów <supports-gl-texture> w pliku manifestu.

  Podczas tworzenia gry korzystającej z OpenGL ES możesz na przykład udostępnić jeden plik APK dla urządzeń obsługujących kompresję tekstur ATI i oddzielny plik APK dla urządzeń obsługujących kompresję PowerVR (oraz wiele innych).

• Rozmiar ekranu (i opcjonalnie gęstość ekranu)

  Jest ona określana na podstawie elementu <supports-screens> lub <compatible-screens>w pliku manifestu. Nigdy nie należy używać obu elementów. W miarę możliwości należy używać tylko elementu <supports-screens>.

  Możesz na przykład przesłać jeden plik APK obsługujący małe i normalne ekrany oraz inny plik APK obsługujący ekrany duże i bardzo duże. Więcej informacji o generowaniu oddzielnych plików APK na podstawie rozmiaru lub gęstości ekranu znajdziesz w artykule Tworzenie wielu plików APK.

  Aby zapewnić obsługę wszystkich rozmiarów ekranów, zastosuj te sprawdzone metody:

  • System Android zapewnia aplikacjom dużą pomoc w obsługiwaniu wszystkich konfiguracji ekranu za pomocą jednego pliku APK. Unikaj tworzenia wielu plików APK na potrzeby obsługi różnych ekranów, chyba że jest to absolutnie konieczne. Zamiast tego postępuj zgodnie z instrukcjami dotyczącymi obsługi wielu ekranów, aby Twoja aplikacja była elastyczna i mogła dostosować się do wszystkich konfiguracji ekranów za pomocą jednego pliku APK.
  • Domyślnie wszystkie atrybuty rozmiaru ekranu w elemencie <supports-screens> mają wartość „true”, jeśli nie określisz ich inaczej. Jednak ponieważ atrybut android:xlargeScreens został dodany w Androidzie 2.3 (poziom interfejsu API 9), Google Play uzna go za „fałszywy”, jeśli aplikacja nie ustawi android:minSdkVersion ani android:targetSdkVersion na „9” lub wyższy.
  • W pliku manifestu nie należy łączyć elementów <supports-screens> i  <compatible-screens>. Korzystanie z obu zwiększa ryzyko wystąpienia błędu z powodu konfliktów między nimi. Aby dowiedzieć się, którego z nich użyć, przeczytaj artykuł Rozpowszechnianie treści na konkretnych ekranach. Jeśli nie możesz uniknąć korzystania z obu, pamiętaj, że w przypadku konfliktu w porozumieniu danego rozmiaru zwycięży wartość „false”.

• Zestawy funkcji urządzenia

  Jest ona określana na podstawie elementów <uses-feature> w pliku manifestu.

  Możesz na przykład udostępnić jeden plik APK dla urządzeń obsługujących wielodotykowe przesuwanie, a inny dla urządzeń, które nie obsługują tej funkcji. Listę funkcji obsługiwanych przez platformę znajdziesz w tabeli referencyjnej funkcji.

• Android (wersja Go)

  Aby kierować aplikację na urządzenia z Androidem (wersja Go), musisz w pliku APK zadeklarować:<uses-feature android:name="android.hardware.ram.low" android:required="true">, kierowanie na co najmniej poziom interfejsu API 26 oraz mieć wyższy kod wersji niż w pliku APK bez wersji Go.

• Poziom interfejsu API

  Jest ona określana na podstawie elementu <uses-sdk> w pliku manifestu. Aby określić obsługę różnych poziomów interfejsu API, możesz użyć atrybutów android:minSdkVersion i android:maxSdkVersion.

  Możesz na przykład opublikować aplikację w jednym pliku APK obsługującym poziomy interfejsu API 16–19 (Android 4.1.x–4.4.4) – korzystając tylko z interfejsów API dostępnych od poziomu 16 lub niższego – oraz w drugim pliku APK obsługującym poziomy interfejsu API 21 i wyższe (Android 5.0 i nowsze) – korzystając tylko z interfejsów API dostępnych od poziomu 21 lub niższego. Aby dowiedzieć się, jak tworzyć oddzielne pliki APK, które będą kierowane na różne interfejsy API, przeczytaj artykuł Konfigurowanie wersji produktu.

  Jeśli używasz tej cechy jako czynnika do odróżniania wielu plików APK, plik APK o wyższej wartości atrybutu android:minSdkVersion musi mieć wyższą wartość atrybutu android:versionCode. Podobnie jest w przypadku, gdy 2 pliki APK pokrywają się pod względem obsługiwanych urządzeń na podstawie różnych obsługiwanych filtrów. Dzięki temu, gdy urządzenie otrzyma aktualizację systemu, Google Play będzie mogło zaoferować użytkownikowi aktualizację aplikacji (ponieważ aktualizacje są oparte na zwiększeniu kodu wersji aplikacji). To wymaganie zostało opisane w sekcji Reguły dotyczące wielu plików APK.

  Unikaj używania interfejsu android:maxSdkVersion, ponieważ jeśli aplikacja została prawidłowo opracowana przy użyciu publicznych interfejsów API, to zawsze będzie zgodna z przyszłościowymi wersjami Androida. Jeśli chcesz opublikować inny plik APK na wyższy poziom interfejsu API, nadal nie musisz określać maksymalnej wersji, ponieważ jeśli w jednym pliku APK wartość android:minSdkVersion wynosi "16", a w drugim "21", urządzenia obsługujące interfejs API na poziomie 21 lub wyższym zawsze będą otrzymywać drugi plik APK (ponieważ jego kod wersji jest wyższy, zgodnie z poprzednią notatką).



• Architektura procesora (ABI)

  Niektóre natywne biblioteki udostępniają osobne pakiety dla określonych architektur procesora lub interfejsów binarnych aplikacji (ABI). Zamiast pakować wszystkie dostępne biblioteki w jeden plik APK, możesz utworzyć osobny plik APK dla każdego ABI i umieścić w nim tylko biblioteki potrzebne w przypadku danego ABI. Więcej informacji o generowaniu oddzielnych plików APK na podstawie docelowego ABI znajdziesz w artykule Tworzenie wielu plików APK.

Inne elementy pliku manifestu, które umożliwiają filtry Google Play, ale nie są wymienione powyżej, są nadal stosowane do każdego pliku APK w zwykły sposób. Google Play nie zezwala jednak na publikowanie osobnych plików APK na podstawie tych cech. Nie możesz opublikować wielu plików APK, jeśli wymienione powyżej filtry są takie same dla każdego pliku APK (ale pliki APK różnią się ze względu na inne cechy w pliku manifestu lub pliku APK). Nie możesz na przykład przesyłać różnych plików APK, które różnią się tylko cechami <uses-configuration>.

Reguły dotyczące wielu plików APK

Zanim opublikujesz kilka plików APK swojej aplikacji, musisz poznać te zasady:

• Wszystkie pliki APK publikowane dla tej samej aplikacji muszą mieć tę samą nazwę pakietu i być podpisane tym samym kluczem certyfikatu.
• Każdy plik APK musi mieć inny kod wersji, określony przez atrybut android:versionCode.
• Każdy plik APK nie musi dokładnie odpowiadać konfiguracji obsługiwanej przez inny plik APK.

  Oznacza to, że każdy plik APK musi deklarować obsługę co najmniej jednego z obsługiwanych filtrów Google Play (wymienionych powyżej).

  Zazwyczaj pliki APK różnią się od siebie na podstawie określonej cechy (np. obsługiwanych formatów kompresji tekstur), więc każdy plik APK będzie deklarować obsługę różnych urządzeń. Można jednak publikować wiele plików APK, które częściowo się pokrywają. Jeśli 2 pliki APK pokrywają się (obsługują te same konfiguracje urządzeń), urządzenie, które mieści się w tym zakresie, otrzyma plik APK z wyższym kodem wersji (zdefiniowanym przez android:versionCode).

• Nie możesz aktywować nowego pliku APK, który ma kod wersji niższy niż plik APK, który zastępuje. Jeśli na przykład masz aktywny plik APK dla rozmiarów ekranu mały – normalny z kodem wersji 0400, spróbuj go zastąpić plikiem APK dla tych samych rozmiarów ekranu z kodem wersji 0300. Powoduje to błąd, ponieważ użytkownicy poprzedniego pliku APK nie będą mogli zaktualizować aplikacji.
• Plik APK, który wymaga wyższego poziomu interfejsu API, musi mieć wyższy kod wersji.

  Jest to możliwe tylko wtedy, gdy pliki APK różnią się tylko na podstawie obsługiwanych poziomów interfejsu API (żadne inne obsługiwane filtry nie odróżniają plików APK od siebie) lub gdy pliki APK używają innego obsługiwanego filtra, ale zachodzą na siebie.

  Jest to ważne, ponieważ urządzenie użytkownika otrzyma aktualizację aplikacji z Google Play tylko wtedy, gdy kod wersji pliku APK w Google Play jest wyższy niż kod wersji pliku APK na urządzeniu. Dzięki temu, jeśli urządzenie otrzyma aktualizację systemu, która umożliwia zainstalowanie pliku APK dla wyższych poziomów interfejsu API, otrzyma ono aktualizację aplikacji, ponieważ kod wersji zostanie zwiększony.

  Uwaga: wielkość zwiększenia kodu wersji jest nieistotna. Musi on być po prostu większy w wersji, która obsługuje wyższe poziomy interfejsu API.

  Oto przykłady:

  • Jeśli przesłany przez Ciebie plik APK przeznaczony dla poziomu interfejsu API 16 lub nowszego (Android 4.1.x lub nowszy) ma kod wersji 0400, plik APK przeznaczony dla poziomu interfejsu API 21 lub nowszego (Android 5.0 lub nowszy) musi mieć kod wersji 0401 lub nowszy. W tym przypadku poziom interfejsu API jest jedynym obsługiwanym filtrem, więc kody wersji muszą się zwiększać w zależności od obsługiwanego poziomu interfejsu API w każdym pliku APK, aby użytkownicy otrzymywali aktualizację po każdej aktualizacji systemu.
  • Jeśli masz jeden plik APK przeznaczony dla poziomu interfejsu API 16 (lub wyższego) i małych i dużych ekranów oraz inny plik APK przeznaczony dla poziomu interfejsu API 21 (lub wyższego) i dużych i bardzo dużych ekranów, kody wersji muszą być coraz wyższe w zależności od poziomu interfejsu API. W tym przypadku do rozróżniania poszczególnych plików APK służy filtr poziomu interfejsu API, ale również rozmiar ekranu. Ponieważ rozmiary ekranów się pokrywają (oba pliki APK obsługują duże ekrany), kody wersji muszą być uporządkowane. Dzięki temu urządzenie z dużym ekranem, które otrzyma aktualizację systemu do poziomu interfejsu API 21, otrzyma aktualizację drugiego pliku APK.
  • Jeśli masz 1 plik APK przeznaczony na poziom interfejsu API 16 (lub wyższy) i małe ekrany oraz inny plik APK przeznaczony na poziom interfejsu API 21 (lub wyższy) i duże ekrany – xlarge, kody wersji nie muszą być zwiększane w zależności od poziomów interfejsu API. Ponieważ filtr rozmiaru ekranu nie zawiera żadnych nakładających się wartości, nie ma urządzeń, które mogłyby przełączać się między tymi plikami APK, więc nie ma potrzeby zwiększania kodu wersji z niższego poziomu interfejsu API do wyższego.
  • Jeśli masz jeden plik APK przeznaczony dla procesorów ARMv7 i wyższych na poziomie interfejsu API 16 (i wyższym) oraz inny plik APK przeznaczony dla procesorów ARMv5TE i wyższych na poziomie interfejsu API 21 (i wyższym), kody wersji muszą być coraz wyższe w zależności od poziomu interfejsu API. W tym przypadku do rozróżniania poszczególnych plików APK służy filtr poziomu interfejsu API, ale także architektura procesora. Plik APK z bibliotekami ARMv5TE jest zgodny z urządzeniami z procesorem ARMv7, więc pliki APK pokrywają się pod tym względem. W związku z tym kod wersji pliku APK obsługującego poziom interfejsu API 21 lub nowszy musi być wyższy. Dzięki temu urządzenie z procesorem ARMv7, które otrzyma aktualizację systemu do poziomu interfejsu API 21, otrzyma aktualizację drugiego pakietu APK, który jest przeznaczony dla poziomu interfejsu API 21. Jednak ponieważ tego typu aktualizacja powoduje, że na urządzeniu z procesorem ARMv7 używany jest plik APK, który nie jest w pełni zoptymalizowany pod kątem procesora, należy udostępnić plik APK dla architektury ARMv5TE i ARMv7 na każdym poziomie interfejsu API, aby zoptymalizować wydajność aplikacji na każdym procesorze. Uwaga: dotyczy to tylko porównywania plików APK z bibliotekami ARMv5TE i ARMv7, a nie innych natywnych bibliotek.

Nieprzestrzeganie powyższych zasad spowoduje błąd w Konsoli Google Play podczas aktywowania plików APK. Dopóki nie rozwiążesz problemu, nie będzie można opublikować aplikacji.

Podczas aktywowania plików APK mogą wystąpić inne konflikty, które spowodują wyświetlenie ostrzeżeń, a nie błędów. Ostrzeżenia mogą być spowodowane przez:

• Gdy zmodyfikujesz plik APK, aby „zredukować” obsługę cech urządzenia, żadne inne pliki APK nie będą obsługiwać urządzeń, które nie mieszczą się w obsługiwanym zakresie. Jeśli na przykład pakiet APK obsługuje obecnie ekrany o małym i normalnym rozmiarze, a zmienisz go tak, aby obsługiwał tylko ekrany o małym rozmiarze, zmniejszysz pulę obsługiwanych urządzeń i niektóre z nich nie będą już widzieć Twojej aplikacji w Google Play. Możesz rozwiązać ten problem, dodając kolejny plik APK, który obsługuje ekrany o normalnym rozmiarze, aby wszystkie wcześniej obsługiwane urządzenia nadal były obsługiwane.
• Gdy występują „nakładania się” między co najmniej 2 plikami APK. Jeśli na przykład jeden plik APK obsługuje rozmiary ekranu mały, normalny i duży, a inny plik APK obsługuje rozmiary duży i bardzo duży, występuje nakładanie się, ponieważ oba pliki APK obsługują duże ekrany. Jeśli tego nie zrobisz, urządzenia kwalifikujące się do obu plików APK (w tym przykładzie urządzenia z dużym ekranem) otrzymają plik APK z najwyższym kodem wersji.

  Uwaga: jeśli tworzysz osobne pliki APK na potrzeby różnych architektur procesora, pamiętaj, że plik APK dla ARMv5TE będzie się pokrywać z plikiem APK dla ARMv7. Oznacza to, że plik APK przeznaczony dla ARMv5TE jest zgodny z urządzeniem ARMv7, ale odwrotna sytuacja nie ma miejsca (plik APK zawierający tylko biblioteki ARMv7 jest niezgodny z urządzeniem ARMv5TE).

W takich przypadkach pojawi się ostrzeżenie, ale nadal możesz opublikować aplikację.

Tworzenie wielu plików APK

Jeśli zdecydujesz się opublikować kilka plików APK, prawdopodobnie musisz utworzyć oddzielne projekty Androida dla każdego pliku APK, który chcesz opublikować, aby móc je odpowiednio opracować osobno. Aby to zrobić, po prostu zduplikuj istniejący projekt i nadaj mu nową nazwę. (Możesz też użyć systemu kompilacji, który może generować różne zasoby, np. tekstury, na podstawie konfiguracji kompilacji).

Wskazówka: aby uniknąć duplikowania dużych fragmentów kodu aplikacji, możesz użyć projektu biblioteki. Projekt biblioteki zawiera wspólny kod i zasoby, które możesz uwzględnić w projektach aplikacji.

Podczas tworzenia wielu projektów dla tej samej aplikacji warto nadać każdemu z nich nazwę, która wskazuje na ograniczenia dotyczące urządzenia, na którym ma być zainstalowany plik APK. Dzięki temu łatwiej je rozróżnić. Na przykład „HelloWorld_21” może być dobrą nazwą dla aplikacji przeznaczonej na poziom API 21 lub wyższy.

Uwaga: wszystkie pliki APK opublikowane dla tej samej aplikacji muszą mieć tę samą nazwę pakietu i być podpisane tym samym kluczem certyfikatu. Zapoznaj się też ze wszystkimi regułami dotyczącymi wielu pakietów APK.

Przypisywanie kodów wersji

Każdy plik APK tej samej aplikacji musi mieć unikalny kod wersji, określony przez atrybut android:versionCode. Podczas publikowania wielu plików APK należy z uwagą przydzielać im kody wersji, ponieważ muszą być one różne, ale w niektórych przypadkach muszą być zdefiniowane w określonej kolejności, zależnie od konfiguracji, którą obsługuje dany plik APK.

Sortowanie według kodów wersji

Plik APK, który wymaga wyższego poziomu interfejsu API, musi mieć wyższy kod wersji. Jeśli na przykład utworzysz 2 pliki APK, aby obsługiwać różne poziomy interfejsu API, plik APK dla wyższych poziomów interfejsu API musi mieć wyższy kod wersji. Dzięki temu jeśli urządzenie otrzyma aktualizację systemu, która pozwoli na zainstalowanie pakietu APK dla wyższych poziomów interfejsu API, użytkownik otrzyma powiadomienie o konieczności zaktualizowania aplikacji. Więcej informacji o tym wymaganiu znajdziesz w sekcji Zasady dotyczące wielu plików APK.

Zastanów się też, jak kolejność kodów wersji może wpływać na to, który plik APK otrzymają użytkownicy. Może to być spowodowane nakładaniem się zakresów różnych plików APK lub przyszłymi zmianami, które wprowadzisz w plikach APK.

Jeśli na przykład masz różne pliki APK na podstawie rozmiaru ekranu, np. jeden dla małego i normalnego oraz jeden dla dużego i bardzo dużego, ale przewidujesz, że w przyszłości zmienisz pliki APK na jeden dla małego i normalnego oraz jeden dla normalnego i bardzo dużego, powinieneś zwiększyć kod wersji pliku APK dla dużego i bardzo dużego. W ten sposób po wprowadzeniu zmiany urządzenie o normalnym rozmiarze otrzyma odpowiednie uaktualnienie, ponieważ kod wersji dotychczasowego pliku APK zostanie zastąpiony kodem nowego pliku APK, który obsługuje to urządzenie.

Pamiętaj też, że podczas tworzenia wielu plików APK, które różnią się obsługą różnych formatów kompresji tekstur OpenGL, należy pamiętać, że wiele urządzeń obsługuje wiele formatów. Ponieważ w przypadku pokrywających się zakresów dwóch plików APK urządzenie otrzymuje plik APK z najwyższym kodem wersji, należy uporządkować kody wersji plików APK tak, aby plik APK z preferowanym formatem kompresji miał najwyższy kod wersji. Możesz na przykład utworzyć oddzielne wersje aplikacji korzystające z formatów kompresji PVRTC, ATITC i ETC1. Jeśli wolisz te formaty w takim właśnie porządku, plik APK, który używa formatu PVRTC, powinien mieć najwyższy kod wersji, plik APK, który używa formatu ATITC, powinien mieć kod wersji niższej, a wersja z formatem ETC1 – najniższy. Jeśli więc urządzenie obsługuje zarówno formaty PVRTC, jak i ETC1, otrzyma plik APK z formatem PVRTC, ponieważ ma najwyższy kod wersji.

Jeśli Sklep Google Play nie może zidentyfikować odpowiedniego pliku APK do zainstalowania na urządzeniu docelowym, możesz też utworzyć uniwersalny plik APK, który zawiera zasoby dla wszystkich różnych wersji urządzenia, które chcesz obsługiwać. Jeśli udostępnisz uniwersalny plik APK, przypisz mu najniższy priorytet versionCode. Sklep Google Play instaluje wersję aplikacji, która jest zgodna z urządzeniem docelowym i ma najwyższą wartość versionCode. Przypisanie niższej wartości versionCode do uniwersalnego pliku APK powoduje, że Sklep Google Play próbuje zainstalować jeden z innych plików APK, zanim sięgnie po większy uniwersalny plik APK.

Używanie schematu kodu wersji

Aby umożliwić aktualizowanie kodów wersji w różnych plikach APK niezależnie od siebie (np. gdy naprawiasz błąd tylko w jednym pliku APK, więc nie musisz aktualizować wszystkich plików APK), użyj schematu kodów wersji, który zapewnia wystarczającą ilość miejsca między każdym plikiem APK, aby można było zwiększyć kod w jednym pliku bez konieczności zwiększania go w innych. W kodzie musisz też podać rzeczywistą nazwę wersji (czyli widoczną dla użytkownika wersję przypisaną do android:versionName), aby można było łatwo powiązać kod i nazwę wersji.

Uwaga: gdy zwiększysz kod wersji pliku APK, Google Play poprosi użytkowników poprzedniej wersji o zaktualizowanie aplikacji. Aby uniknąć zbędnych aktualizacji, nie zwiększaj kodu wersji plików APK, które nie zawierają żadnych zmian.

Zalecamy użycie kodu wersji zawierającego co najmniej 7 cyfr: liczby całkowite reprezentujące obsługiwane konfiguracje znajdują się w bitach o większej mocy, a nazwa wersji (z android:versionName) – w bitach o mniejszej mocy. Jeśli np. nazwa wersji aplikacji to 3.1.0, kody wersji pliku APK na poziomie interfejsu API 4 i 11 będą wyglądać odpowiednio na przykład jak 0400310 i 1100310. Pierwsze 2 cyfry są zarezerwowane na poziom interfejsu API (odpowiednio 4 i 11), 2 cyfry w środku na rozmiary ekranu lub formaty tekstur GL (nieużywane w tych przykładach), a 3 ostatnie cyfry na nazwę wersji aplikacji (3.1.0). Rysunek 1 przedstawia 2 przykłady, które dzielą się na podstawie wersji platformy (poziom interfejsu API) i rozmiaru ekranu.

Rysunek 1. Sugerowany schemat kodów wersji, w którym pierwsze 2 cyfry oznaczają poziom interfejsu API, 3 i 4 cyfry – minimalny i maksymalny rozmiar ekranu (1–4 oznaczają każdy z 4 rozmiary) lub formaty tekstur, a 3 ostatnie cyfry – wersję aplikacji.

Ten schemat kodów wersji to tylko sugestia dotycząca sposobu tworzenia wzoru, który można skalować wraz z rozwojem aplikacji. Schemat ten nie pokazuje w szczególności rozwiązania umożliwiającego identyfikację różnych formatów kompresji tekstur. Jedną z możliwości jest zdefiniowanie własnej tabeli, która określa inną liczbę całkowitą dla każdego z formatów kompresji obsługiwanych przez aplikację (np. 1 może odpowiadać ETC1, a 2 – ATITC itd.).

Możesz użyć dowolnego schematu, ale musisz dokładnie przemyśleć, jak przyszłe wersje aplikacji będą musiały zwiększać swoje kody wersji i jak urządzenia będą otrzymywać aktualizacje, gdy zmieni się konfiguracja urządzenia (np. z powodu aktualizacji systemu) lub gdy zmodyfikujesz obsługę konfiguracji w przypadku jednego lub kilku plików APK.