Memantau kualitas teknis aplikasi dengan Android vitals

Insight baru tentang masalah dan rekomendasi kualitas aplikasi

Mulai September 2024, Anda dapat menemukan insight dan rekomendasi baru di halaman Ringkasan Android vitals serta Error dan ANR di Konsol Play untuk membantu Anda memprioritaskan masalah kualitas.

Untuk saat ini, masalah kompatibilitas aplikasi, perilaku buruk, dan beberapa rekomendasi UX ditampilkan. Kami akan terus mendeteksi dan menampilkan lebih banyak masalah kualitas serta memberikan lebih banyak rekomendasi pada tahun mendatang.

Gunakan Android vitals untuk membantu memahami dan meningkatkan stabilitas, performa, serta penggunaan baterai aplikasi, dan lain-lain.

Memilih cara mengakses data aplikasi

Ada dua cara untuk menggunakan Android vitals: melalui Konsol Play dan melalui Play Developer Reporting API.

API ini menyediakan akses terprogram ke Android vitals bagi developer yang ingin mengintegrasikan data Android vitals dengan set data lain atau menghadirkannya dalam alur kerja mereka. Untuk mempelajari lebih lanjut cara menggunakan API untuk mengakses Android vitals, buka halaman Google Play Developer Reporting API.

Untuk menemukan dan meninjau data Android vitals aplikasi Anda di Konsol Play:

1. Buka Konsol Play, lalu buka halaman Ringkasan Android vitals (Kualitas > Android Vitals > Ringkasan).
2. Pilih rentang data yang ingin Anda lihat menggunakan pemilih rentang tanggal di kanan atas.

Penting: Jika data tidak tersedia, berarti aplikasi Anda tidak memiliki cukup titik data di dalam filter yang ditentukan untuk mengidentifikasi masalah.

Memantau data vital inti aplikasi

Di bagian atas halaman Ringkasan Android vitals, Anda dapat melihat data tentang data vital inti aplikasi. Data ini merupakan metrik teknis terpenting yang memengaruhi visibilitas aplikasi Anda di Google Play. Data vital inti mencakup:

• Rasio ANR yang dirasakan pengguna
• Rasio error yang dirasakan pengguna

Google Play menentukan batas perilaku buruk pada metrik tersebut. Jika melebihi batas ini, aplikasi Anda kemungkinan akan sulit ditemukan di Google Play. Dalam kasus tertentu, peringatan dapat ditampilkan di listingan Play Store aplikasi Anda untuk menetapkan ekspektasi pengguna.

Anda dapat menggunakan bagian "Masalah kritis" untuk mengidentifikasi dengan cepat area mana saja di aplikasi Anda yang dapat diperbaiki. Ada dua jenis masalah kritis:

• Perilaku buruk: Metrik yang melampaui batas perilaku buruk
• Anomali: Perubahan data yang signifikan (misalnya, peningkatan tajam dalam rasio ANR yang dirasakan pengguna)

Untuk menerima notifikasi email, buka Penyiapan > Notifikasi atau klik Kelola notifikasi di pojok dari bagian "Data vital inti" (Kualitas > Android vitals > Ringkasan). Perhatikan bahwa notifikasi tersebut saat ini hanya tersedia untuk anomali.

Mempelajari semua fitur vitals

Di dekat bagian tengah halaman Ringkasan Android vitals, Anda dapat melihat semua data vitals menurut aspek kualitasnya.

Dalam tabel, Anda dapat meninjau metrik untuk jangka waktu saat ini dan sebelumnya. Anda juga dapat melihat perbandingan aplikasi Anda dengan aplikasi lain di Google Play.

Melihat metrik secara mendetail

Untuk detail lainnya tentang metrik, pilih Lihat detail () di sampingnya. Di layar berikutnya, Anda dapat meninjau:

• Batas perilaku buruk
• Tolok ukur kategori
• Detail perbandingan tolok ukur
  • Di dekat bagian atas halaman, pada kartu perbandingan pembanding, pilih Edit grup pembanding untuk mengedit grup pembanding kustom. Setelah membuat grup pembanding kustom, Anda dapat melihat perbandingan aplikasi Anda dengan aplikasi lain di Google Play yang Anda pilih.
• Tren metrik dari waktu ke waktu

Menganalisis data dengan dimensi

