Catatan rilis Android 9

Halaman ini merangkum fitur-fitur utama dalam rilis Android 9, dan menyediakan link ke informasi tambahan. Ringkasan fitur ini disusun berdasarkan lokasi dokumentasi fitur di situs ini. Lihat pembaruan situs Agustus 2018 untuk panduan pemindahan bagian dan penggantian nama.

Membangun

Gambar sistem generik (GSI)

Citra sistem generik (GSI) adalah citra sistem dengan konfigurasi yang disesuaikan untuk perangkat Android. Generic System Image (GSI) mencakup detail perbedaan antara GSI untuk perangkat yang diluncurkan dengan Android 9 dan perangkat yang diupgrade ke Android 9.

Arsitektur

Lapisan abstraksi perangkat keras (HAL)

Kompatibilitas mundur kerangka HIDL

Verifikasi kompatibilitas mundur kerangka HIDL adalah metode untuk memverifikasi kompatibilitas kerangka kerja.

HAL yang tersedia secara dinamis

HAL yang tersedia secara dinamis mendukung penghentian dinamis subsistem perangkat keras Android saat tidak digunakan atau tidak diperlukan.

TERSEMBUNYI

Blok Memori HIDL

HIDL MemoryBlock adalah lapisan abstrak yang dibangun di atas hidl_memory , HIDL @1.0::IAllocator , dan HIDL @1.0::IMapper . Ini dirancang untuk layanan HIDL yang memiliki beberapa blok memori yang berbagi satu tumpukan memori.

Hamparan pohon perangkat

Hamparan terkompresi

Android 9 dan yang lebih tinggi menyertakan dukungan untuk overlay terkompresi pada gambar overlay blob pohon perangkat (DTBO) saat menggunakan header tabel pohon perangkat versi 1.

pembaruan DTO

Android 9 dan yang lebih tinggi mengharuskan bootloader meneruskan blob pohon perangkat terpadu ke kernel sebelum memodifikasi properti yang ditentukan dalam overlay pohon perangkat (DTO) .

Versi header gambar DTBO

Android 9 dan lebih tinggi menyertakan kolom versi di header gambar DTBO.

Verifikasi DTBO

Android 9 dan lebih tinggi memerlukan partisi DTBO. Untuk menambahkan node atau membuat perubahan pada properti di SoC DT, bootloader harus secara dinamis melapisi DT khusus perangkat di atas SoC DT. Untuk informasi lebih lanjut lihat Kompilasi & Verifikasi .

Kepatuhan kernel

Android 9 dan lebih tinggi mencakup persyaratan yang memengaruhi kernel, antarmukanya, dan penggunaan DTBO. Untuk informasi lebih lanjut, lihat halaman ini:

Penjual NDK

Perubahan desain

Untuk informasi tentang perubahan desain VNDK di Android 9 dan lebih tinggi, lihat halaman ini:

pemeriksa ABI

Halaman Stabilitas ABI menjelaskan pemeriksa antarmuka biner aplikasi (ABI), yang memastikan bahwa perubahan yang dilakukan pada pustaka VNDK menjaga kepatuhan ABI.

cuplikan VNDK

Citra sistem dapat menggunakan snapshot VNDK untuk menyediakan pustaka VNDK yang benar ke citra vendor meskipun citra sistem dan vendor dibuat dari versi Android yang berbeda.

Objek antarmuka vendor (objek VINTF)

Halaman berikut di bagian Objek Antarmuka Vendor menjelaskan pembaruan di Android 9 dan lebih tinggi:

Jadwal penghentian HIDL

Halaman berikut menjelaskan cara Android menghentikan dan menghapus HIDL HAL:

Pemuat boot

Partisi produk

Android 9 dan lebih tinggi mendukung partisi bangunan /product menggunakan sistem build Android. Sebelumnya, Android 8.x menerapkan pemisahan komponen khusus system-on-chip (SoC) dari partisi /system ke partisi /vendor tanpa mendedikasikan ruang untuk komponen khusus OEM yang dibuat dari sistem build Android.

Kepatuhan alasan boot kanonik

Halaman Alasan Boot Canonical menjelaskan perubahan pada spesifikasi alasan bootloader di Android 9 dan lebih tinggi.

Sistem sebagai root

Semua perangkat yang diluncurkan dengan Android 9 dan lebih tinggi harus menggunakan system-as-root , yang menggabungkan ramdisk.img ke system.img (juga dikenal sebagai no-ramdisk), yang selanjutnya dipasang sebagai rootfs.

Versi header gambar boot

Di Android 9 dan lebih tinggi, header gambar boot berisi kolom untuk menunjukkan versi header . Bootloader harus memeriksa kolom versi ini dan mengurai header yang sesuai.

