Memahami kualitas multiperangkat & memublikasikan aplikasi di luar perangkat seluler di Google Play

Selamat datang, semuanya.

Terima kasih banyak telah bergabung dalam sesi ini tentang memahami kualitas aplikasi multiperangkat dan memublikasikan aplikasi di Google Play untuk faktor bentuk selain perangkat seluler.

Saya Jan Kleinert, Developer Relations Engineer di tim Android untuk Mobil.

Dan saya Faustine Liao, Operations Lead di tim Kepercayaan dan Keamanan Play.

Kami sangat senang Anda semua hadir bersama kami hari ini.

Jadi selama bertahun-tahun, saat kita berbicara tentang pengembangan Android, kebanyakan dari kita benar-benar hanya membayangkan perangkat seluler, tetapi ekosistem Android telah berkembang jauh melampaui sekadar smartphone.

Jadi, saat ini pengguna Anda berinteraksi dengan aplikasi di ruang keluarga mereka di Android TV, mungkin saat mengantre atau saat mengisi daya mobil di Android Auto atau Automotive OS, di pergelangan tangan mereka dengan Wear OS, dan makin banyak di ruang 3D imersif dengan Android XR.

Ini adalah peluang besar untuk berkembang, tetapi memperluas ke faktor bentuk ini berarti ada beberapa pertimbangan kecil yang perlu diperhitungkan untuk strategi publikasi Anda.

Proses keseluruhan mulai dari mem-build aplikasi hingga memublikasikannya dan menayangkannya di Google Play umumnya tetap sama seperti yang biasa Anda lakukan untuk rilis seluler.

Bangun dan siapkan aplikasi Anda, lalu buat listingan di Konsol Play, uji aplikasi, upload dan kirim rilis produksi, lalu tunggu peninjauan dan persetujuan.

Namun, ada beberapa pertimbangan unik untuk memublikasikan aplikasi untuk faktor bentuk selain seluler.

Hari ini, kami akan memberikan framework yang jelas untuk membantu Anda mempersiapkan proses rilis multiperangkat yang lebih lancar dan lebih dapat diprediksi.

Mari kita mulai dengan fondasinya: cara merancang dan memaketkan aplikasi Anda.

Jadi, sebelum Anda menggunakan Konsol Google Play, Anda harus membuat keputusan arsitektur yang penting.

Apakah Anda membuat satu app bundle terpadu yang berisi semua hal untuk semua faktor bentuk yang Anda dukung, atau apakah Anda membagi aplikasi menjadi modul khusus faktor bentuk dan membuat Android App Bundle, atau AAB, untuk masing-masing modul?

Jadi, saat saya mengatakan modul atau modularisasi, yang saya maksud adalah cara untuk membuat struktur codebase Anda dengan cara yang meningkatkan kemudahan pengelolaan.

Ada banyak pendekatan untuk modularisasi, tetapi, secara umum, yang Anda lakukan adalah, mengatur codebase menjadi bagian-bagian yang dikaitkan secara longgar dan berdiri sendiri, dengan setiap bagian adalah modul.

Jadi, meskipun pendekatan Android App Bundle terpadu mungkin terdengar lebih mudah dikelola, kami sebenarnya merekomendasikan pendekatan modular.

Berikut contoh yang menunjukkan alasan kami merekomendasikan pendekatan modular ini.

Jadi, bayangkan Anda memiliki aplikasi yang mendukung perangkat seluler dan Android TV.

Jika Anda mengirimkan satu Android App Bundle di jalur rilis seluler standar dan aplikasi Android TV Anda gagal dalam pemeriksaan peninjauan, seluruh rilis akan dihentikan.

Jadi, hal ini akan memengaruhi rilis aplikasi Android TV dan aplikasi seluler Anda.

Jadi, meskipun tidak ada masalah khusus pada aplikasi seluler Anda, Anda harus mengatasi masalah yang menyebabkan peninjauan Android TV tersebut gagal dan mengirim ulang aplikasi Anda untuk ditinjau sebelum rilis dapat tersedia bagi pengguna.