Untuk membantu mengatur, menyegmentasikan, dan menganalisis data, metrik Anda dikelompokkan menurut sejumlah dimensi yang berbeda. Semua metrik memiliki pengelompokan berikut:

• Artefak: Versi aplikasi Anda tempat masalah terjadi
• Versi Android (SDK): Versi OS Android yang dilaporkan oleh perangkat pengguna
• Faktor bentuk: Jenis perangkat tempat aplikasi dijalankan (misalnya, Ponsel, Tablet, TV, Wearable)
• Model perangkat: Deskripsi perangkat yang sangat terperinci, yang terdiri dari merek dan ID perangkat unik, misalnya, "Google oriole". Model perangkat tunggal mungkin memiliki varian dengan versi Android, RAM, penyimpanan, atau Sistem di Chip (SoC) yang berbeda.
• Negara/wilayah: Lokasi yang dilaporkan oleh perangkat pengguna pada saat masalah terjadi

Tips: Untuk pengelompokan berdasarkan aspek tertentu dari hardware atau software perangkat (misalnya, model perangkat atau versi Android), Anda dapat mengklik simbol () di samping item dalam tabel.

Beberapa metrik memiliki pengelompokan tambahan:

• Nama penguncian layar saat aktif: Tag yang ditetapkan secara terprogram saat menggunakan PowerManager API di aplikasi Anda
• Nama bangun: Tag yang ditetapkan secara terprogram saat menggunakan AlarmManager API di aplikasi Anda
• Nama aktivitas ANR: Nama yang sepenuhnya memenuhi syarat dari class aktivitas tempat ANR terjadi (jika tersedia)
• Jenis ANR: Saat ANR terjadi (misalnya, saat mengeksekusi layanan) (jika tersedia)

Anda dapat melihat detail selengkapnya jika tersedia (misalnya, cluster error atau ANR yang terkait dengan pengelompokan tersebut) dengan memilih Lihat detail () di samping item.

Tips: Anda dapat beralih antarmetrik dalam satu kategori menggunakan tombol di bagian atas layar, dan memfilter halaman.

Jenis data dan metrik

Data Android vitals untuk 90 hari sebelumnya tersedia di Konsol Play. Data tersebut juga tersedia untuk tiga tahun di Play Developer Reporting API.

Data dikumpulkan dari pengguna yang telah memilih untuk membagikan data penggunaan dan diagnostik secara otomatis dari subset perangkat Android dan versi OS. Untuk mengetahui informasi selengkapnya tentang cara pengguna Android memilih untuk membagikan data, buka Pusat Bantuan Akun.

Android vitals diperbarui setiap hari. Terkadang, data untuk perangkat Android 10 dan yang lebih baru dapat dikirim lebih awal daripada data untuk perangkat di bawah Android 10. Jika hal ini terjadi, Anda hanya akan melihat data Android 10 dan yang lebih baru pada hari ketika data tersedia.

Catatan: Metrik Android vitals mengecualikan masalah teknis yang terjadi di model perangkat yang tidak tersertifikasi, atau di versi aplikasi Anda yang tidak diinstal melalui Google Play.

Ciutkan Semua Luaskan Semua

Stabilitas

Metrik rasio ANR

Metrik rasio ANR memberikan ringkasan kualitas aplikasi Anda. Metrik ini dihitung dengan mengambil jumlah pengguna yang mengalami ANR dan menormalisasi jumlah tersebut berdasarkan penggunaan aplikasi Anda. Metrik ini dilaporkan sebagai persentase pengguna aktif harian. Pengguna aktif harian ditentukan sebagai pengguna yang menggunakan aplikasi dalam satu hari di satu perangkat. Jika pengguna menggunakan aplikasi Anda di lebih dari satu perangkat dalam satu hari, setiap perangkat akan berkontribusi pada jumlah pengguna aktif untuk hari tersebut. Jika beberapa pengguna menggunakan perangkat yang sama dalam satu hari, ini akan dihitung sebagai satu pengguna aktif.

Ada tiga metrik rasio ANR:

• Rasio ANR yang dirasakan pengguna: Persentase pengguna aktif harian yang mengalami setidaknya satu ANR yang dirasakan pengguna. ANR yang dirasakan pengguna adalah ANR yang kemungkinan telah diketahui oleh pengguna. Saat ini, hanya ANR "waktu pengiriman input habis" yang akan dihitung. Metrik ini akan selalu lebih rendah dari rasio ANR Anda secara keseluruhan, karena dinormalisasi berdasarkan penggunaan harian, tetapi tidak menghitung semua ANR.
  Rasio ANR yang dirasakan pengguna merupakan data vital inti, yang berarti rasio ini memengaruhi visibilitas aplikasi Anda di Google Play. Rasio ini penting karena ANR yang dihitung selalu terjadi saat pengguna berinteraksi dengan aplikasi, sehingga paling banyak menyebabkan gangguan.
• Rasio ANR: Persentase pengguna harian yang mengalami setidaknya satu ANR. Metrik ini mencakup ANR yang tidak diklasifikasikan sebagai ANR yang dirasakan pengguna, tetapi kami tidak dapat menjamin bahwa ANR ini tidak memengaruhi pengguna.
• Rasio multi-ANR: Persentase pengguna harian yang mengalami setidaknya dua ANR. Metrik ini membantu menandai loop masalah.

Memperbaiki masalah

ANR yang berkontribusi pada metrik rasio ANR Anda dilaporkan di halaman Error dan ANR. Di halaman ini, Anda dapat memfilter ANR yang dirasakan pengguna.

Situs Android Developers menyediakan panduan untuk mendiagnosis dan memperbaiki ANR.

Metrik rasio error

Metrik rasio error memberikan ringkasan kualitas aplikasi Anda. Metrik ini dihitung dengan mengambil jumlah pengguna yang mengalami error dan menormalisasi jumlah tersebut berdasarkan penggunaan aplikasi Anda. Metrik ini dilaporkan sebagai persentase pengguna harian. Pengguna harian ditentukan sebagai pengguna yang menggunakan aplikasi dalam satu hari di satu perangkat. Jika pengguna memiliki lebih dari satu perangkat, pengguna tersebut akan dihitung lebih dari sekali. Misalnya, jika dua pengguna menggunakan aplikasi selama dua hari di satu perangkat masing-masing, berarti empat sesi harian akan dihasilkan.

Ada tiga metrik rasio error:

• Rasio error yang dirasakan pengguna: Persentase pengguna harian yang mengalami setidaknya satu error yang dirasakan pengguna. Error yang dirasakan pengguna adalah error yang kemungkinan telah diketahui oleh pengguna. Misalnya, error yang terjadi saat aplikasi Anda menampilkan aktivitas atau berjalan sebagai layanan latar depan. Metrik ini akan selalu lebih rendah dari rasio error Anda secara keseluruhan, karena metrik ini dinormalisasi berdasarkan penggunaan harian, tetapi tidak menghitung semua error.
  Rasio error yang dirasakan pengguna merupakan data vital inti, yang berarti rasio ini memengaruhi visibilitas aplikasi Anda di Google Play. Rasio ini penting karena error yang dihitung selalu terjadi saat pengguna berinteraksi dengan aplikasi, sehingga paling banyak menyebabkan gangguan. Oleh karena itu, Anda harus memastikan bahwa aplikasi Anda tidak melebihi batas perilaku buruk untuk metrik ini.

• Rasio error: Persentase pengguna harian yang mengalami setidaknya satu error. Metrik ini mencakup error yang tidak diklasifikasikan sebagai error yang dirasakan pengguna, tetapi kami tidak dapat menjamin bahwa error ini tidak memengaruhi pengguna.

• Rasio multi-error: Persentase pengguna harian yang mengalami setidaknya dua error. Metrik ini membantu menandai loop masalah.

Memperbaiki masalah

Situs Android Developers menyediakan panduan untuk mendiagnosis dan memperbaiki error.

Waktu mulai dan waktu pemuatan

Waktu mulai (waktu hingga tampilan awal)

Di halaman Waktu mulai, Anda dapat melihat detail waktu kapan aplikasi dimulai secara perlahan dari status sistem cold, warm, dan hot. Waktu mulai mengukur waktu yang diperlukan dari saat pengguna meluncurkan aplikasi Anda, hingga saat frame pertama muncul di layar. Hal ini juga disebut dengan 'waktu hingga tampilan awal'.

Aplikasi Anda mungkin belum siap untuk memulai interaksi dengan pengguna setelah waktu ini, misalnya jika aplikasi Anda memiliki layar pemuatan tambahan.

Detail pengumpulan data