DTBO dalam pemulihan

Untuk mencegah kegagalan OTA karena ketidakcocokan antara citra pemulihan dan partisi DTBO pada perangkat non-A/B, citra pemulihan harus berisi informasi dari citra DTBO .

Menampilkan

Tampilkan potongan

Guntingan tampilan memungkinkan pengembang aplikasi menciptakan pengalaman menyeluruh dan imersif sambil tetap memberikan ruang untuk sensor penting di bagian depan perangkat.

Putar saran

Pembaruan pada perilaku rotasi layar Android 9 dan yang lebih tinggi mencakup dukungan untuk kontrol yang menghadap pengguna untuk menyematkan rotasi layar ke lanskap atau potret meskipun posisi perangkat berubah.

Transisi aplikasi yang disinkronkan

Transisi aplikasi yang disinkronkan memungkinkan animasi transisi aplikasi baru.

Klasifikasi teks (sebelumnya TEXTCLASSIFIER)

Android 9 dan yang lebih tinggi menyertakan layanan Pengklasifikasi Teks , yang merupakan cara yang disarankan untuk mengimplementasikan klasifikasi teks, dan implementasi layanan default.

Warna gamut lebar

Android 9 dan yang lebih tinggi menyertakan dukungan untuk warna gamut lebar, termasuk:

  • Rentang dinamis tinggi (HDR)
  • Memproses konten dalam ruang warna BT2020, namun bukan sebagai ruang data target akhir

Untuk menggunakan warna gamut lebar, seluruh tampilan tumpukan perangkat (seperti layar, komposer perangkat keras, GPU) harus mendukung warna gamut lebar atau format buffer. Perangkat tidak perlu mengklaim dukungan untuk konten bergamut luas meskipun perangkat kerasnya mendukungnya. Namun, warna gamut lebar harus diaktifkan untuk memanfaatkan perangkat keras secara maksimal. Untuk menghindari pengalaman visual yang tidak konsisten, warna gamut lebar tidak boleh dinonaktifkan selama runtime.

Kesesuaian

Dokumen Definisi Kompatibilitas Android

Dokumen Definisi Kompatibilitas (CDD) Android 9 mengulangi versi sebelumnya dengan pembaruan untuk fitur baru dan perubahan persyaratan untuk fungsi yang dirilis sebelumnya.

Pengaturan

Widget aplikasi yang lebih baik

Kerangka widget aplikasi Android menawarkan peningkatan visibilitas ke dalam interaksi pengguna, khususnya saat pengguna menghapus atau menambahkan widget secara manual. Fungsionalitas ini hadir secara default dengan Launcher3.

Produsen perlu memperbarui aplikasi peluncur mereka (yang dikirimkan bersama perangkat) untuk mendukung fitur ini jika tidak didasarkan pada Launcher3. OEM perlu mendukung bidang widgetFeatures baru di peluncur default mereka.

Perhatikan bahwa fitur ini hanya berfungsi secara end to end ketika peluncur menerapkannya seperti yang diharapkan. AOSP menyertakan contoh implementasi. Lihat AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca untuk kode contoh yang diberikan.

Pemberitahuan perubahan status perangkat ke penginstal paket

Siaran sistem yang dilindungi dapat dikirim ke aplikasi yang memiliki izin INSTALL_PACKAGES setiap kali ada perubahan pada properti seperti kepadatan lokal atau tampilan. Penerima dapat didaftarkan dalam manifes, dan suatu proses dibangunkan untuk menerima siaran. Hal ini berguna bagi penginstal paket yang ingin menginstal komponen aplikasi tambahan setelah perubahan tersebut, yang jarang terjadi, karena perubahan konfigurasi yang memenuhi syarat untuk memicu siaran ini jarang terjadi.

Kode sumber pemberitahuan perubahan status perangkat terletak di lokasi berikut di bawah platform/frameworks/base :

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

Arsitektur informasi

Perubahan pada arsitektur informasi untuk aplikasi Pengaturan memberikan lebih banyak fungsi dan implementasi yang lebih mudah.

Tes

Sebuah tes

Alat baris perintah Atest memungkinkan Anda membuat, menginstal, dan menjalankan pengujian Android secara lokal, sehingga mempercepat pengujian ulang tanpa memerlukan pengetahuan tentang opsi baris perintah test harness Federasi Perdagangan.

Rangkaian Uji Kompatibilitas

unduhan CTS

Paket Compatibility Test Suite (CTS) yang mendukung Android 9 tersedia di halaman Unduhan CTS . Kode sumber untuk pengujian yang disertakan dapat disinkronkan dengan tag android-cts-9.0_r1 di pohon sumber terbuka.

