obsługa wielu plików APK,

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

Obsługa wielu plików APK to funkcja w Google Play, która umożliwia publikowanie różnych plików APK aplikacji, z których każdy jest dostosowany do urządzeń o odmiennych konfiguracjach. Każdy plik APK to pełna i niezależna wersja Twojej aplikacji. Jednak każda z nich ma tę samą stronę w Google Play i musi mieć tę samą nazwę pakietu oraz być podpisanym tym samym kluczem wersji. Ta funkcja jest przydatna w przypadkach, gdy aplikacja nie może dotrzeć do wszystkich urządzeń z jednym plikiem APK.

Urządzenia z Androidem mogą się różnić pod wieloma względami, dlatego dla powodzenia aplikacji ważne jest, aby udostępnić ją na jak największej liczbie urządzeń. Aplikacje na Androida działają zwykle na większości zgodnych urządzeń z jednym plikiem APK. Zapewniają alternatywne zasoby dla różnych konfiguracji (np. różne układy dla różnych rozmiarów ekranu), a system Android w czasie działania wybiera odpowiednie zasoby dla urządzenia. Jednak tylko w niektórych przypadkach pojedynczy plik APK może nie być obsługiwany we wszystkich konfiguracjach urządzeń, bo alternatywne zasoby sprawiają, że plik APK jest za duży lub inne problemy techniczne uniemożliwiają jego działanie na wszystkich urządzeniach.

Aby ułatwić Ci opublikowanie aplikacji na jak najwięcej urządzeń, Google Play umożliwia opublikowanie wielu plików APK w ramach jednej strony aplikacji. Następnie Google Play dostarcza każdy pakiet APK odpowiednim urządzeniom zgodnie z obsługą konfiguracji zadeklarowaną w pliku manifestu każdego pakietu APK.

Publikując aplikację z wieloma pakietami APK, możesz:

• Obsługuj różne formaty kompresji tekstur OpenGL w przypadku każdego pliku APK.
• Każdy plik APK obsługuje różne rozmiary i gęstości ekranu.
• obsługują różne zestawy funkcji urządzenia z poszczególnymi plikami APK.
• obsługują różne wersje platformy z każdym plikiem APK.
• Każdy plik APK obsługuje różne architektury procesora (np. dla ARM lub x86, gdy aplikacja używa pakietu NDK na Androida).
• Optymalizacja pod kątem podstawowych urządzeń, takich jak urządzenia z Androidem (wersja Go).

Obecnie Google Play obsługuje tylko te cechy urządzenia, na których można publikować wiele plików APK w ramach tej samej aplikacji.

Uwaga: więcej informacji o przygotowywaniu i publikowaniu plików APK w Google Play znajdziesz w artykule pomocy na temat przygotowywania i wdrażania wersji.

Jak działa wiele pakietów APK

Koncepcja korzystania z wielu plików APK w Google Play polega na tym, że w Google Play jest dostępny tylko jeden wpis aplikacji, ale różne urządzenia mogą pobierać inne pliki APK. Oznacza to, że:

• Masz tylko jeden zestaw szczegółów produktu (opis aplikacji, ikony, zrzuty ekranu itp.). Oznacza to również, że nie możesz naliczać innej ceny za różne pliki APK.
• Wszyscy użytkownicy widzą w Google Play tylko jedną wersję aplikacji. Dlatego nie są mylone różnej opublikowanej wersji aplikacji przeznaczonej na tablety lub telefony.
• Wszystkie opinie użytkowników są stosowane do tych samych informacji o aplikacji, mimo że użytkownicy różnych urządzeń mogą mieć różne pliki APK.
• Jeśli opublikujesz różne pliki APK dla różnych wersji Androida (dla różnych poziomów interfejsu API), a potem gdy urządzenie użytkownika otrzyma aktualizację systemu, która będzie je kwalifikować do innego opublikowanego przez Ciebie pliku APK, Google Play zaktualizuje aplikację użytkownika do pliku APK zaprojektowanego pod kątem wyższej wersji Androida. Wszystkie dane systemowe powiązane z aplikacją są zachowywane (tak samo jak w przypadku zwykłych aktualizacji aplikacji w przypadku pojedynczego pliku APK).