• Waktu mulai hanya direkam saat pengguna memicu suatu aktivitas.
  • Contoh: Untuk aplikasi keyboard, waktu mulainya sama dengan waktu mulai aplikasi pendamping.
• Jika aplikasi dimulai beberapa kali pada hari yang sama dari status sistem yang sama, waktu mulai maksimum pada hari tersebut akan direkam.
• Waktu mulai dilacak saat frame pertama aplikasi dimuat sepenuhnya, meskipun bukan layar yang digunakan pengguna untuk berinteraksi.
  • Contoh: Jika aplikasi dimulai dengan layar pembuka, waktu mulainya sama dengan waktu yang diperlukan untuk menampilkan layar pembuka.

Detail vital

• Sesi yang terdampak: Persentase sesi ketika pengguna mengalami waktu mulai yang lambat untuk setiap status sistem:
  • Start cold lambat: 5 detik atau lebih
  • Start warm lambat: 2 detik atau lebih
  • Start hot lambat: 1 detik atau lebih
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 10%/1% sesi harian ketika pengguna mengalami waktu mulai aplikasi yang lambat untuk aplikasi Anda.

Memperbaiki masalah

Jika aplikasi Anda memiliki jumlah waktu mulai lambat yang tinggi, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Rendering

Semua rendering

Kecepatan sesi lambat (30 FPS atau 20 FPS) [khusus game]

Mengapa ini penting

Dengan sesi lambat, Anda dapat memahami performa kecepatan frame game, yang memengaruhi kelancaran dan keseruan game saat dimainkan pengguna.

Memahami data aplikasi

Di halaman Sesi lambat, Anda akan melihat detail persentase sesi harian ketika pengguna mengalami lebih dari 25% frame yang berjalan lebih lambat dari 30 FPS atau 20 FPS, bergantung pada benchmark yang Anda pilih. Anda juga dapat melihat distribusi sesi berdasarkan kecepatan frame untuk game Anda. (Kecepatan frame tingkat sesi diukur pada persentil ke-75, yang berarti bahwa 75% frame mencapai setidaknya kecepatan frame ini.)

Sebagian besar game di Google Play harus menargetkan 30 FPS atau lebih tinggi. Hal ini memberikan pengalaman yang wajar bagi pengguna, apa pun jenis game yang mereka mainkan (meskipun beberapa pengguna akan lebih memilih setidaknya 60 FPS, terutama di perangkat yang lebih canggih). Pantau metrik kecepatan sesi lambat (30 FPS) untuk memastikan Anda mencapai standar ini. Perlu diingat bahwa metrik ini hanya menyertakan sesi ketika lebih dari 25% frame tidak mencapai 30 FPS, sehingga memiliki toleransi terhadap variabilitas kecepatan frame.

Meskipun 30 FPS memberikan pengalaman yang wajar, mungkin ada waktu atau jenis game yang sebaiknya menurunkan kecepatan frame di bawah ini, atau ada baiknya pengguna memainkan game Anda di ponsel yang tidak dapat mendukung 30 FPS. Dalam skenario ini, setidaknya 75% frame dalam satu sesi tetap harus mencapai 20 FPS atau lebih tinggi. Pantau metrik kecepatan sesi lambat (20 FPS) untuk memastikan Anda memenuhi standar ini.

Android vitals melaporkan sesi lambat (30 FPS) dan sesi lambat (20 FPS) untuk setiap perangkat serta di semua perangkat dan sesi. Gunakan metrik secara keseluruhan untuk memahami pengalaman pengguna secara keseluruhan, tetapi perhatikan juga performa per perangkat. Pada waktunya, Play akan mulai mengalihkan pengguna dari game yang tidak dapat mencapai 20 FPS di ponsel mereka.

Vitals hanya memulai pemantauan kecepatan frame setelah game berjalan selama 1 menit.

Detail pengumpulan data

Metrik sesi lambat dihitung dengan data yang dikumpulkan dari SurfaceFlinger. Lebih jelasnya, kecepatan frame sesi diperkirakan berdasarkan waktu antara frame yang dirender di platform yang dimiliki aplikasi, dan mencakup frame yang dirender oleh OpenGL, Vulkan, serta toolkit UI Android. Metrik ini saat ini hanya tersedia untuk game.

Data kecepatan frame untuk Sesi Lambat dikumpulkan untuk perangkat yang menjalankan Android 9 dan lebih baru.

