Zapewnianie jakości na wielu urządzeniach i publikowanie aplikacji na urządzenia inne niż mobilne w Google Play

Witam wszystkich.

Dziękujemy za udział w tej sesji poświęconej jakości aplikacji na wiele urządzeń i publikowaniu w Google Play na urządzenia inne niż mobilne.

Nazywam się Jan Kleinert i jestem inżynierem ds. relacji z programistami w zespole Androida do samochodu.

A ja nazywam się Faustine Liao i jestem kierowniczką operacyjną w zespole ds. zaufania i bezpieczeństwa w Google Play.

Bardzo się cieszymy, że jesteście tu dzisiaj z nami.

Dlatego przez lata, gdy mówiliśmy o tworzeniu aplikacji na Androida, większość z nas miała na myśli tylko urządzenia mobilne. Jednak ekosystem Androida rozszerzył się daleko poza smartfony.

Dziś użytkownicy korzystają z aplikacji w salonie na Androidzie TV, w samochodzie na Androidzie Auto lub Automotive OS, na nadgarstku na Wear OS, a coraz częściej także w przestrzeniach 3D na Androidzie XR.

To ogromna szansa na rozwój, ale rozszerzenie działalności na te formaty oznacza, że w strategii publikowania należy uwzględnić kilka dodatkowych kwestii.

Cały proces od utworzenia aplikacji do jej opublikowania i udostępnienia w Google Play jest zasadniczo taki sam jak w przypadku wersji mobilnych.

Utwórz i przygotuj aplikację, a następnie utwórz jej stronę w Konsoli Play, przetestuj aplikację, prześlij wersję produkcyjną i poczekaj na jej sprawdzenie i zatwierdzenie.

Istnieją jednak pewne szczególne kwestie, które należy wziąć pod uwagę podczas publikowania aplikacji na inne formaty urządzeń niż urządzenia mobilne.

Dzisiaj przedstawimy Ci jasne ramy, które pomogą Ci przygotować się do płynniejszego i bardziej przewidywalnego procesu publikowania na wiele urządzeń.

Zacznijmy od podstaw: jak zaprojektować i spakować aplikację.

Zanim więc zaczniesz korzystać z Konsoli Google Play, musisz podjąć ważną decyzję dotyczącą architektury.

Czy tworzysz jeden ujednolicony pakiet aplikacji zawierający wszystko, co jest potrzebne do obsługi wszystkich formatów, czy dzielisz aplikację na moduły dostosowane do poszczególnych formatów i generujesz dla każdego z nich pakiety Android App Bundle (AAB)?

Gdy mówię o modułach lub modularyzacji, mam na myśli sposób strukturyzacji bazy kodu, który ułatwia jej utrzymanie.

Istnieje wiele podejść do modularyzacji, ale ogólnie polega ona na organizowaniu bazy kodu w oprogramowanie luźno sprzężone, samodzielne części, z których każda jest modułem.

Chociaż ujednolicone podejście do pakietu Android App Bundle może wydawać się prostsze w zarządzaniu, zalecamy podejście modułowe.

Oto przykład, który pokazuje, dlaczego zalecamy takie podejście modułowe.

Wyobraźmy sobie, że masz aplikację, która obsługuje zarówno urządzenia mobilne, jak i Androida TV.

Jeśli prześlesz pojedynczy pakiet aplikacji na Androida na standardowej ścieżce wersji mobilnej, a aplikacja na Androida TV nie przejdzie weryfikacji, spowoduje to zatrzymanie całej wersji.

Wpłynie to zarówno na wersję aplikacji na Androida TV, jak i na wersję aplikacji mobilnej.

Mimo że nie było problemu z samą aplikacją mobilną, musisz rozwiązać problemy, które spowodowały odrzucenie aplikacji na Androida TV, i ponownie przesłać aplikację do sprawdzenia, zanim będzie można udostępnić wersję użytkownikom.