Obsługiwane filtry

Urządzenia odbierające dany pakiet APK są określane przez filtry Google Play określone przez elementy w pliku manifestu każdego pakietu APK. Google Play zezwala jednak na publikowanie wielu plików APK tylko wtedy, gdy każdy z nich używa filtrów do obsługi tych parametrów urządzenia:

• Formaty kompresji tekstur OpenGL

  Są one oparte na elementach <supports-gl-texture> w pliku manifestu.

  Na przykład podczas tworzenia gry obsługującej OpenGL ES możesz udostępnić 1 plik APK dla urządzeń obsługujących kompresję tekstur ATI i osobny dla urządzeń obsługujących kompresję PowerVR.

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

  Zależą one od elementu <supports-screens> lub <compatible-screens> w pliku manifestu. Nigdy nie używaj obu elementów, a w miarę możliwości używaj tylko <supports-screens>.

  Możesz na przykład udostępnić jeden plik APK obsługujący małe i normalne ekrany oraz drugi plik APK, który obsługuje duże i bardzo duże ekrany. Więcej informacji o generowaniu osobnych plików APK na podstawie rozmiaru ekranu lub gęstości ekranu znajdziesz w artykule o tworzeniu wielu plików APK.

  Rozważ zastosowanie tych sprawdzonych metod w przypadku obsługi wszystkich rozmiarów ekranu:

  • System Android zapewnia silną obsługę aplikacji, umożliwiając obsługę wszystkich konfiguracji ekranu za pomocą jednego pliku APK. Jeśli nie jest to absolutnie konieczne, unikaj tworzenia wielu plików APK przeznaczonych do obsługi różnych ekranów. Zamiast tego postępuj zgodnie z przewodnikiem Obsługa wielu ekranów, aby aplikacja była elastyczna i mogła dostosować się do wszystkich konfiguracji ekranów w ramach jednego pliku APK.
  • Domyślnie wszystkie atrybuty rozmiaru ekranu w elemencie <supports-screens> mają wartość „true” (prawda), jeśli nie jest zadeklarowane inaczej. Ponieważ jednak w Androidzie 2.3 (poziom interfejsu API 9) dodano atrybut android:xlargeScreens, Google Play przyjmie, że ma on wartość „false” (fałsz), jeśli aplikacja nie ustawi wartości android:minSdkVersion albo android:targetSdkVersion na „9” lub wyższą.
  • W pliku manifestu nie należy łączyć elementów <supports-screens> i <compatible-screens>. Użycie obu tych opcji zwiększa prawdopodobieństwo pomyłki z powodu konfliktu między nimi. Aby dowiedzieć się, które z nich mają być używane, przeczytaj artykuł Dystrybucja na określonych ekranach. Jeśli nie możesz uniknąć korzystania z obu tych elementów, pamiętaj, że w przypadku konfliktów w zgodności między danym rozmiarem wygrana jest wartość „false” (fałsz).
• Zestawy funkcji urządzenia

  Są one oparte na elementach <uses-feature> w pliku manifestu.

  Możesz na przykład udostępnić jeden plik APK dla urządzeń obsługujących wielodotyk, a drugi dla urządzeń nieobsługujących tej funkcji. Listę funkcji obsługiwanych przez platformę znajdziesz w dokumentacji funkcji.

• Android (wersja Go)

  Aby można było kierować reklamy na urządzenia z Androidem (wersja Go), pakiet APK musi zadeklarować <uses-feature android:name="android.hardware.ram.low" android:required="true">, kierować na interfejs API na poziomie 26 i mieć wyższy kod wersji niż plik APK z inną wersją niż Go.