Di sisi lain, Android App Bundle modular untuk setiap faktor bentuk akan memberi Anda kontrol yang lebih terperinci dan membantu Anda mengisolasi rilis faktor bentuk tersebut dari rilis seluler.

Jadi, jika Anda memiliki modul aplikasi terpisah untuk aplikasi seluler dan aplikasi TV, Anda dapat membuat Android App Bundle terpisah untuk masing-masing modul.

Kemudian, jika ada masalah dengan peninjauan untuk aplikasi TV Anda, hanya rilis aplikasi tersebut yang akan diblokir hingga Anda dapat menyelesaikan masalahnya.

Rilis aplikasi seluler akan dipublikasikan sebagaimana mestinya.

Seperti yang telah disebutkan sebelumnya, ada banyak pendekatan untuk modularisasi.

Berikut adalah salah satu contoh pendekatan untuk memodularisasi aplikasi buku audio yang memiliki pengalaman seluler dan pengalaman Android Automotive OS.

Jadi, di bagian atas, dalam warna hijau, kita memiliki modul aplikasi untuk setiap faktor bentuk, dan ini membantu memisahkan dependensi khusus platform.

Kemudian, dalam warna kuning, kita memiliki modul fitur, dan modul tersebut sesuai dengan bagian terisolasi dari fungsi aplikasi.

Modul data berwarna biru, lalu di bagian bawah, ada modul inti, atau umum, yang biasanya digunakan, untuk berisi kode yang sering digunakan modul lain.

Kemudian, dalam file setelan Gradle project, Anda dapat menyertakan dan menyiapkan konfigurasi Gradle multi-modul ini untuk mendukung jenis modularisasi ini.

...

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

Jadi, Anda akan terus menggunakan nama paket atau ID aplikasi yang sama untuk setiap modul dan app bundle.

Pendekatan modular tersebut terkait langsung dengan strategi jalur Anda di Konsol Play.

Saat memublikasikan, Anda memiliki jalur seluler standar, tetapi kami juga menawarkan jalur faktor bentuk khusus.

Untuk Android TV, Android XR, dan Android Automotive OS, Anda memiliki pilihan.

Anda dapat memublikasikannya bersama aplikasi seluler atau menggunakan jalur faktor bentuk khusus.

Namun, ada dua pengecualian.

Untuk Wear OS, Anda harus menggunakan jalur Wear OS khusus.

Dan untuk Android Auto, karena pada dasarnya merupakan ekstensi aplikasi seluler Anda yang diproyeksikan ke layar mobil, satu-satunya pilihan adalah jalur seluler standar.

Jika Anda mengelola beberapa jalur, pembuatan versi sangatlah penting.

Salah satu pendekatannya adalah dengan menetapkan beberapa digit pertama kode versi Anda ke faktor bentuk.

Misalnya, 01 untuk seluler, 02 untuk Wear OS, 03 untuk Android Automotive OS, dan seterusnya.

Kami biasanya merekomendasikan agar Anda membuat kode versi dengan panjang minimal tujuh digit, sehingga digit yang tersisa dapat digunakan untuk versi aplikasi.

Hal ini membantu mencegah konflik kode versi di Konsol Play.

Setelah aplikasi Anda dikemas, sekarang saatnya untuk menguji.

Pengembangan faktor bentuk memerlukan pengujian menyeluruh, dan Google Play memberi Anda tiga saluran berbeda untuk melakukannya sebelum merilis ke produksi: pengujian internal, pengujian tertutup, dan pengujian terbuka.

Jika menggunakan jalur faktor bentuk khusus, Anda juga dapat menggabungkan jalur pengujian ini dengan faktor bentuk, sehingga memberi Anda kontrol yang lebih terperinci atas prosesnya.

Misalnya, Anda dapat memiliki rilis pengujian tertutup untuk aplikasi seluler di jalur standar dan rilis pengujian tertutup terpisah untuk aplikasi Android TV di jalur faktor bentuk Android TV khusus dengan kelompok penguji yang berbeda jika Anda ingin menyiapkannya seperti itu.