Pilihan CTS

Untuk Android 9, CTS v2 mendapatkan perintah dan argumen berikut :

  • run retry coba ulang semua pengujian yang gagal atau tidak dijalankan dari sesi sebelumnya.
  • '--shard-count shard yang dijalankan CTS ke dalam sejumlah potongan independen tertentu, untuk dijalankan pada beberapa perangkat secara paralel.

Selain itu, perintah yang sebelumnya tidak berdokumen --retry-type telah ditambahkan ke referensi perintah konsol CTS v2 yang sama.

Layanan Elemen Aman (SE).

Layanan Elemen Aman memeriksa elemen aman yang didukung platform global dengan mengidentifikasi apakah perangkat memiliki implementasi SE HAL dan jika ya, berapa banyak. Ini digunakan sebagai dasar untuk menguji API dan implementasi elemen aman yang mendasarinya.

Kotak fusi sensor

Kotak fusi sensor digunakan dalam uji fusi sensor Camera Image Test Suite (Camera ITS) dan uji sinkronisasi multi-kamera serta menyediakan lingkungan pengujian yang konsisten untuk mengukur keakuratan stempel waktu kamera dan sensor lainnya untuk ponsel Android. Lihat halaman ini untuk informasi lebih lanjut:

Bidang pandang luas ITS-in-a-box

Wide field of view ITS-in-a-box merupakan sistem otomatis yang dirancang untuk menguji sistem kamera wide field of view (WFoV) dan regular field of view (RFoV) di Kamera ITS.

Rangkaian Uji Vendor

Arsitektur pengontrol host

Arsitektur pengontrol host Vendor Test Suite (VTS) adalah arsitektur kerangka pengujian VTS yang terintegrasi dengan layanan penyajian pengujian berbasis cloud.

Pengujian HAL yang mengetahui nama layanan

Pengujian HAL yang mengetahui nama layanan VTS mendukung mendapatkan nama layanan dari instans HAL tertentu berdasarkan perangkat yang menjalankan pengujian VTS.

Pemeriksaan testabilitas HAL

Pemeriksaan kemampuan pengujian VTS HAL mencakup metode runtime untuk menggunakan konfigurasi perangkat guna mengidentifikasi pengujian VTS mana yang harus dilewati untuk target perangkat tersebut.

Infrastruktur pengujian otomatis

Infrastruktur pengujian otomatis adalah infrastruktur VTS untuk pengujian otomatis VTS, CTS, atau pengujian lainnya pada perangkat mitra yang menjalankan citra sistem generik (GSI) AOSP.

Men-debug

Telemetri tingkat lanjut

Di Android, telemetri adalah proses pengumpulan informasi penggunaan dan diagnostik secara otomatis tentang perangkat, sistem Android, dan aplikasi. Pada versi Android sebelumnya, tumpukan telemetri terbatas dan tidak menangkap informasi yang diperlukan untuk mengidentifikasi dan menyelesaikan masalah keandalan sistem dan perangkat atau aplikasi. Hal ini membuat identifikasi akar permasalahan menjadi sulit, bahkan mustahil.

Android 9 menyertakan fitur telemetri statsd , yang mengatasi kekurangan ini dengan mengumpulkan data yang lebih baik dan lebih cepat. statsd mengumpulkan statistik penggunaan aplikasi, baterai dan proses, serta kerusakan. Data dianalisis dan digunakan untuk meningkatkan produk, perangkat keras, dan layanan.

Untuk detail lebih lanjut, lihat frameworks/base/cmds/statsd/ .

Fitur keamanan

Penandatanganan aplikasi

Skema tanda tangan APK v3 mendukung rotasi kunci APK.

Dukungan biometrik

Android 9 menyertakan kelas publik BiometricPrompt , yang dapat digunakan aplikasi untuk mengintegrasikan dukungan autentikasi biometrik dengan cara yang tidak bergantung pada perangkat dan modalitas. Untuk informasi selengkapnya tentang mengintegrasikan tumpukan biometrik Anda untuk menyertakan BiometricPrompt , lihat Biometrik .

Analisis dinamis

Android 9 menyertakan dukungan untuk alat mitigasi dan analisis eksploitasi lainnya.

Integritas aliran kontrol (CFI)

Integritas aliran kendali (CFI) adalah mekanisme keamanan yang melarang perubahan pada grafik aliran kendali asli dari biner yang dikompilasi, sehingga secara signifikan lebih sulit untuk melakukan serangan semacam itu.

Keuangan Kernel

Selain CFI sistem, yang diaktifkan secara default, Android 9 dan lebih tinggi menyertakan dukungan untuk integritas aliran kontrol kernel (CFI) .