• Poziom API

  Zależą one od 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ę z jednym plikiem APK, który obsługuje poziomy API 16–19 (Android 4.1.x–4.4.4) – używając tylko interfejsów API dostępnych od poziomu 16 lub niższego – i drugiego, który obsługuje interfejsy API na poziomie 21 lub wyższym (Android 5.0 i nowsze), z interfejsów API dostępnych od poziomu 21 lub niższego. Aby dowiedzieć się, jak tworzyć osobne pliki APK, z których każdy będzie kierowany na inny zakres interfejsów API, przeczytaj artykuł Konfigurowanie smaków produktów.

  Jeśli używasz tej cechy jako czynnika wpływającego na rozróżnianie wielu plików APK, plik APK z wyższą wartością android:minSdkVersion musi mieć wyższą wartość android:versionCode. Dzieje się tak również wtedy, gdy 2 pakiety APK nakładają się na obsługę urządzeń z powodu innego obsługiwanego filtra. Dzięki temu po otrzymaniu aktualizacji systemu na urządzeniu Google Play może zaproponować użytkownikowi aktualizację aplikacji (ponieważ aktualizacje bazują na zwiększeniu kodu wersji aplikacji). To wymaganie zostało szczegółowo opisane w sekcji poniżej dotyczącej reguł wielu plików APK.

  Ogólnie nie zalecamy używania android:maxSdkVersion, ponieważ aplikacja, w której przypadku zostały użyte publiczne interfejsy API, jest zawsze zgodna z przyszłymi wersjami Androida. Jeśli chcesz opublikować inny plik APK dla wyższych poziomów interfejsów API, i tak nie musisz określać maksymalnej wersji. Jeśli android:minSdkVersion w jednym pliku APK to "16", a "21" w innym, urządzenia obsługujące interfejs API na poziomie 21 lub wyższym zawsze otrzymają drugi plik APK (ponieważ jego kod wersji jest wyższy, jak zaznaczyliśmy w poprzedniej uwag).



• Architektura procesora (ABI)

  Niektóre biblioteki natywne dostarczają 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 interfejsu ABI i uwzględnić tylko te biblioteki, których potrzebujesz. Więcej informacji o generowaniu osobnych plików APK na podstawie docelowego interfejsu ABI znajdziesz w artykule o tworzeniu wielu plików APK.

Inne elementy pliku manifestu, które włączają filtry Google Play, ale nie zostały wymienione powyżej, są nadal stosowane do każdego pakietu APK w zwykły sposób. Google Play nie zezwala jednak na publikowanie osobnych plików APK na podstawie różnych parametrów urządzenia. Nie można więc opublikować wielu plików APK, jeśli wymienione powyżej filtry są takie same dla każdego pliku. Pliki APK różnią się w zależności od innych cech w pliku manifestu lub pliku APK. Nie możesz na przykład udostępniać różnych plików APK, które różnią się tylko cechami <uses-configuration>.

Reguły dotyczące wielu plików APK

Zanim opublikujesz wiele plików APK dla swojej aplikacji, musisz poznać te reguły:

• Wszystkie pliki APK, które publikujesz 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 w atrybucie android:versionCode.
• Żaden plik APK nie może dokładnie odpowiadać konfiguracji innego pliku APK.

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

  Zwykle pliki APK rozróżnia się na podstawie konkretnych cech (takich jak obsługiwane formaty kompresji tekstur), dlatego każdy plik APK deklaruje obsługę różnych urządzeń. Można jednak opublikować wiele plików APK, których obsługa nieznacznie się pokrywa. Gdy 2 pliki APK nakładają się na siebie (obsługują niektóre z tych samych konfiguracji urządzeń), urządzenie, które mieści się w tym zakresie, otrzyma pakiet z wyższym kodem wersji (zdefiniowanym przez android:versionCode).