Z drugiej strony modułowe pakiety aplikacji na Androida dla każdego formatu zapewnią Ci bardziej szczegółową kontrolę i pomogą odizolować wersje na dany format od wersji mobilnych.

Jeśli masz osobne moduły aplikacji na urządzenia mobilne i telewizory, możesz wygenerować osobne pakiety Android App Bundle dla każdego z nich.

Jeśli wystąpi problem ze sprawdzeniem aplikacji TV, tylko wersja tej aplikacji zostanie zablokowana do czasu rozwiązania problemu.

Wersja aplikacji mobilnej zostanie opublikowana zgodnie z planem.

Jak już wspominałem, istnieje wiele podejść do modularyzacji.

Oto przykład podejścia do modularyzacji aplikacji do audiobooków, która działa na urządzeniach mobilnych i systemie operacyjnym Android Automotive.

U góry, na zielono, mamy moduł aplikacji dla każdego formatu, co pomaga oddzielić zależności specyficzne dla platformy.

Na żółto zaznaczono moduły funkcji, które odpowiadają odizolowanym częściom funkcjonalności aplikacji.

Moduły danych są oznaczone na niebiesko, a na dole znajdują się moduły podstawowe lub wspólne, które zwykle zawierają kod często używany przez inne moduły.

Następnie w plikach ustawień Gradle projektu możesz uwzględnić i skonfigurować tę wielomodułową konfigurację Gradle, aby obsługiwała ten rodzaj modularyzacji.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

Dlatego w przypadku każdego modułu i pakietu aplikacji będziesz używać tej samej nazwy pakietu lub identyfikatora aplikacji.

To modułowe podejście jest bezpośrednio powiązane ze strategią ścieżek w Konsoli Play.

Gdy publikujesz aplikację, masz standardową ścieżkę mobilną, ale oferujemy też ścieżki dedykowane dla poszczególnych formatów.

W przypadku Androida TV, Androida XR i systemu operacyjnego Android Automotive masz wybór.

Możesz publikować je razem z aplikacjami mobilnymi lub używać osobnych ścieżek dla tych formatów.

Istnieją jednak 2 wyjątki.

W przypadku Wear OS musisz używać osobnej ścieżki dla tego systemu.

W przypadku Androida Auto, który jest zasadniczo rozszerzeniem aplikacji mobilnej wyświetlanym na ekranie samochodu, jedyną opcją jest standardowa ścieżka mobilna.

Jeśli zarządzasz wieloma ścieżkami, wersjonowanie jest kluczowe.

Jednym ze sposobów jest przypisanie pierwszych kilku cyfr kodu wersji do formatu.

Na przykład 01 dla urządzeń mobilnych, 02 dla Wear OS, 03 dla systemu operacyjnego Android Automotive itd.

Zalecamy, aby kody wersji miały co najmniej 7 cyfr, dzięki czemu pozostałe cyfry będą mogły być używane do oznaczania wersji aplikacji.

Pomaga to zapobiegać kolizjom kodów wersji w Konsoli Play.

Gdy aplikacja zostanie spakowana, nadejdzie czas na jej przetestowanie.

Tworzenie aplikacji na różne formaty wymaga dokładnego przetestowania. Google Play udostępnia 3 różne kanały, które umożliwiają przeprowadzenie testów przed opublikowaniem aplikacji w wersji produkcyjnej: testy wewnętrzne, testy zamknięte i testy otwarte.

Jeśli używasz ścieżek przeznaczonych dla konkretnych formatów, możesz też połączyć te ścieżki testów z formatami, co zapewni jeszcze większą kontrolę nad procesem.

Możesz na przykład mieć wersję aplikacji mobilnej do testu zamkniętego na ścieżce standardowej i osobną wersję aplikacji na Androida TV do testu zamkniętego na ścieżce dedykowanej dla formatu Android TV z różnymi zestawami testerów, jeśli chcesz to skonfigurować w ten sposób.

Testy wewnętrzne są więc świetnym punktem wyjścia.