Enkripsi

Enkripsi berbasis file

Enkripsi berbasis file (FBE) diperbarui agar berfungsi dengan penyimpanan yang dapat diadopsi . Perangkat baru harus menggunakan enkripsi berbasis file, bukan enkripsi disk penuh.

Enkripsi metadata

Android 9 dan lebih tinggi menyertakan dukungan untuk enkripsi metadata jika ada dukungan perangkat keras. Dengan enkripsi metadata, satu kunci yang ada saat boot menggunakan enkripsi berbasis file untuk mengenkripsi konten apa pun yang tidak dienkripsi.

Penyimpanan kunci

Android 9 dan lebih tinggi menyertakan Keymaster 4 , yang memiliki fitur berikut.

Peti besi

Android 9 dan yang lebih tinggi menyertakan dukungan untuk kunci Android Keystore yang disimpan dan digunakan dalam CPU terpisah secara fisik yang dibuat khusus untuk aplikasi dengan keamanan tinggi, seperti elemen aman tertanam (SE) . StrongBox Keymaster adalah implementasi Keymaster HAL pada perangkat keras aman yang terpisah. StrongBox memiliki:

  • CPU diskrit
  • Penyimpanan aman integral
  • Generator nomor acak sejati berkualitas tinggi
  • Kemasan tahan kerusakan
  • Resistensi saluran samping

Impor kunci aman

Untuk mengimpor kunci dengan aman ke Keymaster 4, kunci yang dibuat di luar perangkat dienkripsi dengan spesifikasi otorisasi yang menentukan cara penggunaan kunci.

dukungan 3DES

Keymaster 4 menyertakan 3DES untuk kompatibilitas dengan sistem lama yang menggunakan 3DES.

Pengikatan versi

Untuk mendukung struktur modular Treble dan memutus pengikatan system.img ke boot.img , Keymaster 4 mengubah model pengikatan versi kunci agar memiliki tingkat patch terpisah untuk setiap partisi. Hal ini memungkinkan setiap partisi diperbarui secara independen sambil tetap memberikan perlindungan rollback.

API Konfirmasi yang Dilindungi Android

Perangkat yang didukung dan diluncurkan dengan Android 9 terinstal memberi pengembang kemampuan untuk menggunakan API Konfirmasi Dilindungi Android . Dengan API ini, aplikasi dapat menggunakan instance ConfirmationPrompt untuk menampilkan perintah kepada pengguna, meminta mereka menyetujui pernyataan singkat. Pernyataan ini memungkinkan aplikasi menegaskan kembali bahwa pengguna ingin menyelesaikan transaksi sensitif, seperti melakukan pembayaran.

SELinux

Sandbox SELinux per aplikasi

Sandbox aplikasi memiliki perlindungan baru dan kasus pengujian untuk memastikan bahwa semua aplikasi yang tidak memiliki hak istimewa yang menargetkan Android 9 dan lebih tinggi menjalankan sandbox SELinux individual.

Perubahan tiga kali lipat SELinux

Pembaruan pada Treble SELinux di Android 9 dan lebih tinggi didokumentasikan di beberapa halaman di bagian SELinux .

Penjual init

Vendor init menutup lubang dalam sistem Treble/vendor split dengan menggunakan domain SELinux terpisah untuk menjalankan perintah /vendor dengan izin khusus vendor.

Properti sistem

Android 9 membatasi properti sistem agar tidak dibagikan antara partisi system dan vendor jika tidak diperlukan dan menyediakan metode untuk memastikan konsistensi antara properti sistem bersama.

Tes atribut SELinux

Android 9 menyertakan pengujian waktu build baru yang memastikan semua file di lokasi tertentu memiliki atribut yang sesuai . Misalnya, semua file di sysfs memiliki atribut sysfs_type yang diperlukan.

Audio

Efek audio resolusi tinggi

Pembaruan pada efek audio resolusi tinggi mencakup konversi pemrosesan efek dari int16 ke format float dan peningkatan trek keluaran klien secara simultan, memori klien/server maksimum, dan total trek campuran.

Kamera

Kamera USB eksternal

Android 9 dan lebih tinggi mendukung penggunaan kamera USB plug-and-play (yaitu webcam) menggunakan API Android Camera2 standar dan antarmuka kamera HIDL.

Pelacakan gerak

Perangkat kamera dapat mengiklankan kemampuan pelacakan gerak .

Dukungan multi-kamera

Dukungan multi-kamera mencakup dukungan API untuk perangkat multi-kamera melalui perangkat kamera logis baru yang terdiri dari dua atau lebih perangkat kamera fisik yang menunjuk ke arah yang sama.

