Qualität für verschiedene Geräte und Veröffentlichung über Mobilgeräte hinaus bei Google Play

Hallo zusammen.

Vielen Dank, dass Sie an dieser Session zur App-Qualität für verschiedene Geräte und zum Veröffentlichen von Apps für andere Formfaktoren als Mobilgeräte bei Google Play teilgenommen haben.

Ich bin Jan Kleinert, Developer Relations Engineer im Android for Cars-Team.

Und ich bin Faustine Liao, Operations Lead im Play Trust and Safety-Team.

Wir freuen uns sehr, dass Sie heute alle dabei sind.

Wenn wir also jahrelang von Android-Entwicklung gesprochen haben, haben die meisten von uns wahrscheinlich nur an Mobilgeräte gedacht. Das Android-Ökosystem hat sich jedoch weit über Smartphones hinaus entwickelt.

Heute interagieren Nutzer mit Apps im Wohnzimmer auf Android TV, im Auto oder beim Laden des Autos mit Android Auto oder Automotive OS, am Handgelenk mit Wear OS und zunehmend in immersiven 3D-Räumen mit Android XR.

Das ist eine enorme Wachstumschance. Wenn Sie Ihre Veröffentlichungsstrategie auf diese Formfaktoren ausweiten, müssen Sie jedoch einige Dinge beachten.

Der gesamte Prozess von der Entwicklung Ihrer App bis zur Veröffentlichung und Bereitstellung bei Google Play ist im Wesentlichen derselbe wie bei Releases für Mobilgeräte.

Erstellen und bereiten Sie Ihre App vor, erstellen Sie dann Ihren Eintrag in der Play Console, testen Sie Ihre App, laden Sie Ihren Produktionsrelease hoch und reichen Sie ihn ein. Warten Sie dann auf die Überprüfung und Genehmigung.

Bei der Veröffentlichung von Apps für andere Formfaktoren als Mobilgeräte gibt es jedoch einige Besonderheiten zu beachten.

Heute stellen wir Ihnen ein klares Framework vor, mit dem Sie sich auf einen reibungsloseren, besser planbaren Releaseprozess für verschiedene Geräte vorbereiten können.

Beginnen wir mit den Grundlagen: wie Sie Ihre App entwerfen und verpacken.

Bevor Sie also die Google Play Console überhaupt öffnen, müssen Sie eine wichtige architektonische Entscheidung treffen.

Erstellen Sie ein einzelnes, einheitliches App-Bundle, das alles für alle unterstützten Formfaktoren enthält, oder teilen Sie Ihre App in formfaktorspezifische Module auf und generieren für jedes ein Android App Bundle (AAB)?

Wenn ich also von Modulen oder Modularisierung spreche, meine ich damit nur eine Möglichkeit, die Codebasis so zu strukturieren, dass sie sich leichter verwalten lässt.

Es gibt viele Ansätze zur Modularisierung, aber im Allgemeinen organisieren Sie Ihre Codebasis in lose gekoppelte, eigenständige Teile, wobei jeder Teil ein Modul ist.

Ein einheitlicher Android App Bundle-Ansatz mag zwar einfacher zu verwalten sein, wir empfehlen jedoch den modularen Ansatz.

Hier ist ein Beispiel, das zeigt, warum wir diesen modularen Ansatz empfehlen.

Angenommen, Sie haben eine App, die sowohl Mobilgeräte als auch Android TV unterstützt.

Wenn Sie ein einzelnes Android App Bundle im standardmäßigen Release-Track für Mobilgeräte einreichen und Ihre Android TV-App eine Überprüfung nicht besteht, wird der gesamte Release gestoppt.

Das wirkt sich sowohl auf die Veröffentlichung Ihrer Android TV-App als auch auf die Ihrer mobilen App aus.