• Nie możesz aktywować nowego pliku APK o kodzie wersji niższym od kodu, który zastępuje. Załóżmy na przykład, że masz aktywny plik APK przeznaczony na ekrany o rozmiarach „małych” – normalnych z kodem wersji 0400. Następnie spróbuj zastąpić go plikiem APK przeznaczonym na ekrany o tym samym rozmiarze z kodem wersji 0300. Wystąpi błąd, bo 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.

  Dzieje się tak tylko wtedy, gdy: pliki APK różnią się tylko na obsługiwanych poziomach interfejsu API (pozostałe obsługiwane filtry nie odróżniają plików APK) lub gdy pliki APK używają innego obsługiwanego filtra, ale pliki APK w ramach tego filtra pokrywają się.

  To ważne, ponieważ urządzenie użytkownika otrzymuje aktualizację aplikacji z Google Play tylko wtedy, gdy kod wersji pliku APK w Google Play jest wyższy niż kod wersji pliku APK obecnie zainstalowanego na urządzeniu. Dzięki temu, gdy urządzenie otrzyma aktualizację systemu, która następnie zakwalifikuje je do zainstalowania pliku APK na potrzeby wyższych poziomów interfejsu API, otrzyma aktualizację aplikacji, ponieważ zwiększy się kod wersji.

  Uwaga: rozmiar zwiększonego kodu wersji nie ma znaczenia. Należy go po prostu zwiększyć w wersji, która obsługuje wyższe poziomy interfejsu API.

  Oto przykłady:

  • Jeśli przesłany przez Ciebie plik APK dla interfejsu API poziomów 16 i wyższych (Android 4.1.x lub nowszy) ma kod wersji 0400, to pakiet APK przeznaczony na interfejs API na poziomie 21 lub wyższym (Android 5.0 lub nowszy) musi mieć kod wersji 0401 lub nowszej. W tym przypadku jedynym obsługiwanym filtrem jest poziom interfejsu API, więc kody wersji muszą być większe zgodnie z obsługą poziomu interfejsu API w przypadku każdego pliku APK. Dzięki temu użytkownicy otrzymają aktualizację po aktualizacji systemu.
  • Jeśli masz jeden plik APK przeznaczony dla interfejsu API na poziomie 16 (lub wyższym) oraz dla małych i dużych ekranów, a drugi dla interfejsu API poziomu 21 (lub nowszego) i dużych ekranów, kody wersji muszą być coraz większe zgodnie z poziomami interfejsu API. W tym przypadku do rozróżniania poszczególnych plików APK wykorzystywany jest filtr na poziomie interfejsu API, ale podobnie jak rozmiar ekranu. Rozmiary ekranu się pokrywają (oba pliki APK obsługują duże ekrany), więc kody wersji muszą nadal być zgodne. Dzięki temu urządzenie o dużym ekranie, które otrzyma aktualizację systemu do interfejsu API poziomu 21, otrzyma aktualizację drugiego pliku APK.
  • Jeśli masz jeden plik APK przeznaczony dla interfejsu API na poziomie 16 (lub wyższym) oraz dla małych i normalnych ekranów, a drugi dla interfejsu API na poziomie 21 (lub wyższym) i dużych ekranów, nie trzeba zwiększać kodów wersji zgodnie z poziomami interfejsu API. Ponieważ filtr rozmiaru ekranu nie nakłada się na siebie, nie ma urządzeń, które mogłyby zostać przeniesione między tymi dwoma plikami APK. Nie trzeba więc zmieniać kodów wersji z niższego poziomu API na wyższy.
  • Jeśli masz jeden plik APK przeznaczony dla API poziomu 16 (lub nowszego) oraz dla procesorów ARMv7, a drugi dla interfejsów API poziomu 21 (lub nowszego) oraz ARMv5TE, kody wersji muszą się zwiększać zgodnie z poziomami interfejsu API. W tym przypadku do rozróżniania poszczególnych plików APK jest używany filtr na poziomie interfejsu API, ale podobnie jak architektura procesora. Plik APK z bibliotekami ARMv5TE jest zgodny z urządzeniami z procesorem ARMv7, dlatego pliki APK nakładają się na tę cechę. Dlatego kod wersji pliku APK, który obsługuje interfejs API na poziomie 21 lub wyższym, musi być wyższy. Dzięki temu urządzenie z procesorem ARMv7, które otrzyma aktualizację systemu do interfejsu API poziomu 21, otrzyma aktualizację drugiego pliku APK przeznaczonego na interfejs API poziomu 21. W efekcie tego rodzaju aktualizacja powoduje, że urządzenie ARMv7 korzysta z pliku APK, który nie jest w pełni zoptymalizowany pod kątem CPU tego urządzenia, dlatego musisz udostępnić pakiet APK zarówno dla architektury ARMv5TE, jak i ARMv7 na każdym poziomie interfejsu API. Pozwoli to zoptymalizować wydajność aplikacji przez każdy procesor. Uwaga: dotyczy to tylko podczas porównywania plików APK z bibliotekami ARMv5TE i ARMv7, a nie w przypadku porównywania innych bibliotek natywnych.