Parameter sesi

Penerapan parameter sesi dapat mengurangi penundaan dengan memungkinkan klien kamera secara aktif mengonfigurasi subset parameter permintaan yang mahal sebagai bagian dari fase inisialisasi sesi pengambilan.

Produsen tunggal, penyangga banyak konsumen

Transportasi buffer kamera produsen tunggal dan banyak konsumen adalah serangkaian metode yang memungkinkan klien kamera menambah dan menghapus permukaan keluaran secara dinamis saat sesi pengambilan aktif dan streaming kamera sedang berlangsung.

Konektivitas

Menelepon dan mengirim pesan

Menerapkan rencana data

Android 9 dan yang lebih tinggi memberikan dukungan yang lebih baik bagi operator yang mengimplementasikan paket data menggunakan API SubscriptionPlan.

Aplikasi panggilan pihak ketiga

Android 9 dan lebih tinggi menyediakan API yang memungkinkan aplikasi panggilan pihak ketiga (3P) menangani panggilan operator masuk secara bersamaan dan mencatat panggilan di log panggilan sistem.

Pembawa

Identifikasi pembawa

Di Android 9, AOSP menambahkan database ID operator untuk membantu identifikasi operator . Basis data meminimalkan logika duplikat dan pengalaman aplikasi yang terfragmentasi dengan menyediakan cara umum untuk mengidentifikasi operator.

eSIM

SIM tertanam (eSIM atau eUICC) adalah teknologi terbaru yang memungkinkan pengguna seluler mengunduh profil operator dan mengaktifkan layanan operator tanpa memiliki kartu SIM fisik. Di Android 9 dan lebih tinggi, framework Android menyediakan API standar untuk mengakses eSIM dan mengelola profil langganan di eSIM. Untuk informasi lebih lanjut, lihat:

Dukungan multi-SIM untuk pengaturan IMS

Android 9 dan lebih tinggi memberikan peningkatan pada pengaturan pengguna untuk subsistem multimedia IP (IMS) . Anda dapat mengatur voiceover LTE (VoLTE), panggilan video, dan panggilan Wi-Fi per langganan, bukan membagikan pengaturan ini ke semua langganan.

Siaran status SIM

Di Android 9 dan yang lebih tinggi, Intent.ACTION_SIM_STATE_CHANGED tidak digunakan lagi, dan dua siaran terpisah untuk status kartu dan status aplikasi kartu ditambahkan, TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED dan TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED .

Dengan perubahan ini, penerima yang hanya perlu mengetahui apakah suatu kartu ada tidak perlu mendengarkan perubahan status aplikasi, dan penerima yang hanya perlu mengetahui apakah aplikasi kartu sudah siap tidak perlu mendengarkan perubahan status kartu.

Dua siaran baru adalah @SystemApis dan tidak melekat. Hanya penerima dengan izin READ_PRIVILEGED_PHONE_STATE yang dapat menerima siaran.

Maksudnya tidak disiarkan ulang saat Anda membuka kunci perangkat. Penerima yang bergantung pada siaran yang dikirim sebelum Anda membuka kunci harus menggunakan directBootAware , atau mereka harus menanyakan status setelah pengguna membuka kunci. Status dapat ditanyakan menggunakan API yang sesuai di TelephonyManager, getSimCardState() dan getSimApplicationState() .

Wifi

Wi-Fi operator

Fitur Wi-Fi operator memungkinkan perangkat terhubung secara otomatis ke jaringan Wi-Fi yang diimplementasikan oleh operator. Di area dengan kemacetan tinggi atau dengan jangkauan seluler minimal seperti stadion atau stasiun kereta bawah tanah, Wi-Fi operator membantu meningkatkan konektivitas dan meringankan lalu lintas.

pengacakan MAC

Pengacakan MAC memungkinkan perangkat menggunakan alamat MAC acak saat mencari jaringan baru yang saat ini tidak terkait dengan jaringan. Di Android 9 dan lebih tinggi, opsi pengembang dapat diaktifkan untuk menyebabkan perangkat menggunakan alamat MAC acak saat menyambung ke jaringan Wi-Fi.

Aktifkan Wi-Fi secara otomatis

Saat fitur Aktifkan Wi-Fi secara otomatis diaktifkan, Wi-Fi secara otomatis diaktifkan kembali setiap kali perangkat berada di dekat jaringan Wi-Fi yang disimpan dengan indikator kekuatan sinyal yang diterima relatif (RSSI) yang cukup tinggi.

Waktu perjalanan pulang pergi Wi-Fi