Auch wenn es kein Problem mit Ihrer mobilen App gab, müssen Sie die Probleme beheben, die dazu geführt haben, dass die Android TV-Überprüfung fehlgeschlagen ist, und Ihre App noch einmal zur Überprüfung einreichen, bevor der Release für Ihre Nutzer verfügbar gemacht werden kann.

Modulare Android App Bundles für jeden Formfaktor bieten Ihnen dagegen eine detailliertere Kontrolle und helfen Ihnen, diese Formfaktor-Releases von Ihren mobilen Releases zu trennen.

Wenn Sie separate App-Module für Ihre mobile App und Ihre TV-App haben, können Sie stattdessen für jedes Modul ein eigenes Android App Bundle generieren.

Wenn es ein Problem mit der Überprüfung Ihrer TV-App gibt, wird nur die Veröffentlichung dieser App blockiert, bis Sie das Problem behoben haben.

Der Release der mobilen App wird wie vorgesehen veröffentlicht.

Wie bereits erwähnt, gibt es viele Ansätze für die Modularisierung.

Hier ist ein Beispiel für die Modularisierung einer Hörbuch-App, die sowohl für Mobilgeräte als auch für Android Automotive OS entwickelt wurde.

Oben in Grün sehen Sie ein App-Modul für jeden Formfaktor. So lassen sich die plattformspezifischen Abhängigkeiten trennen.

In Gelb sehen Sie die Funktionsmodule, die isolierten Teilen der App-Funktionen entsprechen.

Die Datenmodule sind blau dargestellt. Unten befinden sich die Kern- oder allgemeinen Module, die normalerweise Code enthalten, der von anderen Modulen häufig verwendet wird.

In den Gradle-Einstellungsdateien Ihres Projekts können Sie dann diese Gradle-Konfiguration mit mehreren Modulen einbinden und einrichten, um diese Art der Modularisierung zu unterstützen.

...

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

Sie verwenden also für jedes App-Modul und -Bundle denselben Paketnamen oder dieselbe Anwendungs-ID.

Dieser modulare Ansatz ist direkt mit Ihrer Release-Track-Strategie in der Play Console verknüpft.

Wenn Sie eine App veröffentlichen, haben Sie den Standard-Track für Mobilgeräte, aber wir bieten auch spezielle Tracks für Formfaktoren an.

Für Android TV, Android XR und Android Automotive OS haben Sie die Wahl.

Sie können sie zusammen mit der mobilen Version oder über die speziellen Formfaktor-Tracks veröffentlichen.

Es gibt jedoch zwei Ausnahmen.

Für Wear OS müssen Sie den speziellen Wear OS-Track verwenden.

Und für Android Auto, das im Grunde eine Erweiterung Ihrer mobilen App ist, die auf das Display im Auto projiziert wird, ist der Standard-Track für Mobilgeräte die einzige Option.

Wenn Sie mehrere Tracks verwalten, ist die Versionsverwaltung entscheidend.

Eine Möglichkeit besteht darin, die ersten Ziffern des Versionscodes dem Formfaktor zuzuweisen.

Beispiel: 01 für Mobilgeräte, 02 für Wear OS, 03 für Android Automotive OS usw.

Wir empfehlen, die Versionscodes mindestens siebenstellig zu machen, damit die verbleibenden Ziffern für die App-Version verwendet werden können.

So werden Versionscode-Konflikte in der Play Console vermieden.

Nachdem Sie Ihre App gepackt haben, ist es an der Zeit, sie zu testen.

Die Entwicklung für verschiedene Formfaktoren erfordert gründliche Tests. Google Play bietet Ihnen drei verschiedene Kanäle, um dies vor der Veröffentlichung in der Produktion zu tun: interne Tests, geschlossene Tests und offene Tests.

Wenn Sie spezielle Tracks für Formfaktoren verwenden, können Sie diese Test-Tracks auch mit Ihren Formfaktoren kombinieren, um den Prozess noch genauer zu steuern.