Pozwala ona szybko udostępnić aplikację maksymalnie 100 testerom i co ważne, nie wymaga sprawdzania w Google Play.

Oznacza to, że Ty i Twoi testerzy możecie szybko zainstalować aplikację na urządzeniach i sprawdzić, jak działa na emulatorach lub na prawdziwym telewizorze, zegarku bądź innym urządzeniu.

W przypadku testów wewnętrznych otrzymasz unikalny adres URL, który możesz udostępnić testerom.

Gdy wyniki testów wewnętrznych będą zadowalające, możesz przejść do testów zamkniętych i otwartych.

Możesz wyjść poza testy wewnętrzne i utworzyć wersję do testów zamkniętych, aby przekazać przedpremierowe wersje aplikacji do sprawdzenia szerszemu gronu testerów i zebrać dzięki temu bardziej ukierunkowane opinie.

Grupami testerów w testach zamkniętych możesz zarządzać za pomocą list adresów e-mail lub Grup dyskusyjnych Google.

Z kolei test otwarty pozwala przeprowadzić test na większej grupie użytkowników w Google Play.

Będziesz widoczny(-a) w Google Play i każdy będzie mógł dołączyć do programu testów otwartych.

Nie potrzebują zaproszenia i mogą przekazywać Ci opinie (także prywatne) na temat aplikacji.

Te ścieżki testów otwartych i ścieżki testu zamkniętego powodują uruchomienie sprawdzania.

To naprawdę ogromna zaleta.

Dzięki temu możesz przetestować sam proces sprawdzania i usunąć wszelkie przeszkody na długo przed wyczekiwanym dniem premiery.

Skoro mowa o procesie weryfikacji, porozmawiajmy trochę o tym, co on obejmuje i dlaczego jest ważny.

Zasady i wytyczne dotyczą przede wszystkim jakości aplikacji.

Aplikacje i gry wysokiej jakości są wartościowe dla użytkowników i wygodne w użyciu. W pełni wykorzystują możliwości urządzeń premium i zostały zaprojektowane z myślą o bezpieczeństwie.

Przyjrzyjmy się, jak możesz przygotować aplikację, aby jak najłatwiej przeszła proces sprawdzania.

Myślę, że najlepiej zacząć od zapoznania się ze wskazówkami dotyczącymi jakości aplikacji, które skupiają się na tym, jak zapewnić użytkownikom jak najlepsze wrażenia.

Publikujemy wskazówki dotyczące podstawowej jakości aplikacji, które mają zastosowanie do wszystkich aplikacji i określają minimalną jakość, jaką powinny spełniać wszystkie aplikacje, a także wskazówki dotyczące jakości aplikacji adaptacyjnych. Pomogą Ci one zapewnić, że Twoja aplikacja będzie działać bezproblemowo niezależnie od formatu urządzenia, rozmiaru ekranu czy trybu wyświetlania.

Te 2 zestawy wytycznych to świetny punkt wyjścia.

Mamy też wskazówki dotyczące jakości aplikacji na poszczególne formaty.

Nasi weryfikatorzy będą testować Twoje aplikacje na rzeczywistych urządzeniach i emulatorach pod kątem zgodności z tymi wytycznymi.

Dlatego bardzo ważne jest, aby Twoja aplikacja była z nimi zgodna.

Oto najczęstsze przyczyny odrzucania aplikacji w przypadku poszczególnych formatów.

Pamiętaj jednak, że nie obejmują one wszystkich wskazówek dotyczących jakości aplikacji.

Dlatego zapoznaj się ze wskazówkami dotyczącymi jakości dla każdego formatu, z którym pracujesz, aby poznać bardziej szczegółowe kryteria.

Zacznijmy od Androida TV.

Dlatego u dołu slajdów w tych sekcjach znajdziesz krótki link, który przeniesie Cię do pełnej listy wskazówek dotyczących jakości aplikacji na dany format.