Waktu perjalanan pulang pergi (RTT) Wi-Fi memungkinkan perangkat mengukur jarak ke perangkat pendukung lainnya, baik itu titik akses (AP) atau rekan Wi-Fi Aware (jika Wi-Fi Aware didukung pada perangkat). Fitur ini dibuat berdasarkan protokol IEEE 802.11mc, dan memungkinkan aplikasi menggunakan akurasi dan kesadaran lokasi yang ditingkatkan.

Peningkatan skor Wi-Fi

Model penilaian Wi-Fi yang ditingkatkan dengan cepat dan akurat menentukan kapan perangkat harus keluar dari jaringan Wi-Fi yang terhubung atau memasuki jaringan Wi-Fi baru. Model-model ini memberikan pengalaman yang andal dan lancar bagi pengguna dengan menghindari kesenjangan dalam konektivitas.

Tinjau dan sesuaikan nilai RSSI di sumber daya config.xml , terutama yang berikut ini:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

Konkurensi Wi-Fi STA/AP

Konkurensi Wi-Fi STA/AP adalah kemampuan perangkat untuk beroperasi dalam mode stasiun (STA) dan titik akses (AP) secara bersamaan. Untuk perangkat yang mendukung Wi-Fi dual band simultan (DBS), hal ini membuka kemampuan seperti tidak mengganggu Wi-Fi STA ketika pengguna ingin mengaktifkan hotspot (SoftAP).

Peningkatan WiFiStateMachine

WifiStateMachine adalah kelas utama yang digunakan untuk mengontrol aktivitas Wi-Fi, mengoordinasikan input pengguna (mode operasi: hotspot, memindai, menghubungkan, atau mematikan), dan mengontrol tindakan jaringan Wi-Fi (seperti memindai atau menghubungkan).

Di Android 9 dan yang lebih tinggi, kode framework Wi-Fi dan implementasi WifiStateMachine dirancang ulang, sehingga mengurangi ukuran kode, logika kontrol Wi-Fi yang lebih mudah diikuti, granularitas kontrol yang lebih baik, serta peningkatan cakupan dan kualitas pengujian unit .

Pada tingkat tinggi, WifiStateMachine memungkinkan Wi-Fi berada di salah satu dari empat kondisi:

  • Mode klien (dapat terhubung dan memindai)
  • Mode pindai saja
  • Mode SoftAP (hotspot Wi-Fi)
  • Dinonaktifkan (Wi-Fi mati sepenuhnya)

Setiap mode Wi-Fi memiliki persyaratan berbeda untuk menjalankan layanan dan harus diatur secara konsisten, hanya menangani kejadian yang relevan dengan pengoperasiannya. Implementasi baru ini membatasi kode pada peristiwa yang terkait dengan mode tersebut, sehingga mengurangi waktu proses debug dan risiko munculnya bug baru karena kerumitannya. Selain penanganan eksplisit untuk fungsionalitas mode, manajemen thread ditangani secara konsisten dan penggunaan saluran asinkron dihilangkan sebagai mekanisme sinkronisasi.

Pembaruan izin Wi-Fi

Di Android 9 dan lebih tinggi, izin aplikasi CHANGE_WIFI_STATE diaktifkan secara default. Anda dapat menonaktifkan izin untuk aplikasi apa pun di halaman pengaturan di Pengaturan > Aplikasi & notifikasi > Akses aplikasi khusus > Kontrol Wi-Fi .

Aplikasi harus mampu menangani kasus ketika izin CHANGE_WIFI_STATE tidak diberikan.

Untuk memvalidasi perilaku ini, jalankan pengujian robotelektrik dan manual.

Untuk pengujian manual:

  1. Buka Pengaturan > Aplikasi & notifikasi > Akses aplikasi khusus > Kontrol Wi-Fi .
  2. Pilih dan matikan izin untuk aplikasi Anda.
  3. Verifikasikan bahwa aplikasi Anda dapat menangani skenario ketika izin CHANGE_WIFI_STATE tidak diberikan.

Penghentian WPS

Karena masalah keamanan, penyiapan yang dilindungi Wi-Fi (WPS) di WiFiManager tidak digunakan lagi dan dinonaktifkan di Android 9 dan lebih tinggi. Namun, WiFiDirect masih menggunakan WPS di pemohon WPA.

Grafik

Penerapan

API Vulkan 1.1

Android 9 dan lebih tinggi mendukung penerapan API grafis Vulkan 1.1 .

Alat WinScope untuk penelusuran transisi jendela

Android 9 dan lebih tinggi menyertakan alat WinScope untuk melacak transisi jendela. WinScope menyediakan infrastruktur dan alat untuk mencatat dan menganalisis keadaan window manager selama dan setelah transisi. Hal ini memungkinkan perekaman dan penelusuran transisi jendela, sekaligus merekam semua status pengelola jendela terkait ke file jejak. Anda dapat menggunakan data ini untuk memutar ulang dan menjalani transisi.