Sie können beispielsweise einen geschlossenen Test-Release für Ihre mobile App im Standard-Track und einen separaten geschlossenen Test-Release für Ihre Android TV-App im speziellen Android TV-Formfaktor-Track mit unterschiedlichen Testern haben, wenn Sie das so einrichten möchten.

Interne Tests sind also ein guter Ausgangspunkt.

Damit können Sie Ihre App schnell an bis zu 100 Tester verteilen, ohne dass eine Google Play-Überprüfung ausgelöst wird.

Das bedeutet, dass Sie und Ihre Tester die App schnell auf Geräten installieren und die Nutzung auf Emulatoren oder einem echten Fernseher, einer Smartwatch oder einem anderen Gerät testen können.

Bei internen Tests erhalten Sie eine eindeutige URL, die Sie mit den Testern teilen können.

Wenn Sie mit den Ergebnissen Ihrer internen Tests zufrieden sind, können Sie zu geschlossenen und offenen Tests übergehen.

Sie können über interne Tests hinausgehen und einen geschlossenen Testrelease erstellen. So können Sie Vorabveröffentlichungen Ihrer App mit einer größeren Gruppe von Testern testen und gezieltes Feedback erhalten.

Sie können Ihre Gruppen für geschlossene Tests entweder als Listen mit E‑Mail-Adressen oder über Google Groups verwalten.

Mit einem offenen Test können Sie dagegen einen Test mit einer größeren Gruppe bei Google Play durchführen.

Sie sind bei Google Play sichtbar und jeder kann am offenen Testprogramm teilnehmen.

Es ist keine Einladung erforderlich und sie können Ihnen Feedback und privates Feedback zur App geben.

Diese Tracks für offene und geschlossene Tests lösen Überprüfungen aus.

Das ist ein enormer Vorteil.

So können Sie den Überprüfungsprozess selbst testen und eventuelle Probleme lange vor dem Veröffentlichungstag beheben.

Apropos Überprüfungsprozess: Lassen Sie uns kurz darüber sprechen, was der Prozess beinhaltet und warum er wichtig ist.

Im Grunde geht es bei diesen Richtlinien um die Qualität von Apps.

Apps und Spiele mit hoher Qualität bieten Nutzern Folgendes: einen Mehrwert, eine angenehme Nutzung, eine optimale Ausnutzung von Premium-Geräten und eine hohe Sicherheit.

Sehen wir uns also an, wie Sie Ihre App so vorbereiten können, dass sie die Überprüfungen möglichst einfach besteht.

Am besten fangen Sie mit den Qualitätsrichtlinien zur App an, die sich auf die Nutzerfreundlichkeit konzentrieren.

Wir veröffentlichen Qualitätsrichtlinien für Kern-Apps, die für alle Apps gelten und die Mindestqualität definieren, die alle Apps erfüllen sollten, sowie Qualitätsrichtlinien für adaptive Apps. Diese helfen Ihnen, dafür zu sorgen, dass Ihre App unabhängig von Geräteformfaktor, Bildschirmgröße oder Anzeigemodus eine gute Nutzererfahrung bietet.

Diese beiden Richtlinien sind ein guter Ausgangspunkt.

Außerdem gibt es für jeden Formfaktor eigene Richtlinien zur App-Qualität.

Unsere Prüfer testen Ihre Apps auf echten Geräten und Emulatoren anhand dieser Richtlinien.

Es ist also sehr wichtig, dass Ihre App diese Richtlinien einhält.

Hier ist eine kurze Übersicht über die häufigsten Gründe, warum Apps für die einzelnen Formfaktoren abgelehnt werden.

Beachten Sie jedoch, dass diese nicht alle Qualitätsrichtlinien für Apps abdecken.

Sehen Sie sich also die Qualitätsrichtlinien für jeden Formfaktor, mit dem Sie arbeiten, im Detail an, um die umfassenden Kriterien zu kennen.

Fangen wir mit Android TV an.