Jadi, pengujian internal adalah titik awal yang bagus.

Dengan pengujian ini, Anda dapat mendistribusikan aplikasi dengan cepat kepada maksimal 100 penguji, dan yang terpenting, pengujian ini tidak memicu peninjauan Play.

Jadi, ini berarti Anda dan penguji dapat menginstal aplikasi di perangkat dengan cepat dan memvalidasi pengalaman di emulator atau TV, smartwatch, atau perangkat lain yang sebenarnya.

Dengan pengujian internal, Anda akan mendapatkan URL unik yang dapat dibagikan kepada penguji tersebut.

Setelah puas dengan hasil pengujian internal, Anda dapat beralih ke pengujian tertutup dan pengujian terbuka.

Anda dapat memperluas pengujian di luar pengujian internal dengan rilis pengujian tertutup, yang memungkinkan Anda menguji versi pra-rilis aplikasi dengan kelompok penguji yang lebih luas untuk mendapatkan masukan yang akurat.

Anda dapat mengelola grup pengujian tertutup sebagai daftar alamat email atau melalui Google Grup.

Di sisi lain, pengujian terbuka membantu Anda menjalankan pengujian dengan kelompok yang lebih besar di Google Play.

Anda akan terlihat di Google Play, dan siapa pun dapat bergabung ke program pengujian terbuka.

Tidak diperlukan undangan, dan mereka akan dapat memberikan masukan, masukan pribadi kepada Anda tentang aplikasi.

Jalur pengujian terbuka dan tertutup ini memicu peninjauan.

Hal ini sebenarnya merupakan keuntungan yang sangat besar.

Dengan begitu, Anda dapat menguji proses peninjauan itu sendiri dan mengatasi hambatan apa pun jauh sebelum hari peluncuran yang sangat dinantikan.

Jadi, terkait proses peninjauan, mari kita bahas sedikit tentang apa yang diperlukan dalam proses tersebut dan mengapa proses tersebut penting.

Pada intinya, kebijakan dan pedoman ini adalah tentang kualitas aplikasi.

Jadi, aplikasi dan game berkualitas tinggi memberikan nilai kepada pengguna, menyenangkan untuk digunakan, mengoptimalkan perangkat premium, dan dirancang untuk keamanan.

Jadi, mari kita lihat cara Anda dapat menyiapkan aplikasi untuk lulus peninjauan semudah mungkin.

Menurut kami, tempat terbaik untuk memulai adalah dengan melihat pedoman Kualitas Aplikasi yang berfokus pada seperti apa pengalaman pengguna yang baik.

Kami memublikasikan pedoman Kualitas Aplikasi Inti yang berlaku untuk semua aplikasi dan menentukan kualitas minimum yang harus dipenuhi semua aplikasi, serta pedoman Kualitas Aplikasi adaptif, dan pedoman ini akan membantu Anda memastikan bahwa aplikasi Anda memberikan pengalaman yang baik, apa pun faktor bentuk perangkat, ukuran layar, atau mode tampilannya.

Kedua kumpulan panduan ini merupakan tempat yang sangat baik untuk memulai.

Namun, kami juga memiliki pedoman Kualitas Aplikasi khusus faktor bentuk untuk setiap faktor bentuk.

Peninjau kami akan menguji aplikasi Anda di perangkat dan emulator sungguhan berdasarkan pedoman ini.

Jadi, sangat penting untuk memastikan aplikasi Anda mematuhinya.

Berikut adalah ringkasan alasan paling umum penolakan aplikasi untuk setiap faktor bentuk.

Namun, perlu diingat bahwa ini tidak akan mencakup daftar lengkap semua pedoman Kualitas Aplikasi.

Jadi, pastikan untuk melihat pedoman kualitas tersebut untuk setiap faktor bentuk yang Anda gunakan secara mendetail untuk kumpulan kriteria yang lebih lengkap.

Jadi, mari kita mulai dengan Android TV.