Kode sumber alat WinScope terletak di platform/development/tools/winscope .

Interaksi

Audio otomotif

Audio Otomotif menjelaskan arsitektur audio untuk implementasi Android terkait otomotif.

Neural Networks (NN) HAL mendefinisikan abstraksi berbagai akselerator. Penggerak akselerator ini harus mematuhi HAL ini.

Kendaraan HAL

Properti Kendaraan menjelaskan perubahan pada antarmuka HAL kendaraan.

Pemilihan satelit GNSS

Saat bekerja dengan HAL sistem satelit navigasi global (GNSS) baru (v1.1+), Kerangka Android memantau pengaturan Android. Mitra dapat mengubah pengaturan dari layanan Google Play atau pembaruan sistem lainnya. Pengaturan ini memberi tahu GNSS HAL jika satelit GNSS tertentu tidak boleh digunakan. Hal ini dapat berguna jika terjadi kesalahan konstelasi atau satelit GNSS yang terus-menerus, atau untuk bereaksi lebih cepat terhadap masalah implementasi GNSS HAL yang mungkin terjadi ketika menggabungkan konstelasi menggunakan sistem waktu dan kejadian eksternal yang berbeda, seperti rollover angka detik kabisat, hari, atau minggu .

Model perangkat keras GNSS

Di Android 9, GNSS HAL versi 1.1 atau lebih tinggi dapat meneruskan informasi tentang API perangkat keras ke platform. Platform perlu mengimplementasikan antarmuka IGnssCallback dan meneruskan pegangan ke HAL. GNSS HAL meneruskan informasi model perangkat keras melalui metode LocationManager#getGnssHardwareModelName() . Produsen perangkat harus bekerja sama dengan penyedia GNSS HAL mereka untuk menyediakan informasi ini jika memungkinkan.

Izin

Mengonfigurasi pembaruan kontrol akses diskresioner

Mengonfigurasi Kontrol Akses Diskresioner (DAC) berisi pembaruan pada mekanisme ID Android (AID) untuk memperluas kemampuan sistem file.

Memasukkan izin aplikasi yang memiliki hak istimewa ke dalam daftar putih

Di Android 9 dan yang lebih tinggi, jika ada izin yang harus ditolak, edit XML untuk menggunakan tag deny-permission , bukan tag permission yang digunakan pada rilis sebelumnya.

Data

Peningkatan estimasi bandwidth

Android 9 memberikan dukungan yang lebih baik untuk estimasi bandwidth. Aplikasi Android dapat membuat pengaturan resolusi yang lebih sesuai untuk panggilan video dan streaming video jika dapat mengakses bandwidth data yang tersedia.

Pada perangkat yang menjalankan Android 6.0 atau lebih tinggi, penelepon yang menginginkan perkiraan bandwidth untuk jaringan seluler akan memanggil ConnectivityManager.requestBandwidthUpdate() , dan framework dapat memberikan perkiraan bandwidth downlink.

Namun pada perangkat yang menjalankan versi 9 atau lebih tinggi, callback onCapabilitiesChanged() secara otomatis diaktifkan ketika ada perubahan signifikan dalam perkiraan bandwidth, dan pemanggilan requestBandwidthUpdate() tidak boleh dilakukan; getLinkDownstreamBandwidthKbps() dan getLinkUpstreamBandwidthKbps() terkait diisi dengan informasi terbaru yang disediakan oleh lapisan fisik.

Selain itu, perangkat dapat memeriksa bandwidth sel LTE melalui ServiceState.getCellBandwidths() . Hal ini memungkinkan aplikasi menentukan berapa banyak bandwidth (frekuensi) yang tersedia pada sel tertentu. Informasi bandwidth sel tersedia melalui menu tersembunyi sehingga penguji lapangan dapat memeriksa informasi terkini.

pemantauan lalu lintas eBPF

Alat lalu lintas jaringan eBPF menggunakan kombinasi implementasi kernel dan ruang pengguna untuk memantau penggunaan jaringan pada perangkat sejak boot perangkat terakhir. Alat ini menyediakan fungsionalitas tambahan seperti penandaan soket, memisahkan lalu lintas latar depan/latar belakang, dan firewall per-UID untuk memblokir aplikasi dari akses jaringan bergantung pada status perangkat.

Pulihkan ke API yang lebih rendah

Perangkat sekarang dapat memulihkan dari versi sistem operasi yang akan datang. Hal ini sangat berguna ketika pengguna telah mengupgrade ponselnya tetapi kemudian hilang atau rusak.