Tampilan dasbor

• Kecepatan frame representatif: Performa kecepatan frame game di perangkat dengan Android 9 atau lebih baru, dihitung pada persentil ke-75. Artinya, 75% sesi memiliki kecepatan frame ini atau lebih cepat 75% dari waktu tersebut.
• Kecepatan sesi lambat dari waktu ke waktu: Deret waktu yang menampilkan persentase sesi yang ditentukan sebagai Sesi lambat.
• Distribusi kecepatan frame: Histogram yang menunjukkan kecepatan frame persentil ke-75 di seluruh sesi. Artinya, 75% frame dalam suatu sesi lebih cepat daripada kecepatan frame yang digunakan untuk mengelompokkan sesi.

Memperbaiki masalah

Jika jumlah Sesi lambat aplikasi Anda tinggi, buka situs developer Android untuk mendapatkan solusi yang direkomendasikan.

Rendering toolkit UI Android

Frame lambat berlebihan [khusus aplikasi]

Memahami data aplikasi

Di halaman Frame lambat berlebihan, Anda akan melihat detail persentase sesi harian ketika pengguna mengalami lebih dari 50% frame yang melampaui batas waktu rendering perangkat. Interaksi pengguna dengan aplikasi Anda sebaiknya berjalan pada 60 frame per detik tanpa penurunan atau penundaan.

Detail pengumpulan data

Google mengumpulkan waktu render setiap frame yang dirender oleh aplikasi saat menggunakan framework Toolkit UI. Frame yang dirender menggunakan OpenGL atau Vulkan secara langsung tidak dikumpulkan datanya.

Tampilan dasbor

Saat memilih salah satu baris, Anda akan melihat data yang diuraikan menjadi beberapa persentil.

• Sesi yang terdampak: Persentase sesi harian ketika pengguna mengalami lebih dari 50% frame yang waktu rendernya melebihi 16 milidetik. Sesi harian mengacu pada satu hari ketika aplikasi Anda digunakan. Misalnya, jika dua pengguna menggunakan aplikasi selama dua hari, berarti empat sesi harian akan dihasilkan.
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 90%/99% total frame memiliki waktu render yang lebih rendah dari jumlah yang ditampilkan. Jumlah ini didasarkan pada semua frame yang dikumpulkan.

Saat mengklik entri dalam tabel, Anda akan melihat diagram 'Distribusi waktu render UI'. Saat meninjau diagram, Anda harus memastikan bahwa sebagian besar frame aplikasi Anda berada pada atau di bawah 16 milidetik.

Data di bawah diagram menunjukkan performa rendering aplikasi dan dapat membantu menemukan penyebab utama masalah waktu render. Misalnya, jika persentase 'Latensi input tinggi' cukup tinggi, coba lihat kode aplikasi yang menangani input pengguna. Untuk informasi selengkapnya tentang metrik ini, buka menguji performa UI.

• Vsyncs yang terlewat: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah peristiwa Vsync yang terlewat dibagi jumlah frame.
• Latensi input tinggi: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah peristiwa input yang perlu waktu lebih dari 24 milidetik dibagi jumlah frame.
• UI thread lambat: Untuk semua frame yang dirender selama lebih dari 16 milidetik, jumlah peristiwa penyelesaian UI thread yang perlu waktu lebih dari 8 milidetik dibagi jumlah frame.
• Perintah render lambat: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah waktu yang dibutuhkan saat mengirimkan perintah render ke GPU lebih dari 12 milidetik dibagi jumlah frame.
• Upload bitmap lambat: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah waktu yang dibutuhkan saat mengupload bitmap ke GPU lebih dari 3,2 milidetik dibagi dengan jumlah frame.

Memperbaiki masalah

Jika frame dengan waktu render lebih dari 16 milidetik jumlahnya tinggi di aplikasi Anda, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Periode frozen berlebihan [khusus aplikasi]

Memahami data aplikasi

Di halaman Frame lambat berlebihan, Anda akan melihat detail persentase sesi harian ketika pengguna mengalami lebih dari 50% frame yang melampaui batas waktu rendering perangkat. Interaksi pengguna dengan aplikasi Anda sebaiknya berjalan pada 60 frame per detik tanpa penurunan atau penundaan.

Detail pengumpulan data