Nieprzestrzeganie tych reguł po aktywacji plików APK spowoduje wyświetlenie w Konsoli Google Play błędu – nie będziesz mieć możliwości opublikowania aplikacji do czasu naprawienia błędu.

Podczas aktywacji plików APK mogą wystąpić inne konflikty, które raczej powodują wyświetlanie ostrzeżeń, a nie błędów. Ostrzeżenia mogą mieć następujące przyczyny:

• Jeśli zmodyfikujesz plik APK, by „zmniejszyć” obsługę określonych parametrów urządzenia, a żadne inne pliki APK nie będą obsługiwać urządzeń spoza obsługiwanego zakresu. Jeśli na przykład plik APK obsługuje obecnie małe i normalne ekrany, a Ty zmienisz go tak, aby obsługiwał tylko małe ekrany, liczba obsługiwanych urządzeń zmniejszyła się i na niektórych urządzeniach Twoja aplikacja nie będzie już widoczna w Google Play. Możesz rozwiązać ten problem, dodając kolejny plik APK, który obsługuje ekrany o normalnym rozmiarze. Dzięki temu wszystkie obsługiwane wcześniej urządzenia będą nadal obsługiwane.
• Między co najmniej 2 plikami APK występują „nakładające się” sytuacje. Jeśli na przykład jeden plik APK obsługuje małe, normalne i duże rozmiary ekranów, a drugi – duże i bardzo duże, elementy nakładają się, ponieważ oba pliki APK obsługują duże ekrany. Jeśli tego nie zrobisz, urządzenia, które kwalifikują się do korzystania z obu plików APK (w tym przykładzie urządzenia z dużym ekranem) otrzymają ten plik APK o najwyższym kodzie wersji.

  Uwaga: jeśli tworzysz osobne pliki APK dla różnych architektur procesora, pamiętaj, że pakiet APK dla ARMv5TE będzie pokrywał się z plikiem APK dla ARMv7. Oznacza to, że pakiet APK przeznaczony na ARMv5TE jest zgodny z urządzeniami ARMv7, ale nie jest to prawdą (plik APK zawierający tylko biblioteki ARMv7 nie jest zgodny z urządzeniami ARMv5TE).

W przypadku wystąpienia takich konfliktów zobaczysz komunikat z ostrzeżeniem, ale nadal możesz opublikować swoją aplikację.

Tworzenie wielu pakietów APK

Gdy zdecydujesz się opublikować wiele plików APK, prawdopodobnie musisz utworzyć osobne projekty na Androida dla każdego pliku, który zamierzasz opublikować, aby móc odpowiednio zaprogramować je oddzielnie. Aby to zrobić, skopiuj 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: jednym ze sposobów na uniknięcie duplikowania dużych części kodu aplikacji jest użycie projektu biblioteki. Projekt biblioteczny zawiera udostępniony kod i zasoby, które możesz uwzględnić w swoich rzeczywistych projektach aplikacji.