Jika OEM memodifikasi agen pencadangan untuk salah satu paket sistem (android, sistem, pengaturan), agen tersebut harus menangani pemulihan set cadangan yang dibuat pada versi platform yang lebih tinggi tanpa mengalami error dan dengan memulihkan setidaknya beberapa data.

Pertimbangkan untuk menggunakan validator untuk memeriksa nilai yang tidak valid dari bagian data cadangan tertentu dan hanya memulihkan data yang valid, seperti pada core/java/android/provider/SettingsValidators.java .

Fitur ini diaktifkan secara default. Dukungan SettingsBackupAgent untuk memulihkan dari versi mendatang dapat dimatikan melalui Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION . Tidak diperlukan implementasi tambahan kecuali produsen perangkat memperluas salah satu agen cadangan yang disertakan dalam ROM (atau menambahkan agen khusus).

Fitur ini memungkinkan pemulihan sistem dari versi platform yang akan datang; namun, wajar jika data yang dipulihkan tidak akan lengkap. Petunjuk berikut berlaku untuk agen pencadangan berikut:

  • PackageManagerBackupAgent mendukung versi data cadangan yang akan datang melalui pembuatan versi format; ekstensi di sini harus kompatibel dengan kode pemulihan saat ini atau mengikuti instruksi di kelas, yang mencakup memasukkan konstanta yang tepat.

  • SystemBackupAgent menentukan restoreAnyVersion = false di Android 9 dan lebih tinggi. Itu tidak mendukung pemulihan dari versi API yang lebih tinggi.

  • SettingsBackupAgent menentukan restoreAnyVersion = true di Android 9 dan lebih tinggi. Dukungan parsial ada melalui validator. Pengaturan dapat dipulihkan dari versi API yang lebih tinggi jika validatornya ada di OS target. Menambahkan pengaturan apa pun harus disertai dengan validatornya. Periksa kelas untuk detailnya.

  • Agen pencadangan khusus apa pun yang disertakan dalam ROM harus meningkatkan kode versinya setiap kali terjadi perubahan yang tidak kompatibel pada format data cadangan dan memastikan restoreAnyVersion = false (default) jika agen mereka tidak siap menangani data cadangan dari versi mendatang. kode mereka.

Perusahaan

Peningkatan profil terkelola

Perubahan UX untuk profil terkelola memudahkan pengguna untuk mengidentifikasi, mengakses, dan mengontrol profil terkelola.

Jeda OTA

@SystemApi baru memungkinkan pemilik perangkat menjeda pembaruan OTA tanpa batas waktu , termasuk pembaruan keamanan.

Pertunjukan

Kesehatan 2.0

Android 9 dan lebih tinggi mencakup android.hardware.health HAL 2.0, peningkatan versi utama dari health@1.0 HAL. Untuk informasi lebih lanjut lihat halaman ini:

Solusi cache APK

Android 9 dan lebih tinggi menyertakan solusi caching APK untuk instalasi cepat aplikasi yang dimuat sebelumnya pada perangkat yang mendukung partisi A/B. OEM dapat menempatkan pramuat dan aplikasi populer di cache APK yang sebagian besar disimpan di partisi B kosong pada perangkat baru yang dipartisi A/B tanpa memengaruhi ruang data yang digunakan pengguna.

Pengoptimalan yang dipandu profil

Android 9 dan lebih tinggi mendukung penggunaan pengoptimalan terpandu profil (PGO) Clang pada modul Android asli yang memiliki aturan pembuatan cetak biru.

Pencatatan log terlebih dahulu

Mode khusus SQLiteDatabase yang disebut logging write-ahead kompatibilitas (WAL) memungkinkan database untuk menggunakan journal_mode=WAL sambil mempertahankan maksimal satu koneksi per database.

Waktu booting

Android 9 mengubah pengoptimalan waktu booting seperti yang dijelaskan dalam Mengoptimalkan Waktu Booting .

Kekuatan

Pembatasan latar belakang

Android 9 dan lebih tinggi menyertakan pembatasan latar belakang yang memungkinkan pengguna membatasi aplikasi yang mungkin menghabiskan daya baterai. Sistem mungkin juga menyarankan untuk menonaktifkan aplikasi yang berdampak negatif pada kesehatan perangkat.

Perangkat tanpa baterai

Android 9 menangani perangkat tanpa baterai dengan lebih elegan dibandingkan rilis sebelumnya. Android 9 menghapus kode untuk perangkat tanpa baterai yang secara default berasumsi bahwa baterai ada, terisi 100%, dan dalam keadaan sehat dengan pembacaan suhu normal pada termistornya.