Unten auf diesen Abschnittsfolien finden Sie einen Kurzlink, der Sie zur vollständigen Liste der Qualitätsrichtlinien für Apps für den jeweiligen Formfaktor führt.

Ein häufiger Grund für die Ablehnung von Android TV-Apps ist, dass für jede von der App unterstützte Sprache ein Bannerbild für den Startbildschirm fehlt.

Sie sollten daher ein Bild mit 320 × 180 Pixeln bereitstellen, das lokalisierten Text zur Kennzeichnung Ihrer App enthält.

Das Bild auf dieser Folie zeigt ein Beispiel für ein Banner auf dem Startbildschirm, das diese Kriterien erfüllt.

Zweitens interagieren Nutzer auf den meisten Fernsehern mit dem Gerät über eine Fernbedienung mit Steuerkreuz.

Es ist also sehr wichtig, dass du die Navigation und den Fokus per Steuerkreuz richtig unterstützt.

Achte darauf, dass du mindestens die Mindestanforderungen für die Steuerkreuz-Steuerung erfüllst, um Ablehnungen aufgrund dieser Kriterien zu vermeiden.

Der dritte häufige Grund für die Ablehnung von Android TV-Apps ist, dass der Intent-Filter CATEGORY_LEANBACK_LAUNCHER in der Android-Manifestdatei fehlt.

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

Durch diesen Filter wird Ihre App als für TV-Geräte aktiviert gekennzeichnet und Google Play kann sie Nutzern als TV-App präsentieren.

Wenn ein Nutzer deine App auf dem Startbildschirm seines Fernsehers auswählt, wird über diesen Intent die zu startende Aktivität identifiziert.

Achten Sie also darauf, dass Sie es in Ihr Manifest aufgenommen haben.

Als Nächstes sehen wir uns Android XR an.

Wenn Sie Apps für XR‑Headsets oder XR‑Datenbrillen mit Android XR entwickeln, sollten Sie besonders auf die Leistung, das Rendering und die Stabilität Ihrer Apps achten.

Mit Perfetto können Sie die Leistung von Apps, die mit dem Jetpack XR SDK erstellt wurden, analysieren, um sicherzustellen, dass die Mindestanforderungen an die Framerate erfüllt werden.

Wenn Sie eine Echtzeit-Engine wie Unity verwenden, können Sie die integrierten Profiling-Tools dieser Engine nutzen, um sicherzustellen, dass Sie die Rendering-Anforderungen erfüllen.

Als Nächstes kommen Autos, die sowohl Android Auto als auch Android Automotive OS umfassen.

Für Android Auto und Android Automotive OS gibt es Kategorien, die für diesen Formfaktor spezifisch sind.

Außerdem dürfen nur bestimmte App-Kategorien für Autos veröffentlicht werden.

Wenn Sie also eine App in einer Kategorie einreichen, die nicht zu den von uns unterstützten Kategorien gehört, oder wenn Sie eine App für einen offenen Test oder die Produktion in einer Kategorie einreichen, die sich noch in der Betaphase befindet, wird sie abgelehnt.

Ich zeige Ihnen, was ich damit meine.

Hier sehen Sie eine Übersicht der App-Kategorien, die für Autos auf den einzelnen Plattformen unterstützt werden, sowie deren Verfügbarkeit.

Ob es sich in der Betaphase befindet, offen ist, also allgemein verfügbar, oder noch nicht unterstützt wird, was hier durch „Demnächst verfügbar“ angezeigt wird.

Einige Kategorien wie Navigations- oder POI-Apps sind allgemein verfügbar. Das bedeutet, dass jeder eine App in einer dieser Kategorien für die Produktion für Autos veröffentlichen kann.

Andere Kategorien wie Kommunikations-Apps für Android Auto befinden sich jedoch noch in der Betaphase.

Für diese Kategorien können Sie also im Track für interne oder geschlossene Tests veröffentlichen, aber nicht im Produktions-Track, es sei denn, Sie wurden für eines unserer Early-Access-Programme für diese Kategorie zugelassen.