Gdy tworzysz wiele projektów dla tej samej aplikacji, warto nadać im nazwę, która wskaże ograniczenia dotyczące urządzeń, które należy zastosować do pliku APK. Dzięki temu będzie można łatwo je rozpoznać. Na przykład „HelloWorld_21” może być dobrą nazwą dla aplikacji zaprojektowanej dla interfejsu API na poziomie 21 lub wyższym.

Uwaga: wszystkie pliki APK, które publikujesz w ramach tej samej aplikacji, muszą mieć taką samą nazwę pakietu i być podpisane tym samym kluczem certyfikatu. Pamiętaj, aby zapoznać się też z regułami dotyczącymi wielu plików APK.

Przypisywanie kodów wersji

Każdy plik APK dla tej samej aplikacji musi mieć unikalny kod wersji określony za pomocą atrybutu android:versionCode. Musisz zachować ostrożność przy przypisywaniu kodów wersji podczas publikowania wielu plików APK, ponieważ każdy z nich musi być inny, ale w niektórych przypadkach muszą lub powinny być zdefiniowane w określonej kolejności zgodnie z konfiguracjami obsługiwanymi przez dany plik APK.

Porządkowanie kodów wersji

Plik APK, który wymaga wyższego poziomu interfejsu API, zwykle musi mieć wyższy kod wersji. Jeśli np. utworzysz 2 pliki APK do obsługi różnych poziomów interfejsu API, plik APK przeznaczony na wyższe poziomy interfejsu API musi mieć wyższy kod wersji. Dzięki temu, jeśli urządzenie otrzyma aktualizację systemu, która następnie kwalifikuje się do zainstalowania pliku APK na potrzeby wyższych poziomów interfejsu API, użytkownik otrzyma powiadomienie o konieczności zaktualizowania aplikacji. Więcej informacji o stosowaniu tego wymogu znajdziesz w sekcji Reguły dotyczące wielu plików APK powyżej.

Warto też wziąć pod uwagę to, w jaki sposób kolejność kodów wersji może wpłynąć na to, który plik APK otrzymają użytkownicy ze względu na pokrywanie się zasięgu różnych plików APK lub wprowadzenie w nich zmian.

Jeśli na przykład masz różne pliki APK oparte na rozmiarze ekranu, np. jeden dla małego – normalnego i jednego dla dużego – bardzo dużego, ale spodziewasz się, kiedy zmienisz pliki APK na jeden dla małych i normalnych – bardzo duży, musisz utworzyć kod wersji dla dużego – bardzo dużego pliku APK. Dzięki temu po wprowadzeniu zmiany urządzenie o normalnym rozmiarze otrzyma odpowiednią aktualizację, ponieważ kod wersji pliku APK zwiększy się do nowego pliku APK, który obsługuje dane urządzenie.

Dodatkowo przy tworzeniu wielu plików APK, które różnią się obsługą różnych formatów kompresji tekstur OpenGL, pamiętaj, że wiele urządzeń obsługuje wiele formatów. W sytuacji, gdy zasięg 2 pakietów APK się pokrywa, urządzenie otrzymuje plik APK o najwyższym kodzie wersji. Dlatego musisz uporządkować kody wersji w tych plikach, by pakiet APK z preferowanym formatem kompresji miał najwyższy kod wersji. Na przykład możesz chcieć utworzyć osobne kompilacje aplikacji, korzystając z formatów kompresji PVRTC, ATITC i ETC1. Jeśli wolisz te formaty w tej dokładnie kolejności, plik APK korzystający z PVRTC powinien mieć najwyższy kod wersji, pakiet APK korzystający z ATITC ma niższy kod, a wersja z ETC1 – najniższą. Jeśli więc urządzenie obsługuje zarówno protokół PVRTC, jak i ETC1, otrzyma plik APK z kodem PVRTC, ponieważ ma najwyższy kod wersji.