Jadi, di bagian bawah slide ini, Anda akan melihat link singkat yang akan mengarahkan Anda ke daftar lengkap pedoman Kualitas Aplikasi untuk faktor bentuk tersebut.

Salah satu alasan umum penolakan aplikasi Android TV adalah jika aplikasi tersebut tidak memiliki gambar banner layar utama untuk setiap bahasa yang didukung aplikasi.

Jadi, yang harus Anda lakukan adalah memberikan gambar berukuran 320 x 180 piksel yang menyertakan teks yang dilokalkan yang mengidentifikasi aplikasi Anda.

Gambar di slide ini menunjukkan contoh banner layar utama yang mematuhi kriteria tersebut.

Kedua, di sebagian besar TV, pengguna akan berinteraksi dengan perangkat menggunakan remote D-pad.

Jadi, sangat penting bagi Anda untuk mendukung navigasi dan fokus D-pad dengan benar.

Pastikan Anda mendukung setidaknya kontrol d-pad minimum untuk menghindari penolakan berdasarkan kriteria tersebut.

Alasan umum ketiga penolakan aplikasi Android TV adalah jika Anda tidak memiliki filter intent CATEGORY_LEANBACK_LAUNCHER dalam file manifes Android.

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

Filter ini akan mengidentifikasi aplikasi Anda sebagai aplikasi yang diaktifkan untuk TV, dan memungkinkan Google Play juga mengidentifikasinya sebagai aplikasi TV bagi pengguna.

Jadi, saat pengguna memilih aplikasi Anda di layar utama TV, intent inilah yang mengidentifikasi aktivitas yang akan diluncurkan.

Jadi, pastikan Anda telah menyertakannya dalam manifes.

Android XR adalah yang berikutnya.

Saat Anda membangun aplikasi untuk headset XR atau kacamata XR yang didukung oleh Android XR, perhatikan performa, rendering, dan stabilitas aplikasi Anda.

Anda dapat menggunakan Perfetto untuk membuat profil performa aplikasi yang dibuat dengan Jetpack XR SDK guna membantu memastikan Anda mematuhi persyaratan kecepatan frame minimum.

Jika Anda membangun menggunakan mesin real-time seperti Unity, Anda dapat menggunakan alat pembuatan profil bawaan mesin tersebut yang ada di dalam mesin untuk memastikan bahwa Anda mematuhi persyaratan rendering.

Selanjutnya, kita memiliki mobil, yang terdiri dari Android Auto dan Android Automotive OS.

Untuk Android Auto dan Android Automotive OS, ada konsep kategori, yang agak unik untuk faktor bentuk khusus ini.

Hanya kategori aplikasi tertentu yang diizinkan untuk dipublikasikan ke mobil.

Jadi, jika Anda mengirimkan aplikasi ke kategori yang tidak sesuai dengan salah satu kategori yang kami dukung, atau jika Anda mengirimkan aplikasi ke pengujian terbuka atau produksi untuk kategori yang hanya dalam versi beta, aplikasi tersebut akan ditolak.

Jadi, mari kita lihat lebih detail apa yang kami maksud.

Di sini, Anda dapat melihat ringkasan kategori aplikasi yang didukung di mobil untuk setiap platform, beserta ketersediaannya.

Baik dalam versi beta, terbuka, yang berarti tersedia secara umum, atau belum didukung, yang ditunjukkan di sini dengan segera hadir.

Jadi, beberapa kategori seperti aplikasi navigasi atau lokasi menarik umumnya tersedia, dan itu berarti siapa pun dapat memublikasikan aplikasi di salah satu kategori tersebut ke produksi untuk mobil.

Namun, kategori lain seperti aplikasi panggilan komunikasi untuk Android Auto masih dalam versi beta.

Jadi, untuk kategori tersebut, Anda dapat memublikasikan ke pengujian internal atau jalur pengujian tertutup, tetapi Anda tidak dapat memublikasikan ke jalur produksi kecuali jika Anda telah diterima di salah satu program akses awal kami untuk kategori tersebut.