Google mengumpulkan waktu render setiap frame yang dirender oleh aplikasi saat menggunakan framework Toolkit UI. Frame yang dirender menggunakan OpenGL atau Vulkan secara langsung tidak dikumpulkan datanya.

Tampilan dasbor

Saat memilih salah satu baris, Anda akan melihat data yang diuraikan menjadi beberapa persentil.

• Sesi yang terdampak: Persentase sesi harian ketika pengguna mengalami lebih dari 50% frame yang waktu rendernya melebihi 16 milidetik. Sesi harian mengacu pada satu hari ketika aplikasi Anda digunakan. Misalnya, jika dua pengguna menggunakan aplikasi selama dua hari, berarti empat sesi harian akan dihasilkan.
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 90%/99% total frame memiliki waktu render yang lebih rendah dari jumlah yang ditampilkan. Jumlah ini didasarkan pada semua frame yang dikumpulkan.

Saat mengklik entri dalam tabel, Anda akan melihat diagram 'Distribusi waktu render UI'. Saat meninjau diagram, Anda harus memastikan bahwa sebagian besar frame aplikasi Anda berada pada atau di bawah 16 milidetik.

Data di bawah diagram menunjukkan performa rendering aplikasi dan dapat membantu menemukan penyebab utama masalah waktu render. Misalnya, jika persentase 'Latensi input tinggi' cukup tinggi, coba lihat kode aplikasi yang menangani input pengguna. Untuk informasi selengkapnya tentang metrik ini, buka menguji performa UI.

• Vsyncs yang terlewat: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah peristiwa Vsync yang terlewat dibagi jumlah frame.
• Latensi input tinggi: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah peristiwa input yang perlu waktu lebih dari 24 milidetik dibagi jumlah frame.
• UI thread lambat: Untuk semua frame yang dirender selama lebih dari 16 milidetik, jumlah peristiwa penyelesaian UI thread yang perlu waktu lebih dari 8 milidetik dibagi jumlah frame.
• Perintah render lambat: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah waktu yang dibutuhkan saat mengirimkan perintah render ke GPU lebih dari 12 milidetik dibagi jumlah frame.
• Upload bitmap lambat: Untuk semua frame yang dirender lebih dari 16 milidetik, jumlah waktu yang dibutuhkan saat mengupload bitmap ke GPU lebih dari 3,2 milidetik dibagi dengan jumlah frame.

Memperbaiki masalah

Jika frame dengan waktu render lebih dari 16 milidetik jumlahnya tinggi di aplikasi Anda, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Penggunaan baterai

Penguncian layar bermasalah dan penguncian layar saat aktif parsial bermasalah (latar belakang)

Halaman Penguncian layar saat aktif parsial bermasalah dan Penguncian layar saat aktif parsial bermasalah (latar belakang) menampilkan penguncian layar saat aktif parsial yang diperoleh aplikasi Anda melalui class PowerManager. Penguncian layar saat aktif parsial memastikan CPU berjalan, tetapi lampu latar keyboard dan layar boleh dimatikan.

Detail pengumpulan data

• Untuk tujuan privasi, tag identifikasi penguncian layar saat aktif parsial akan dianonimkan.
• Data penguncian layar saat aktif parsial dikumpulkan saat perangkat sedang tidak diisi daya dan layarnya mati.
• Data penguncian layar saat aktif parsial bermasalah (latar belakang) hanya dikumpulkan saat aplikasi berjalan di latar belakang.
• Google menghitung durasi penguncian layar saat aktif parsial maksimal per sesi baterai untuk menampilkan berapa banyak sesi yang terkena dampak oleh penguncian layar saat aktif yang lama. Misalnya, jika pengguna memicu fitur penguncian layar saat aktif selama dua jam, Google akan menggunakan nilai fitur tersebut maksimal selama satu jam.
• Untuk aplikasi yang menetapkan sharedUserId dalam file manifes: Anda hanya akan melihat data jika maksimum satu aplikasi dengan sharedUserId yang sama diinstal.

Detail vital

• Sesi yang terkena dampak: Persentase sesi baterai ketika pengguna mengalami setidaknya satu penguncian layar saat aktif selama lebih dari satu jam.
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 10%/1% sesi harian ketika pengguna mengalami penguncian layar saat aktif parsial yang durasinya melebihi jumlah yang ditampilkan.
• Batas perilaku buruk: Jika aplikasi Anda menunjukkan rasio kemunculan yang sama dengan atau lebih tinggi dari batas yang ditampilkan, aplikasi termasuk dalam 25% terbawah dari 1.000 aplikasi teratas di Google Play (berdasarkan jumlah instal).