Jednym z częstych powodów odrzucenia aplikacji na Androida TV jest brak obrazu banera na ekranie głównym w każdym języku obsługiwanym przez aplikację.

Dlatego należy przesłać obraz o wymiarach 320 x 180 pikseli, który zawiera przetłumaczony tekst identyfikujący aplikację.

Obraz na tym slajdzie przedstawia przykład banera na ekranie głównym, który spełnia te kryteria.

Po drugie, na większości telewizorów użytkownicy będą wchodzić w interakcję z urządzeniem za pomocą pilota z padem kierunkowym.

Dlatego bardzo ważne jest, aby prawidłowo obsługiwać nawigację i fokus za pomocą pada kierunkowego.

Upewnij się, że obsługujesz co najmniej minimalne elementy sterujące pada kierunkowego, aby uniknąć odrzucenia aplikacji na podstawie tych kryteriów.

Trzecim najczęstszym powodem odrzucenia aplikacji na Androida TV jest brak filtra intencji CATEGORY_LEANBACK_LAUNCHER w pliku manifestu Androida.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

Ten filtr identyfikuje aplikację jako obsługującą telewizory i pozwala Google Play oznaczyć ją dla użytkowników jako aplikację TV.

Gdy użytkownik wybierze Twoją aplikację na ekranie głównym telewizora, ta intencja określi, którą aktywność należy uruchomić.

Upewnij się, że jest on uwzględniony w pliku manifestu.

Następny jest Android XR.

Jeśli tworzysz aplikacje na gogle XR lub okulary XR z Androidem XR, zwróć szczególną uwagę na wydajność, renderowanie i stabilność.

Za pomocą Perfetto możesz profilować wydajność aplikacji utworzonych za pomocą pakietu Jetpack XR SDK, aby mieć pewność, że spełniasz minimalne wymagania dotyczące liczby klatek.

Jeśli tworzysz grę za pomocą silnika działającego w czasie rzeczywistym, takiego jak Unity, możesz użyć wbudowanych w niego narzędzi do profilowania, aby upewnić się, że spełniasz wymagania dotyczące renderowania.

Następnie mamy samochody, które obejmują zarówno Androida Auto, jak i system operacyjny Android Automotive.

W przypadku Androida Auto i systemu operacyjnego Android Automotive istnieją kategorie, które są nieco unikalne dla tego konkretnego formatu.

W samochodach można publikować tylko aplikacje z określonych kategorii.

Jeśli więc prześlesz aplikację do kategorii, która nie jest zgodna z jedną z obsługiwanych przez nas, lub jeśli prześlesz aplikację do testów otwartych lub ścieżki produkcyjnej w kategorii, która jest dostępna tylko w wersji beta, zostanie ona odrzucona.

Pokażę Ci, o co mi chodzi.

Tutaj możesz zobaczyć podsumowanie kategorii aplikacji obsługiwanych w samochodach na każdej platformie oraz ich dostępność.

Może to być wersja beta, wersja otwarta (czyli ogólnie dostępna) lub wersja jeszcze nieobsługiwana (oznaczona jako „Już wkrótce”).

Niektóre kategorie, takie jak nawigacja czy aplikacje z ciekawymi miejscami, są ogólnie dostępne, co oznacza, że każdy może opublikować aplikację z jednej z tych kategorii na ścieżce produkcyjnej dla samochodów.

Inne kategorie, takie jak aplikacje do komunikacji na Androida Auto, są w wersji beta.

W przypadku tych kategorii możesz opublikować aplikację na ścieżce testu wewnętrznego lub ścieżce testu zamkniętego, ale nie możesz jej opublikować w wersji produkcyjnej, chyba że zaakceptujemy Twoje zgłoszenie do jednego z naszych programów wcześniejszego dostępu w danej kategorii.

Więcej informacji na ten temat znajdziesz w naszych przewodnikach dla programistów aplikacji na Androida do samochodu.

Znajdziesz tam linki, które pozwolą Ci zgłosić się do tych programów wcześniejszego dostępu.