Weitere Informationen dazu und zu anderen Themen finden Sie in unseren Entwicklerleitfäden für Android for Cars.

Dort finden Sie Links, über die Sie sich für diese Early-Access-Programme bewerben können.

Fehlende oder falsche Spezifikationen für Android Automotive OS-Screenshots sind ein weiterer häufiger Grund für die Ablehnung von Apps.

Wenn Sie Screenshots für Android Automotive OS bereitstellen, müssen Sie also mindestens zwei Screenshots im Hochformat und mindestens zwei Screenshots im Querformat mit den hier aufgeführten Abmessungen hochladen.

Sie können den Android Automotive OS-Emulator verwenden, um diese zu erstellen.

Es ist so eingerichtet, dass Screenshots genau in der Größe aufgenommen werden, die Sie benötigen.

Und schließlich ist die Sicherheit bei Apps für Autos von größter Bedeutung.

Wenn Ihre App also nicht unseren Richtlinien zum Ablenkungsgrad des Fahrers entspricht, wird sie abgelehnt.

Eine Video-App muss beispielsweise die Wiedergabe pausieren und darf nicht sichtbar sein, während sich das Fahrzeug bewegt.

Und zu guter Letzt haben wir Wear OS.

Wear OS-Apps können also abgelehnt werden, wenn sie nicht für kleine, runde Displays optimiert und formatiert sind.

Wir empfehlen daher, die neueste stabile Version von Compose für Wear OS zu verwenden, damit Inhalte auf Geräten unterschiedlicher Größe nicht an den Rändern abgeschnitten werden oder die Bildlaufleiste angezeigt wird, wenn scrollbare Inhalte vorhanden sind.

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

Ähnlich wie bei Android Automotive OS können Wear OS-Apps auch wegen fehlender oder ungenauer Wear OS-Screenshots abgelehnt werden.

Hier ist ein gutes Beispiel für einen Screenshot aus dem Google Play Store-Eintrag für die Beispiel-App Androidify, der die Anforderungen erfüllt.

Reichen Sie also mindestens einen Screenshot ein, auf dem Ihre App auf einem Wear OS-Gerät zu sehen ist.

Das bedeutet:

Lies die Qualitätsrichtlinien für Apps für deinen spezifischen Formfaktor und teste deine App anhand dieser Richtlinien, bevor du sie einreichst.

Außerdem ein paar wichtige Tipps.

Wenn für Ihre App eine Anmeldung erforderlich ist, müssen Sie in der Play Console im Bereich „App-Zugriff“ ein aktives Demokonto und gültige Anmeldedaten angeben.

Wenn sich unsere Prüfer nicht anmelden können, können wir Ihre App nicht testen und sie wird automatisch abgelehnt.

Außerdem sollten Sie halten, was Sie versprechen.

Verwenden Sie nicht nur Screenshots von Mobilgeräten.

Wenn Ihre App für Wear OS und Android TV verfügbar ist, laden Sie in der Play Console hochwertige Screenshots für diese Formfaktoren hoch.

Und zu guter Letzt: Seien Sie beschreibend.

Beschreiben Sie genau, wozu Ihre App dient, warum sie nützlich ist und was Nutzer nach der Installation auf den einzelnen Gerätetypen erwarten können.

Zusammenfassend lässt sich sagen, dass es eine unglaubliche Chance ist, Nutzer fast überall zu erreichen. Wenn Sie Ihre App modular aufbauen, interne Tests für schnelle Iterationen nutzen, die Qualitätsrichtlinien für Formfaktoren einhalten und Ihre Store-Einträge optimieren, können Sie Ihre App auf einen reibungsloseren Start- und Überprüfungsprozess vorbereiten.

Vielen Dank, dass Sie sich heute Zeit genommen haben.

Wir sind schon gespannt, welche tollen geräteübergreifenden Funktionen ihr bei Google Play anbieten werdet.