Memperbaiki masalah

Jika aplikasi Anda memiliki penguncian layar saat aktif parsial yang bermasalah dalam jumlah tinggi, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Bangun berlebihan

Halaman Bangun berlebihan menampilkan jumlah bangun Pengelola Alarm yang dipicu oleh aplikasi. Anda akan melihat data jumlah bangun untuk class ELAPSED_REALTIME_WAKEUP atau RTC_WAKEUP.

Detail pengumpulan data

• Untuk tujuan privasi, tag identifikasi bangun akan dianonimkan.
• Data bangun dikumpulkan saat perangkat sedang tidak diisi daya.
• Untuk menyediakan metrik yang dinormalisasi, jumlah bangun akan dibandingkan dengan waktu ketika perangkat menggunakan baterai. Google menghitung jumlah bangun per pengguna setiap jam untuk menampilkan jumlah pengguna yang terdampak oleh rasio bangun yang tinggi.
• Untuk aplikasi yang menetapkan sharedUserId dalam file manifes: Anda hanya akan melihat data jika maksimum satu aplikasi dengan sharedUserId yang sama diinstal.

Detail vital

• Sesi yang terkena dampak: Persentase sesi baterai ketika pengguna mengalami lebih dari 10 kali bangun per jam. Sesi baterai adalah gabungan dari semua laporan baterai yang diterima dalam periode 24 jam yang ditentukan. Di Android 10, laporan baterai mengacu pada interval antara dua pengisian daya baterai, baik dari bawah 20% hingga di atas 80%, atau dari setiap nilai hingga 100%. Di Android 11 dan yang lebih baru, laporan baterai mengacu pada periode tetap 24 jam. Google hanya mengumpulkan data ketika perangkat sedang tidak mengisi daya.
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 10%/1% sesi harian ketika pengguna mengalami bangun per jam yang lebih besar dari nilai yang ditampilkan.
• Batas perilaku buruk: Jika aplikasi Anda menunjukkan rasio kemunculan yang sama dengan atau lebih tinggi dari batas yang ditampilkan, aplikasi termasuk dalam 25% terbawah dari 1.000 aplikasi teratas di Google Play (berdasarkan jumlah instal).

Memperbaiki masalah

Jika aplikasi Anda sering bangun, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Pemindaian Wi-Fi berlebihan (latar belakang)

Halaman Pemindaian Wi-Fi berlebihan (background) ditampilkan saat pemindaian Wi-Fi berakibat pada penggunaan baterai yang tinggi.

Detail pengumpulan data

Data tentang pemindaian Wi-Fi dikumpulkan saat perangkat sedang tidak diisi dayanya dan aplikasi berada di latar belakang.

Detail vital

• Sesi yang terdampak: Persentase sesi baterai ketika pengguna mengalami lebih dari 4 kali pemindaian Wi-Fi per jam.
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 10%/1% sesi harian ketika pengguna mengalami pemindaian Wi-Fi per jam di latar belakang lebih dari jumlah yang ditampilkan.

Memperbaiki masalah

Jika aplikasi mengalami jumlah pemindaian Wi-Fi background yang tinggi, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Penggunaan jaringan berlebihan (latar belakang)

Halaman Penggunaan jaringan berlebihan menunjukkan waktu ketika sejumlah besar data jaringan dikaitkan dengan layanan latar belakang. Ketika penggunaan jaringan seluler terjadi di background, pengguna tidak memiliki akses mudah ke kontrol untuk menghentikan transfer data.

Detail pengumpulan data

Data tentang penggunaan jaringan seluler dikumpulkan saat perangkat sedang tidak diisi dayanya dan aplikasi berada di latar belakang.

Detail vital

• Sesi yang terdampak: Persentase sesi baterai ketika pengguna mengalami lebih dari 50 MB penggunaan jaringan di latar belakang per hari.
• Jumlah sesi: Perkiraan jumlah sesi yang direkam.
• Persentil ke-90/ke-99: 10%/1% sesi harian ketika pengguna mengalami penggunaan jaringan harian di latar belakang yang lebih besar dari jumlah yang ditampilkan.