Gdy Sklep Google Play nie może zidentyfikować prawidłowego pliku APK do zainstalowania na urządzeniu docelowym, możesz też utworzyć uniwersalny plik APK, który będzie zawierał zasoby przeznaczone na różne wersje urządzeń, które chcesz obsługiwać. Jeśli udostępniasz uniwersalny plik APK, przypisz mu najniższą wartość, czyli versionCode. Sklep Google Play instaluje wersję Twojej aplikacji, która jest zarówno zgodna z urządzeniem docelowym, jak i ma najwyższą wartość versionCode, dlatego przypisanie niższej wartości versionCode do uniwersalnego pliku APK sprawi, że Sklep Google Play spróbuje zainstalować jeden z Twoich pozostałych plików APK, zanim zwróci się do większego uniwersalnego pliku APK.

Korzystanie ze schematu kodu wersji

Aby umożliwić różnym plikom APK aktualizowanie ich kodów wersji niezależnie od innych (np. gdy naprawisz błąd tylko w jednym pliku APK, więc nie musisz aktualizować wszystkich plików), użyj schematu, który zapewni wystarczającą ilość miejsca między poszczególnymi kodami APK, dzięki czemu będzie można zwiększyć kod w jednym pliku bez konieczności zwiększania pozostałych. Aby móc łatwo powiązać kod i nazwę wersji, w kodzie musisz też umieścić w kodzie rzeczywistą nazwę wersji (czyli wersję widoczną dla użytkownika przypisaną do elementu android:versionName).

Uwaga: gdy zwiększysz kod wersji pliku APK, Google Play poprosi użytkowników poprzedniej wersji o zaktualizowanie aplikacji. Aby uniknąć niepotrzebnych aktualizacji, nie należy zwiększać kodu wersji plików APK, które tak naprawdę nie zawierają zmian.

Zalecamy użycie kodu wersji zawierającego co najmniej 7 cyfr. Liczby całkowite reprezentujące obsługiwane konfiguracje są w bitach wyższej kolejności, a nazwa wersji (z android:versionName) – w bitach o niższej kolejności. Jeśli na przykład nazwa wersji aplikacji to 3.1.0, kody wersji pakietu APK interfejsu API na poziomie 4 i pakietu APK na poziomie 11 będą wyglądać odpowiednio 0400310 i 1100310. Dwie pierwsze cyfry są zarezerwowane dla poziomu interfejsu API (odpowiednio 4 i 11), 2 środkowe cyfry dotyczą rozmiarów ekranu lub formatów tekstur GL (nie użyto w tych przykładach), a 3 ostatnie cyfry to nazwa wersji aplikacji (3.1.0). Na Rysunku 1 widać 2 przykłady podziału w zależności od wersji platformy (poziom interfejsu API) i rozmiaru ekranu.

Rysunek 1. Sugerowany schemat kodów wersji, używający pierwszych 2 cyfr poziomu interfejsu API, a drugiej i trzeciej do minimalnego i maksymalnego rozmiaru ekranu (1–4 oznacza każdy z 4 rozmiarów) lub do wskazania formatów tekstur i 3 ostatnich cyfr wersji aplikacji.

Ten schemat kodów wersji to tylko sugestia dotycząca tworzenia wzorca, który będzie skalowalny w miarę rozwoju aplikacji. W szczególności nie pokazuje on rozwiązania do identyfikacji różnych formatów kompresji tekstur. Jedną z opcji może być zdefiniowanie własnej tabeli, która określa inną liczbę całkowitą dla każdego z różnych formatów kompresji obsługiwanych przez Twoją aplikację (na przykład 1 może odpowiadać ETC1, 2 to ATITC itd.).

Możesz użyć dowolnego schematu, ale zastanów się, czy przyszłe wersje aplikacji będą musiały zwiększać liczbę kodów wersji oraz jak urządzenia będą otrzymywać aktualizacje w przypadku zmiany konfiguracji urządzenia (np. z powodu aktualizacji systemu) lub zmiany obsługi konfiguracji jednego lub kilku plików APK.