Innym częstym powodem odrzucania aplikacji jest brak specyfikacji zrzutów ekranu na system operacyjny Android Automotive lub ich nieprawidłowa specyfikacja.

Dlatego gdy przesyłasz zrzuty ekranu z systemu operacyjnego Android Automotive, musisz przesłać co najmniej 2 zrzuty ekranu w orientacji pionowej i co najmniej 2 w orientacji poziomej o wymiarach podanych tutaj.

Możesz je przechwycić za pomocą emulatora systemu operacyjnego Android Automotive.

Jest on skonfigurowany w taki sposób, że może przechwytywać zrzuty ekranu o odpowiednim rozmiarze.

W przypadku aplikacji na samochody najważniejsze jest bezpieczeństwo.

Jeśli Twoja aplikacja nie jest zgodna z naszymi wytycznymi dotyczącymi rozpraszania uwagi kierowcy, zostanie odrzucona.

Na przykład aplikacja do odtwarzania filmów musi wstrzymać odtwarzanie i nie może być widoczna, gdy pojazd jest w ruchu.

I na koniec, ale nie mniej ważny, Wear OS.

Aplikacje na Wear OS mogą zostać odrzucone, jeśli nie są zoptymalizowane i sformatowane pod kątem małych, okrągłych wyświetlaczy.

Zalecamy używanie najnowszej stabilnej wersji Compose na Wear OS, aby mieć pewność, że treści nie będą obcinane na krawędziach na urządzeniach o różnych rozmiarach, lub na przykład, że pasek przewijania pojawi się, gdy treści będą przewijalne.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Podobnie jak w przypadku systemu operacyjnego Android Automotive, aplikacje na Wear OS mogą zostać odrzucone z powodu braku zrzutów ekranu z Wear OS lub ich niedokładności.

Oto przykład dobrego zrzutu ekranu ze strony przykładowej aplikacji Androidify w Sklepie Google Play, który spełnia wymagania.

Dlatego prześlij co najmniej 1 zrzut ekranu, który pokazuje aplikację działającą na urządzeniu z Wear OS.

Wniosek?

Przed przesłaniem aplikacji zapoznaj się ze wskazówkami dotyczącymi jakości aplikacji na dany format i przetestuj aplikację pod kątem zgodności z nimi.

Przedstawimy też kilka ważnych wskazówek.

Jeśli aplikacja wymaga logowania, w sekcji dostępu do aplikacji w Konsoli Play musisz podać aktywne konto demonstracyjne i prawidłowe dane logowania.

Jeśli nasi weryfikatorzy nie będą mogli się zalogować, nie będziemy mogli przetestować Twojej aplikacji i zostanie ona automatycznie odrzucona.

Pamiętaj też, aby dotrzymywać obietnic.

Nie używaj tylko zrzutów ekranu z urządzeń mobilnych.

Jeśli Twoja aplikacja jest dostępna na Wear OS i Androida TV, prześlij w Konsoli Play wysokiej jakości zrzuty ekranu z tych urządzeń.

I ostatnia, ale nie mniej ważna kwestia: używaj opisowych nazw.

Wyjaśnij użytkownikom dokładnie, do czego służy aplikacja, dlaczego jest wartościowa i czego mogą się spodziewać po jej zainstalowaniu na każdym typie urządzenia.

Podsumowując, docieranie do użytkowników niemal wszędzie, gdzie się znajdują, to niesamowita możliwość. Modułowa architektura, testy wewnętrzne umożliwiające szybkie wprowadzanie zmian, projektowanie zgodnie ze wskazówkami dotyczącymi jakości na różnych formatach i optymalizacja informacji o aplikacji pomogą Ci przygotować aplikację do płynniejszego procesu wprowadzania na rynek i sprawdzania.

Dziękuję wszystkim za poświęcony czas.

Nie możemy się doczekać, aż zobaczymy, jakie niesamowite funkcje na wiele urządzeń udostępnicie w Google Play.