Anda dapat mengetahui detail selengkapnya tentang hal tersebut dan lainnya di panduan developer Android untuk Mobil.

Di sana, Anda dapat menemukan link untuk menominasikan diri Anda dalam program akses awal tersebut.

Spesifikasi yang tidak ada atau salah untuk screenshot Android Automotive OS adalah alasan umum lain yang kami lihat menyebabkan aplikasi ditolak.

Jadi, saat menyediakan screenshot Android Automotive OS, Anda harus memastikan bahwa Anda menyertakan minimal dua screenshot orientasi potret, dan minimal dua screenshot orientasi lanskap dengan dimensi yang tercantum di sini.

Anda dapat menggunakan emulator Android Automotive OS untuk membantu mengambil screenshot ini.

Alat ini disiapkan sedemikian rupa sehingga dapat mengambil screenshot dengan ukuran yang tepat sesuai kebutuhan Anda.

Terakhir, keselamatan adalah hal yang paling penting dalam aplikasi untuk mobil.

Jadi, jika aplikasi Anda tidak mematuhi pedoman gangguan bagi pengemudi, aplikasi tersebut akan ditolak.

Misalnya, aplikasi video harus menjeda pemutaran, dan tidak boleh terlihat saat kendaraan sedang bergerak.

Terakhir, kami memiliki Wear OS.

Jadi, aplikasi Wear OS dapat ditolak jika tidak dioptimalkan dan diformat untuk layar kecil dan bulat.

Jadi, sebaiknya gunakan versi stabil terbaru Compose untuk Wear OS guna memastikan konten tidak terpotong di bagian tepi pada perangkat dengan ukuran berbeda, atau, misalnya, untuk memastikan scroll bar muncul saat ada konten yang dapat di-scroll.

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

Dan seperti yang kami sebutkan untuk Android Automotive OS, aplikasi Wear OS juga dapat ditolak karena screenshot Wear OS yang tidak ada atau tidak akurat.

Berikut adalah contoh, contoh screenshot yang baik dari listingan Google Play Store untuk aplikasi contoh Androidify, dan screenshot ini memenuhi persyaratan.

Jadi, pastikan Anda mengirimkan setidaknya satu screenshot yang menampilkan aplikasi Anda berjalan di perangkat Wear OS.

Poin pentingnya?

Baca pedoman kualitas aplikasi untuk faktor bentuk spesifik Anda dan uji aplikasi berdasarkan pedoman tersebut sebelum Anda mengirimkannya.

Selain itu, ada beberapa tips penting.

Jika aplikasi Anda memerlukan login, Anda harus memberikan akun demo aktif dan kredensial yang valid di bagian akses aplikasi di Konsol Play.

Jika peninjau kami tidak dapat login, kami tidak dapat menguji aplikasi Anda dan aplikasi Anda akan otomatis ditolak.

Selain itu, pastikan untuk memenuhi janji Anda.

Jangan hanya menggunakan screenshot seluler.

Jika aplikasi Anda tersedia untuk Wear OS dan Android TV, pastikan Anda mengupload screenshot berkualitas tinggi untuk faktor bentuk spesifik tersebut di Konsol Play.

Terakhir, berikan deskripsi yang jelas.

Beri tahu pengguna dengan jelas apa yang dapat ditawarkan aplikasi, mengapa aplikasi itu berharga, dan apa yang dapat diharapkan pengguna saat mereka menginstalnya di setiap jenis perangkat.

Jadi, sebagai kesimpulan, menjangkau pengguna hampir di mana pun mereka berada adalah peluang yang luar biasa. Dengan merancang secara modular, memanfaatkan pengujian internal untuk iterasi cepat, mendesain sesuai pedoman kualitas faktor bentuk, dan mengoptimalkan listingan Play Store, Anda akan membantu menyiapkan aplikasi untuk proses peluncuran dan peninjauan yang lebih lancar.

Terima kasih banyak atas waktu Anda hari ini.

Kami tidak sabar melihat pengalaman multiperangkat luar biasa yang akan Anda hadirkan di Google Play.