Memperbaiki masalah

Jika aplikasi Anda mengalami penggunaan jaringan latar belakang yang tinggi, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Izin

Penolakan izin

Di halaman Penolakan izin, Anda dapat melihat detail tentang persentase sesi izin harian saat pengguna menolak izin. Sesi izin harian mengacu pada satu hari ketika aplikasi meminta setidaknya satu izin dari penggunanya.

Detail pengumpulan data

Data tentang penolakan izin dikumpulkan saat pengguna merespons permintaan izin dalam aplikasi Anda.

Detail vital

• Penolakan:Persentase sesi izin harian saat pengguna menolak izin.
• Jangan tanya lagi: Persentase sesi izin harian ketika pengguna menolak izin dengan memilih Jangan tanya lagi.
• Total sesi: Perkiraan jumlah sesi yang direkam.

Memperbaiki masalah

Jika jumlah penolakan izin di aplikasi Anda tinggi, buka situs Android Developers untuk mendapatkan solusi yang direkomendasikan.

Batas perilaku buruk untuk data vital inti

Google Play telah menentukan batas perilaku buruk untuk data vital inti aplikasi Anda.

Jika melampaui batas perilaku buruk, aplikasi Anda kemungkinan akan sulit ditemukan di Google Play. Jika aplikasi Anda berperilaku buruk di model perangkat tertentu, pengguna di perangkat ini yang menggunakan aplikasi Anda akan dialihkan Google Play ke aplikasi lain yang lebih cocok untuk mereka. Dalam kasus tertentu, peringatan mungkin ditampilkan di listingan Play Store aplikasi Anda untuk menetapkan ekspektasi pengguna, serta memberikan opsi untuk mencari alternatif dengan kualitas teknis yang lebih tinggi.

Google Play biasanya akan mempertimbangkan data selama 28 hari terakhir saat mengevaluasi kualitas aplikasi Anda, tetapi mungkin akan bertindak lebih cepat jika terjadi lonjakan.

Ciutkan Semua Luaskan Semua

Stabilitas

Batas perilaku buruk untuk rasio ANR yang dirasakan pengguna

Google Play telah menentukan batas perilaku buruk untuk rasio ANR yang dirasakan pengguna:

• Perilaku buruk secara keseluruhan: Setidaknya 0,47% pengguna aktif harian mengalami ANR yang dirasakan pengguna di semua model perangkat.

• Perilaku buruk per perangkat: Setidaknya 8% pengguna aktif harian mengalami ANR yang dirasakan pengguna untuk satu model perangkat.

Untuk memperbaiki rasio ANR Anda, perbaiki cluster ANR yang mendasarinya yang dilaporkan di halaman Error dan ANR. Semakin tinggi jumlah pengguna yang terpengaruh, semakin banyak cluster yang berkontribusi pada rasio ANR Anda.

Android vitals akan memberikan notifikasi jika aspek tertentu dari hardware atau software perangkat mungkin berkontribusi pada rasio ANR Anda. Anda juga dapat menjelajahi sendiri pengaitan di halaman Ringkasan jangkauan dan perangkat (Rilis > Jangkauan dan perangkat > Ringkasan).

Batas perilaku buruk untuk rasio error yang dirasakan pengguna

Google Play telah menentukan batas perilaku buruk untuk rasio error yang dirasakan pengguna:

• Perilaku buruk secara keseluruhan: Setidaknya 1,09% pengguna harian mengalami error yang dirasakan pengguna, di semua model perangkat.

• Perilaku buruk per perangkat: Setidaknya 8% pengguna harian mengalami error yang dirasakan pengguna, untuk satu model perangkat.

Untuk memperbaiki rasio error, perbaiki cluster error yang mendasarinya yang dilaporkan di halaman Error dan ANR. Semakin tinggi jumlah pengguna yang terpengaruh, semakin banyak cluster yang berkontribusi pada rasio error Anda.

Android vitals akan memberikan notifikasi jika aspek tertentu dari hardware atau software perangkat mungkin berkontribusi pada rasio error Anda. Anda juga dapat menjelajahi sendiri hubungan ini di halaman Ringkasan jangkauan dan perangkat (Rilis > Jangkauan dan perangkat > Ringkasan).

Konten terkait

Temukan praktik terbaik untuk menggunakan Android vitals guna meningkatkan performa dan stabilitas aplikasi Anda.