Log perubahan Dokumen Definisi Kompatibilitas Android

Android 14

8 April 2024

2. Jenis Perangkat

• 2.2.1. Perangkat keras :

  Lihat revisi

  Mulai persyaratan baru

  Jika implementasi perangkat Genggam menyatakan FEATURE_BLUETOOTH_LE , implementasi tersebut:

  • [ 7.4 .3/H-1-3] HARUS mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB pada jarak 1m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH .
  • [ 7.4 .3/H-1-4] HARUS mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH .

• 2.2.5. Model Keamanan :

  Lihat revisi

  Jika implementasi perangkat Genggam mendukung System API HotwordDetectionService atau mekanisme lain untuk deteksi kata cepat tanpa indikasi akses mikrofon, maka implementasi tersebut:

  • [9.8/H-1-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data dikirim keluar dari layanan deteksi kata cepat pada setiap hasil kata cepat yang berhasil kecuali untuk data audio yang melewati HotwordAudioStream .

  Lihat revisi

  Ubah [9.8/H-1-13] menjadi:

  • [9.8/H-SR-3] SANGAT DIREKOMENDASIKAN untuk memulai ulang proses yang menghosting layanan deteksi kata cepat setidaknya sekali setiap jam atau setiap 30 peristiwa pemicu perangkat keras, mana saja yang lebih dulu.

  Lihat revisi

  Persyaratan yang dihapus [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

• 2.2.7.2. Kamera :

  Lihat revisi

  Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.U untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , maka implementasi tersebut:

  • [ 7.5 /H-1-3] HARUS mendukung properti android.info.supportedHardwareLevel sebagai FULL atau lebih baik untuk kamera utama belakang dan LIMITED atau lebih baik untuk kamera utama depan.

• 2.3.2. Multimedia :

  Lihat revisi

  Jika implementasi perangkat Televisi tidak memiliki layar internal, namun mendukung layar eksternal yang tersambung melalui HDMI, perangkat tersebut:

  • [ 5.8 /T-0-1] HARUS mengatur mode output HDMI ke resolusi tertinggi untuk format piksel yang dipilih yang berfungsi dengan kecepatan refresh 50Hz atau 60Hz untuk layar eksternal, tergantung pada kecepatan refresh video untuk wilayah perangkat tersebut dijual masuk. HARUS mengatur mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50Hz atau 60Hz.

3. Perangkat Lunak

• 3.5.1. Batasan Aplikasi :

  Lihat revisi

  • Persyaratan yang dihapus [C-1-9]

5. Kompatibilitas Multimedia

• 5.3.8. Visi Dolby :

  Lihat revisi

  Jika penerapan perangkat mendeklarasikan dukungan untuk dekoder Dolby Vision melalui HDR_TYPE_DOLBY_VISION , penerapan tersebut:

  • [C-1-3] HARUS mengatur ID track dari lapisan dasar yang kompatibel ke belakang (jika ada) agar sama dengan ID track gabungan lapisan Dolby Vision.

7. Kompatibilitas Perangkat Keras

• 7.1.1.1. Ukuran dan Bentuk Layar :

  Lihat revisi

  Jika implementasi perangkat mendukung layar yang mampu melakukan konfigurasi ukuran UI_MODE_TYPE_NORMAL dan menggunakan tampilan fisik dengan sudut membulat untuk merender layar ini, maka implementasi tersebut:

  • [C-1-1] HARUS memastikan bahwa setidaknya satu dari persyaratan berikut terpenuhi untuk setiap tampilan tersebut:
    • Ketika kotak berukuran 15 dan 18 dp kali 15 18 dp dipasang di setiap sudut tampilan logis, setidaknya satu piksel dari setiap kotak terlihat di layar.

• 7.4.3. Bluetooth :

  Lihat revisi

  Menerapkan kembali persyaratan berikut:

  Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE , implementasi tersebut:

  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -60dBm +/-10 dB pada jarak 1m dari perangkat referensi yang bertransmisi pada ADVERTISE_TX_POWER_HIGH , di mana perangkat diorientasikan sedemikian rupa sehingga pada 'bidang paralel' dengan layar menghadap ke arah yang sama.

  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -60dBm +/-10 dB ketika memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH , di mana perangkat berorientasi sedemikian rupa sehingga mereka berada pada 'bidang paralel' dengan layar menghadap ke arah yang sama.

  Lihat revisi

  Persyaratan [C-10-3] dan [C-10-4] dipindahkan ke 2.2.1. Perangkat keras .

  • [C-10-3] HARUS mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -55dBm +/-10 dB pada jarak 1m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH .
  • [C-10-4] HARUS mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -55dBm +/-10 dB ketika memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH .

20 November 2023

2. Jenis Perangkat

• 2.2.1. Perangkat keras :

  Lihat revisi

  Jika implementasi perangkat Genggam menyatakan dukungan terhadap ABI 64-bit (dengan atau tanpa ABI 32-bit):

• 2.2.7.2. Kamera :

  Lihat revisi

  • [ 7.5 /H-1-13] HARUS mendukung kemampuan LOGICAL_MULTI_CAMERA untuk kamera belakang utama jika terdapat lebih dari 1 kamera belakang RGB.

• 2.3.2. Multimedia :

  Lihat revisi

  • [ 5.8 /T-0-1] HARUS mengatur mode output HDMI ke resolusi tertinggi untuk format SDR atau HDR yang dipilih yang berfungsi dengan kecepatan refresh 50Hz atau 60Hz untuk layar eksternal.

    HARUS mengatur mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50Hz atau 60Hz.

• 2.4.5. Model Keamanan :

  Lihat revisi

  • [9/W-0-1] HARUS mendeklarasikan android.hardware.security.model.compatible feature .

6. Kompatibilitas Alat Pengembang dan Opsi

• 6.1. Alat pengembang :

  Lihat revisi

  • [C-0-12] HARUS menulis Atom LMK_KILL_OCCURRED_FIELD_NUMBER ke

  Lihat revisi

  • [C-0-13] HARUS mengimplementasikan perintah shell dumpsys gpu --gpuwork untuk ditampilkan

9. Kompatibilitas Model Keamanan

• 9.7. Fitur keamanan :

  Lihat revisi

  Jika implementasi perangkat menggunakan kernel Linux yang mampu mendukung SELinux, maka:

  Lihat revisi

  Jika implementasi perangkat menggunakan kernel selain Linux atau Linux tanpa SELinux, maka:

4 Oktober 2023

2. Jenis Perangkat

• 2.2. Persyaratan Genggam :

  Lihat revisi

  Implementasi perangkat Android diklasifikasikan sebagai Genggam jika memenuhi seluruh kriteria berikut:

  • Memiliki ukuran layar diagonal fisik dalam kisaran 4 inci 3,3 inci (atau 2,5 inci untuk implementasi perangkat yang dikirimkan pada API level 29 atau lebih lama) hingga 8 inci.

  Mulai persyaratan baru

  • Memiliki antarmuka input layar sentuh.

• 2.2.1. Perangkat keras :

  Lihat revisi

  Implementasi perangkat genggam:

  • [ 7.1 .1.1/H-0-1] HARUS memiliki setidaknya satu tampilan yang kompatibel dengan Android yang memenuhi semua persyaratan yang dijelaskan dalam dokumen ini. layar yang berukuran setidaknya 2,2” pada tepi pendek dan 3,4” pada tepi panjang.

  Jika implementasi perangkat Genggam mendukung rotasi layar perangkat lunak, maka:

  • [ 7.1 .1.1/H-1-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga berukuran minimal 2 inci pada tepi pendek dan 2,7 inci pada tepi panjang. Perangkat yang dikirimkan pada Android API level 29 atau lebih lama MUNGKIN dikecualikan dari persyaratan ini.

  Jika implementasi perangkat Genggam tidak mendukung rotasi layar perangkat lunak, maka:

  • [ 7.1 .1.1/H-2-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga setidaknya berukuran 2,7 inci pada tepi pendeknya. Perangkat yang dikirimkan pada Android API level 29 atau lebih lama MUNGKIN dikecualikan dari persyaratan ini.

  Mulai persyaratan baru

  • [ 7.1 .1.1/H-0-3]* HARUS memetakan setiap tampilan UI_MODE_NORMAL yang tersedia untuk aplikasi pihak ketiga ke area tampilan fisik tanpa halangan yang berukuran minimal 2,2” inci pada tepi pendek dan 3,4” inci pada tepi panjang.

  • [ 7.1 .1.3/H-0-1]* HARUS menyetel nilai DENSITY_DEVICE_STABLE menjadi 92% atau lebih besar dari kepadatan fisik sebenarnya dari tampilan terkait.

  Jika implementasi perangkat Genggam mendeklarasikan android.hardware.audio.output dan android.hardware.microphone , keduanya:

  • [ 5.6 /H-1-1] HARUS memiliki latensi Mean Continuous Round-Trip sebesar 300 milidetik atau kurang dalam 5 pengukuran, dengan Mean Absolute Deviation kurang dari 30 md , pada jalur data berikut: "speaker ke mikrofon", 3,5 mm adaptor loopback (jika didukung), loopback USB (jika didukung).

  • [ 5.6 /H-1-2] HARUS memiliki latensi Tap-to-tone rata-rata 300 milidetik atau kurang selama setidaknya 5 pengukuran melalui jalur data speaker ke mikrofon.

  Jika implementasi perangkat Genggam mencakup setidaknya satu aktuator haptik, maka implementasi tersebut:

  • [ 7.10 /H]* TIDAK BOLEH menggunakan aktuator haptic (vibrator) massa berputar eksentrik (ERM).
  • [ 7.10 /H]* HARUS mengimplementasikan semua konstanta publik untuk haptics yang jelas di android.view.HapticFeedbackConstants yaitu (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE _START dan GESTURE_END).
  • [ 7.10 /H]* HARUS mengimplementasikan semua konstanta publik untuk haptics yang jelas di android.os.VibrationEffect yaitu (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK dan EFFECT_DOUBLE_CLICK) dan semua konstanta PRIMITIVE_* publik yang layak untuk haptics kaya di android.os.VibrationEffect.Composition yaitu ( KLIK, CENTANG, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Beberapa dari primitif ini, seperti LOW_TICK dan SPIN mungkin hanya dapat dilakukan jika vibrator dapat mendukung frekuensi yang relatif rendah.
  • [7.10/H]* HARUS mengikuti panduan untuk memetakan konstanta publik di android.view.HapticFeedbackConstants ke konstanta android.os.VibrationEffect yang direkomendasikan, dengan hubungan amplitudo yang sesuai.
  • [ 7.10 /H]* HARUS mengikuti penilaian kualitas untuk API createOneShot() dan createWaveform() .
  • [ 7.10 /H]* HARUS memverifikasi bahwa hasil API android.os.Vibrator.hasAmplitudeControl() publik mencerminkan kemampuan vibratornya dengan benar.
  • [ 7.10 /H]* HARUS menempatkan penempatan aktuator di dekat lokasi di mana perangkat biasanya dipegang atau disentuh oleh tangan.

  Jika implementasi perangkat Genggam mencakup setidaknya satu aktuator resonansi linier tujuan umum 7.10 , maka implementasi tersebut:

  • [ 7.10 /H] HARUS menempatkan penempatan aktuator di dekat lokasi di mana perangkat biasanya dipegang atau disentuh oleh tangan.

  • [ 7.10 /H] HARUS menggerakkan aktuator haptik pada sumbu X (kiri-kanan) dari orientasi potret alami perangkat .

  Jika implementasi perangkat Genggam memiliki aktuator haptik tujuan umum yaitu aktuator resonansi linier (LRA) sumbu X, maka:

  • [ 7.10 /H] HARUS memiliki frekuensi resonansi LRA sumbu X di bawah 200 Hz.

• 2.2.2. Multimedia :

  Lihat revisi

  Implementasi perangkat genggam HARUS mendukung format pengkodean video berikut dan membuatnya tersedia untuk aplikasi pihak ketiga:

  • [ 5.2 /H-0-3] AV1

  Implementasi perangkat genggam HARUS mendukung format decoding video berikut dan membuatnya tersedia untuk aplikasi pihak ketiga:

  • [ 5.3 /H-0-6] AV1

• 2.2.3. Perangkat Lunak :

  Lihat revisi

  Jika implementasi perangkat termasuk tombol navigasi fungsi terkini seperti yang dirinci di bagian 7.2.3 mengubah antarmuka, maka:

  • [ 3.8 .3/H-1-1] HARUS menerapkan perilaku penyematan layar dan menyediakan menu pengaturan kepada pengguna untuk mengaktifkan fitur tersebut.

  Jika penerapan perangkat Genggam menyertakan dukungan untuk ControlsProviderService dan Control API serta mengizinkan aplikasi pihak ketiga untuk memublikasikan kontrol perangkat , maka penerapan tersebut:

  • [ 3.8 .16/H-1-6] Implementasi perangkat HARUS secara akurat memberikan keterjangkauan pengguna sebagai berikut:
    • Jika perangkat telah menyetel config_supportsMultiWindow=true dan aplikasi mendeklarasikan metadata META_DATA_PANEL_ACTIVITY dalam deklarasi ControlsProviderService , termasuk ComponentName aktivitas yang valid (sebagaimana ditentukan oleh API), maka aplikasi HARUS menyematkan aktivitas tersebut dalam kemampuan pengguna ini.
    • Jika aplikasi tidak mendeklarasikan metadata META_DATA_PANEL_ACTIVITY , maka aplikasi HARUS merender kolom tertentu seperti yang disediakan oleh ControlsProviderService API serta kolom tertentu yang disediakan oleh Control API.
  • [ 3.8 .16/H-1-7] Jika aplikasi mendeklarasikan metadata META_DATA_PANEL_ACTIVITY , aplikasi HARUS meneruskan nilai pengaturan yang ditentukan di [3.8.16/H-1-5] menggunakan EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS saat meluncurkan aktivitas yang disematkan.

  Jika implementasi perangkat memungkinkan pengguna melakukan panggilan apa pun, mereka akan

  • [ 7.4.1.2 /H-0-1] HARUS mendeklarasikan tanda fitur android.software.telecom .
  • [ 7.4.1.2 /H-0-2] HARUS mengimplementasikan kerangka telekomunikasi .

• 2.2.4. Performa dan Kekuatan :

  Lihat revisi

  Implementasi perangkat genggam:

  • [ 8.5 /H-0-1] HARUS menyediakan kemampuan pengguna di menu Pengaturan untuk melihat semua aplikasi dengan layanan latar depan aktif atau pekerjaan yang dimulai oleh pengguna, termasuk durasi setiap layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK . dan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan atau pekerjaan yang dimulai oleh pengguna. dengan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan dan menampilkan semua aplikasi yang memiliki layanan latar depan aktif dan durasi masing-masing layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK .
    • Beberapa aplikasi MUNGKIN dikecualikan dari penghentian atau terdaftar dalam keterjangkauan pengguna seperti yang dijelaskan dalam dokumen SDK .