Halaman ini merangkum fitur utama dalam rilis Android 9, dan memberikan link ke informasi tambahan. Ringkasan fitur ini disusun sesuai dengan lokasi dokumentasi fitur di situs ini. Lihat pembaruan situs Agustus 2018 untuk mendapatkan panduan pemindahan dan penggantian nama bagian.
Build
Generic System Image (GSI)
Generic System Image (GSI) adalah image sistem dengan konfigurasi yang disesuaikan untuk perangkat Android. Generic System Image (GSI) menyertakan detail tentang perbedaan antara GSI untuk perangkat yang diluncurkan dengan Android 9 dan perangkat yang diupgrade ke Android 9.
Arsitektur
Hardware abstraction layer (HAL)
Kompatibilitas mundur framework HIDL
Verifikasi kompatibilitas mundur framework HIDL adalah metode untuk memverifikasi kompatibilitas mundur framework.
HAL yang tersedia secara dinamis
HAL yang tersedia secara dinamis mendukung penonaktifan dinamis subsistem hardware Android saat tidak digunakan atau tidak diperlukan.
HIDL
HIDL MemoryBlock
HIDL MemoryBlock adalah lapisan abstrak
yang dibuat di hidl_memory
, HIDL @1.0::IAllocator
, dan HIDL @1.0::IMapper
. API ini
dirancang untuk layanan HIDL yang memiliki beberapa blok memori yang berbagi satu
heap memori.
Overlay hierarki perangkat
Overlay terkompresi
Android 9 dan yang lebih baru menyertakan dukungan untuk overlay terkompresi dalam gambar overlay blob hierarki perangkat (DTBO) saat menggunakan header tabel hierarki perangkat versi 1.
Pembaruan DTO
Android 9 dan yang lebih tinggi mewajibkan bootloader meneruskan blob hierarki perangkat terpadu ke kernel sebelum mengubah properti yang ditentukan di overlay hierarki perangkat (DTO).
Pembuatan versi header gambar DTBO
Android 9 dan yang lebih baru menyertakan kolom versi di header gambar DTBO.
Verifikasi DTBO
Android 9 dan yang lebih baru memerlukan partisi DTBO. Untuk menambahkan node atau membuat perubahan pada properti di DT SoC, bootloader harus secara dinamis menempatkan DT khusus perangkat di atas DT SoC. Untuk informasi selengkapnya, lihat Mengompilasi & Memverifikasi.
Kepatuhan kernel
Android 9 dan yang lebih tinggi menyertakan persyaratan yang memengaruhi kernel, antarmukanya, dan penggunaan DTBO. Untuk informasi selengkapnya, lihat halaman berikut:
- Rilis & Update Kernel Stabil
- Kernel Umum Android
- Persyaratan Kernel Modular
- Persyaratan Antarmuka
- Overlay Hierarki Perangkat
NDK Vendor
Perubahan desain
Untuk informasi tentang perubahan desain VNDK di Android 9 dan yang lebih baru, lihat halaman ini:
- Vendor Native Development Kit (VNDK)
- Dukungan Sistem Build VNDK
- VNDK Definition Tool
- Direktori, Aturan, dan sepolicy
- Ekstensi VNDK
- Namespace Penaut
Pemeriksa ABI
Halaman Stabilitas ABI menjelaskan pemeriksa antarmuka biner aplikasi (ABI), yang memastikan bahwa perubahan yang dilakukan pada library VNDK mempertahankan kepatuhan ABI.
Snapshot VNDK
Image sistem dapat menggunakan snapshot VNDK untuk menyediakan library VNDK yang benar ke image vendor meskipun image sistem dan vendor dibuat dari versi Android yang berbeda.
Objek antarmuka vendor (objek VINTF)
Halaman berikut di bagian Objek Antarmuka Vendor menjelaskan update di Android 9 dan yang lebih tinggi:
Jadwal penghentian penggunaan HIDL
Halaman berikut menjelaskan cara Android menghentikan penggunaan dan menghapus HIDL HAL:
Bootloader
Partisi produk
Android 9 dan yang lebih tinggi mendukung pembuatan
partisi /product
menggunakan
sistem build Android. Sebelumnya, Android 8.x menerapkan pemisahan
komponen khusus system-on-chip (SoC) dari partisi /system
ke
partisi /vendor
tanpa menyediakan ruang untuk komponen khusus OEM yang di-build
dari sistem build Android.
Kepatuhan terhadap alasan booting kanonis
Halaman Alasan Booting Kanonik menjelaskan perubahan pada spesifikasi alasan booting bootloader di Android 9 dan yang lebih baru.
Sistem sebagai root
Semua perangkat yang diluncurkan dengan Android 9 dan yang lebih tinggi harus menggunakan
system-as-root, yang menggabungkan ramdisk.img
ke dalam system.img
(juga dikenal sebagai no-ramdisk), yang pada gilirannya dipasang
sebagai rootfs.
Pembuatan versi header image booting
Di Android 9 dan yang lebih baru, header image booting berisi kolom untuk menunjukkan versi header. Bootloader harus memeriksa kolom versi ini dan mengurai header sesuai kebutuhan.
DTBO dalam pemulihan
Untuk mencegah kegagalan OTA karena ketidakcocokan antara image pemulihan dan partisi DTBO pada perangkat non-A/B, image pemulihan harus berisi informasi dari image DTBO.
Tampilan
Potongan layar
Potongan layar memungkinkan developer aplikasi membuat pengalaman imersif dari tepi ke tepi sekaligus tetap menyediakan ruang untuk sensor penting di bagian depan perangkat.
Memutar saran
Update pada perilaku rotasi layar Android 9 dan yang lebih tinggi mencakup dukungan untuk kontrol yang ditampilkan kepada pengguna guna 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 Text Classifier, yang merupakan cara yang direkomendasikan untuk menerapkan klasifikasi teks, dan penerapan layanan default.
Warna gamut yang bervariasi
Android 9 dan yang lebih baru menyertakan dukungan untuk warna gamut lebar, termasuk:
- Rentang dinamis tinggi (HDR)
- Memproses konten dalam ruang warna BT2020, tetapi bukan sebagai ruang data target akhir
Untuk menggunakan warna gamut lebar, stack tampilan penuh perangkat (seperti layar, composer hardware, GPU) harus mendukung warna gamut lebar atau format buffering. Perangkat tidak diwajibkan untuk mengklaim dukungan untuk konten gamut lebar meskipun hardware mendukungnya. Namun, warna gamut lebar harus diaktifkan untuk memanfaatkan hardware sepenuhnya. Untuk menghindari pengalaman visual yang tidak konsisten, warna gamut lebar tidak boleh dinonaktifkan selama runtime.
Kompatibilitas
Android Compatibility Definition Document
Compatibility Definition Document (CDD) Android 9 melakukan iterasi pada versi sebelumnya dengan update untuk fitur baru dan perubahan pada persyaratan untuk fungsi yang dirilis sebelumnya.
Setelan
Widget aplikasi yang lebih baik
Framework widget aplikasi Android menawarkan visibilitas yang lebih baik ke interaksi pengguna, terutama saat pengguna menghapus atau menambahkan widget secara manual. Fungsionalitas ini disertakan secara default dengan Launcher3.
Produsen harus mengupdate aplikasi peluncur mereka (yang dikirimkan bersama perangkat) untuk mendukung fitur ini jika tidak didasarkan pada Launcher3. OEM harus mendukung kolom widgetFeatures baru di peluncur default mereka.
Perhatikan bahwa fitur ini hanya berfungsi secara menyeluruh saat peluncur menerapkannya seperti yang diharapkan. AOSP menyertakan contoh implementasi. Lihat Change-Id AOSP Iccd6f965fa3d61992244a365efc242122292c0ca untuk kode contoh yang diberikan.
Notifikasi 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
lokalitas atau kepadatan tampilan. Penerima dapat didaftarkan dalam manifes, dan
proses akan aktif 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 notifikasi perubahan status perangkat terletak di lokasi
berikut di bagian 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 Setelan memberikan lebih banyak fungsi dan penerapan yang lebih mudah.
Pengujian
Atest
Alat command line Atest memungkinkan Anda mem-build, menginstal, dan menjalankan pengujian Android secara lokal, yang sangat mempercepat pengujian ulang tanpa memerlukan pengetahuan tentang opsi command line harness pengujian Trade Federation.
Compatibility Test Suite (CTS)
Download CTS
Paket Compatibility Test Suite (CTS) yang mendukung Android 9 tersedia di halaman
CTS Downloads. Kode sumber untuk
pengujian yang disertakan dapat disinkronkan dengan tag android-cts-9.0_r1
di
hierarki open source.
Opsi CTS
Untuk Android 9, CTS v2 mendapatkan perintah dan argumen berikut:
run retry
mencoba ulang semua pengujian yang gagal atau tidak dijalankan dari sesi sebelumnya.‘--shard-count
mengelompokkan CTS yang berjalan ke dalam jumlah bagian independen tertentu, untuk dijalankan di beberapa perangkat secara paralel.
Selain itu, perintah --retry-type
yang sebelumnya tidak terdokumentasi telah ditambahkan
ke referensi perintah konsol CTS v2 yang sama.
Layanan Elemen Pengaman (SE)
Layanan Elemen Pengaman memeriksa elemen pengaman yang didukung platform global dengan mengidentifikasi apakah perangkat memiliki implementasi HAL SE dan jika ya, berapa jumlahnya. Ini digunakan sebagai dasar untuk menguji API dan implementasi elemen aman yang mendasarinya.
Kotak penggabungan sensor
Kotak penggabungan sensor digunakan dalam pengujian penggabungan sensor Camera Image Test Suite (Camera ITS) dan pengujian sinkronisasi multi-kamera serta menyediakan lingkungan pengujian yang konsisten untuk mengukur akurasi stempel waktu kamera dan sensor lainnya untuk ponsel Android. Lihat halaman ini untuk mengetahui informasi selengkapnya:
- Panduan Mulai Cepat Sensor Fusion Box memberikan langkah-langkah untuk menyiapkan pengujian sensor fusion dan sensor fusion box untuk pertama kalinya.
- Pemasangan Kotak Sensor Fusion memberikan langkah-langkah untuk memasang kotak sensor fusion.
ITS-in-a-box dengan ruang pandang lebar
ITS-in-a-box bidang pandang lebar adalah sistem otomatis yang dirancang untuk menguji sistem kamera bidang pandang lebar (WFoV) dan bidang pandang reguler (RFoV) di ITS Kamera.
Vendor Test Suite
Arsitektur pengontrol host
Arsitektur pengontrol host Vendor Test Suite (VTS) adalah arsitektur framework pengujian VTS yang terintegrasi dengan layanan penayangan pengujian berbasis cloud-nya.
Pengujian HAL yang mengetahui nama layanan
Pengujian HAL yang mengetahui nama layanan VTS mendukung mendapatkan nama layanan instance HAL tertentu berdasarkan perangkat tempat pengujian VTS berjalan.
Pemeriksaan kemampuan pengujian HAL
Pemeriksaan kemampuan pengujian HAL VTS mencakup metode runtime untuk menggunakan konfigurasi perangkat guna mengidentifikasi pengujian VTS yang harus dilewati untuk target perangkat tersebut.
Infrastruktur pengujian otomatis
Infrastruktur pengujian otomatis adalah infrastruktur VTS untuk pengujian otomatis VTS, CTS, atau pengujian lainnya di perangkat partner yang menjalankan image sistem generik (GSI) AOSP.
Proses Debug
Telemetri lanjutan
Di Android, telemetri adalah proses pengumpulan informasi penggunaan dan diagnostik secara otomatis tentang perangkat, sistem Android, dan aplikasi. Di versi Android sebelumnya, stack telemetri terbatas dan tidak mengambil informasi yang diperlukan untuk mengidentifikasi dan menyelesaikan masalah keandalan sistem serta masalah perangkat atau aplikasi. Hal ini membuat identifikasi akar masalah menjadi sulit, jika tidak mungkin.
Android 9 menyertakan fitur telemetri statsd
, yang mengatasi
kekurangan ini dengan mengumpulkan data yang lebih baik dengan lebih cepat. statsd
mengumpulkan
statistik penggunaan aplikasi, baterai, dan proses, serta error. Data tersebut dianalisis dan
digunakan untuk meningkatkan kualitas produk, hardware, dan layanan.
Untuk detail selengkapnya, lihat frameworks/base/cmds/statsd/
.
Fitur keamanan
Penandatanganan aplikasi
Skema tanda tangan APK v3 mendukung rotasi kunci APK.
Dukungan biometrik
Android 9 menyertakan class publik
BiometricPrompt
,
yang dapat digunakan aplikasi untuk mengintegrasikan dukungan autentikasi biometrik dengan
cara yang tidak bergantung pada perangkat dan modalitas. Untuk informasi selengkapnya tentang cara mengintegrasikan
stack biometrik untuk menyertakan BiometricPrompt
, lihat
Biometrik.
Analisis dinamis
Android 9 menyertakan dukungan untuk lebih banyak alat analisis dan mitigasi eksploit.
Integritas alur kontrol (CFI)
Integritas alur kontrol (CFI) adalah mekanisme keamanan yang melarang perubahan pada grafik alur kontrol asli dari biner yang dikompilasi, sehingga mempersulit serangan tersebut secara signifikan.
CFI Kernel
Selain CFI sistem, yang diaktifkan secara default, Android 9 dan yang lebih tinggi menyertakan dukungan untuk kernel control flow integrity (CFI).
Enkripsi
Enkripsi berbasis file
Enkripsi berbasis file (FBE) diupdate agar dapat berfungsi dengan penyimpanan yang dapat diadopsi. Perangkat baru harus menggunakan enkripsi berbasis file, bukan enkripsi disk penuh.
Enkripsi metadata
Android 9 dan yang lebih baru menyertakan dukungan untuk enkripsi metadata jika dukungan hardware ada. Dengan enkripsi metadata, satu kunci yang ada pada waktu booting menggunakan enkripsi berbasis file untuk mengenkripsi konten yang tidak dienkripsi.
Keystore
Android 9 dan yang lebih tinggi menyertakan Keymaster 4, yang memiliki fitur ini.
StrongBox
Android 9 dan yang lebih tinggi menyertakan dukungan untuk kunci Keystore Android yang disimpan dan digunakan di CPU terpisah secara fisik yang dibuat khusus untuk aplikasi dengan keamanan tinggi, seperti elemen aman (SE) tersemat. StrongBox Keymaster adalah implementasi Keymaster HAL dalam hardware aman terpisah. StrongBox memiliki:
- CPU Diskret
- Penyimpanan aman integral
- Generator angka acak sebenarnya berkualitas tinggi
- Kemasan yang tahan perusakan
- Ketahanan side-channel
Impor kunci yang aman
Untuk mengimpor kunci ke Keymaster 4 dengan aman, kunci yang dibuat di luar perangkat dienkripsi dengan spesifikasi otorisasi yang menentukan cara kunci dapat digunakan.
Dukungan 3DES
Keymaster 4 menyertakan 3DES untuk kompatibilitas dengan sistem lama yang menggunakan 3DES.
Binding versi
Untuk mendukung struktur modular Treble dan memisahkan binding system.img
ke boot.img
, Keymaster 4 mengubah model binding versi kunci
agar memiliki level patch terpisah untuk setiap partisi. Hal ini memungkinkan setiap partisi
diupdate secara independen sekaligus tetap memberikan perlindungan rollback.
Android Protected Confirmation API
Perangkat yang didukung yang diluncurkan dengan Android 9 yang diinstal memberi developer
kemampuan untuk menggunakan
Android Protected Confirmation API.
Dengan API ini, aplikasi dapat menggunakan instance
ConfirmationPrompt
untuk menampilkan perintah kepada pengguna, meminta mereka menyetujui pernyataan singkat. Pernyataan
ini memungkinkan aplikasi untuk menegaskan bahwa pengguna ingin menyelesaikan
transaksi sensitif, seperti melakukan pembayaran.
SELinux
Sandbox SELinux per aplikasi
Sandbox aplikasi memiliki perlindungan dan kasus pengujian baru untuk memastikan bahwa semua aplikasi tanpa hak istimewa yang menargetkan Android 9 dan yang lebih tinggi menjalankan setiap sandbox SELinux.
Perubahan SELinux Treble
Update pada Treble SELinux di Android 9 dan yang lebih tinggi didokumentasikan di beberapa halaman di bagian SELinux.
Inisialisasi vendor
Vendor init menutup celah
dalam pemisahan sistem/vendor Treble dengan menggunakan domain
SELinux terpisah untuk menjalankan perintah /vendor
dengan izin khusus vendor.
Properti sistem
Android 9 membatasi properti sistem
agar tidak dibagikan di antara partisi system
dan vendor
yang tidak perlu dan
menyediakan metode untuk memastikan konsistensi antara properti sistem bersama.
Pengujian 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 beresolusi tinggi
Update pada efek audio beresolusi tinggi mencakup konversi pemrosesan efek dari int16 ke format float dan peningkatan jalur output klien serentak, memori klien/server maksimum, dan total jalur campuran.
Kamera
Kamera USB eksternal
Android 9 dan yang lebih tinggi mendukung penggunaan kamera USB plug-and-play (yaitu, webcam) menggunakan Android Camera2 API standar dan antarmuka HIDL kamera.
Pelacakan gerakan
Perangkat kamera dapat mengumumkan kemampuan pelacakan gerakan.
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 mengarah ke arah yang sama.
Parameter sesi
Menerapkan parameter sesi dapat mengurangi keterlambatan dengan memungkinkan klien kamera mengonfigurasi secara aktif subset parameter permintaan yang mahal sebagai bagian dari fase inisialisasi sesi pengambilan.
Satu produsen, beberapa buffer konsumen
Transpor buffering kamera satu produsen, beberapa konsumen adalah serangkaian metode yang memungkinkan klien kamera menambahkan dan menghapus platform output secara dinamis saat sesi pengambilan aktif dan streaming kamera sedang berlangsung.
Konektivitas
Panggilan telepon dan pesan
Menerapkan paket data
Android 9 dan yang lebih baru memberikan dukungan yang lebih baik bagi operator yang menerapkan paket data menggunakan SubscriptionPlan API.
Aplikasi panggilan pihak ketiga
Android 9 dan yang lebih tinggi menyediakan API yang memungkinkan aplikasi panggilan pihak ketiga (3P) untuk menangani panggilan operator masuk serentak dan mencatat panggilan dalam log panggilan sistem.
Operator
Identifikasi operator
Di Android 9, AOSP menambahkan database ID operator untuk membantu identifikasi operator. Database meminimalkan logika duplikat dan pengalaman aplikasi yang terfragmentasi dengan menyediakan cara umum untuk mengidentifikasi operator.
eSIM
SIM Tersemat (eSIM atau eUICC) adalah teknologi terbaru yang memungkinkan pengguna seluler mendownload profil operator dan mengaktifkan layanan operator tanpa memiliki kartu SIM fisik. Di Android 9 dan yang lebih tinggi, framework Android menyediakan API standar untuk mengakses eSIM dan mengelola profil langganan di eSIM. Untuk informasi selengkapnya, lihat:
Dukungan multi-SIM untuk setelan IMS
Android 9 dan yang lebih tinggi memberikan peningkatan pada setelan pengguna untuk subsistem multimedia IP (IMS). Anda dapat menyiapkan voiceover LTE (VoLTE), panggilan video, dan panggilan Wi-Fi per langganan, bukan membagikan setelan ini di semua langganan.
Siaran status SIM
Di Android 9 dan yang lebih baru, Intent.ACTION_SIM_STATE_CHANGED
tidak digunakan lagi, dan dua
siaran terpisah untuk status kartu dan status permohonan kartu ditambahkan,
TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED
dan
TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED
.
Dengan perubahan ini, penerima yang hanya perlu mengetahui apakah kartu ada tidak perlu memproses perubahan status aplikasi, dan penerima yang hanya perlu mengetahui apakah aplikasi kartu sudah siap tidak perlu memproses perubahan status kartu.
Dua siaran baru adalah @SystemApis dan tidak melekat. Hanya penerima dengan
izin READ_PRIVILEGED_PHONE_STATE
yang dapat menerima siaran.
Intent 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 mengkueri status setelah pengguna membuka kunci. Status dapat dikueri menggunakan
API yang sesuai di TelephonyManager, getSimCardState()
dangetSimApplicationState()
.
Wi-Fi
Wi-Fi Operator
Fitur Wi-Fi operator memungkinkan perangkat terhubung secara otomatis ke jaringan Wi-Fi yang diterapkan operator. Di area dengan kemacetan yang tinggi atau dengan cakupan sel minimal seperti stadion atau stasiun kereta bawah tanah, Wi-Fi operator membantu meningkatkan konektivitas dan mengurangi traffic.
Pengacakan MAC
Pengacakan MAC memungkinkan perangkat menggunakan alamat MAC acak saat menyelidiki jaringan baru saat tidak terkait dengan jaringan. Di Android 9 dan yang lebih baru, opsi developer dapat diaktifkan untuk menyebabkan perangkat menggunakan alamat MAC acak saat terhubung ke jaringan Wi-Fi.
Aktifkan Wi‑Fi secara otomatis
Jika fitur Aktifkan Wi-Fi secara otomatis diaktifkan, Wi-Fi akan otomatis diaktifkan kembali setiap kali perangkat berada di dekat jaringan Wi-Fi tersimpan dengan indikator kekuatan sinyal yang diterima relatif cukup tinggi (RSSI).
Waktu round-trip Wi-Fi
Waktu perjalanan bolak-balik (RTT) Wi-Fi memungkinkan perangkat mengukur jarak ke perangkat pendukung lainnya, baik titik akses (AP) maupun peer Wi-Fi Aware (jika Wi-Fi Aware didukung di perangkat). Fitur ini dibuat berdasarkan protokol IEEE 802.11mc, dan memungkinkan aplikasi menggunakan akurasi dan kesadaran lokasi yang ditingkatkan.
Peningkatan skor Wi-Fi
Model penskoran Wi-Fi yang ditingkatkan dengan cepat dan akurat menentukan kapan perangkat harus keluar dari jaringan Wi-Fi yang terhubung atau masuk ke jaringan Wi-Fi baru. Model ini memberikan pengalaman yang andal dan lancar bagi pengguna dengan menghindari kesenjangan konektivitas.
Tinjau dan sesuaikan nilai RSSI di resource config.xml
,
terutama hal berikut:
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 STA/AP Wi-Fi
Konkurensi STA/AP Wi-Fi adalah kemampuan perangkat untuk beroperasi dalam mode stasiun (STA) dan titik akses (AP) secara serentak. Untuk perangkat yang mendukung Wi-Fi simultan dual-band (DBS), hal ini akan membuka kemampuan seperti tidak mengganggu Wi-Fi STA saat pengguna ingin mengaktifkan hotspot (SoftAP).
Peningkatan WiFiStateMachine
WifiStateMachine
adalah class utama yang digunakan untuk mengontrol aktivitas Wi-Fi, mengoordinasikan
input pengguna (mode operasi: hotspot, pindai, hubungkan, atau nonaktif), 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, meningkatkan perincian kontrol, dan
meningkatkan cakupan dan kualitas pengujian unit.
Pada tingkat tinggi,WifiStateMachine
memungkinkan Wi-Fi berada dalam salah satu dari empat status:
- Mode klien (dapat terhubung dan memindai)
- Mode hanya pindai
- Mode SoftAP (hotspot Wi-Fi)
- Dinonaktifkan (Wi-Fi sepenuhnya nonaktif)
Setiap mode Wi-Fi memiliki persyaratan yang berbeda untuk menjalankan layanan dan harus disiapkan dengan cara yang konsisten, hanya menangani peristiwa yang relevan dengan operasinya. Implementasi baru membatasi kode untuk peristiwa yang terkait dengan mode tersebut, sehingga mengurangi waktu proses debug dan risiko munculnya bug baru karena kompleksitas. Selain penanganan eksplisit untuk fungsi mode, pengelolaan thread ditangani dengan cara yang konsisten dan penggunaan saluran asinkron dihilangkan sebagai mekanisme untuk sinkronisasi.
Update izin Wi-Fi
Di Android 9 dan yang lebih tinggi, izin aplikasi CHANGE_WIFI_STATE
diaktifkan
secara default. Anda dapat menonaktifkan izin untuk
aplikasi apa pun di halaman setelan di Setelan > Aplikasi & notifikasi >
Akses aplikasi khusus > Kontrol Wi-Fi.
Aplikasi harus dapat menangani kasus jika izin CHANGE_WIFI_STATE
tidak
diberikan.
Untuk memvalidasi perilaku ini, jalankan pengujian roboelectric dan manual.
Untuk pengujian manual:
- Buka Setelan > Aplikasi & notifikasi > Akses aplikasi khusus > Kontrol Wi-Fi.
- Pilih dan nonaktifkan izin untuk aplikasi Anda.
- Pastikan aplikasi Anda dapat menangani skenario saat izin
CHANGE_WIFI_STATE
tidak diberikan.
Penghentian penggunaan WPS
Karena masalah keamanan, Wi-Fi protected setup (WPS) di WiFiManager
tidak digunakan lagi dan dinonaktifkan di Android 9 dan yang lebih baru. Namun, WiFiDirect
masih menggunakan
WPS di supplicant WPA.
Grafik
Implementasi
Vulkan 1.1 API
Android 9 dan yang lebih tinggi mendukung penerapan API grafis Vulkan 1.1.
Alat WinScope untuk pelacakan transisi jendela
Android 9 dan yang lebih baru menyertakan alat WinScope untuk melacak transisi jendela. WinScope menyediakan infrastruktur dan alat untuk merekam dan menganalisis status pengelola jendela selama dan setelah transisi. Hal ini memungkinkan perekaman dan langkah melalui transisi jendela, sekaligus merekam semua status pengelola jendela yang relevan ke file rekaman aktivitas. Anda dapat menggunakan data ini untuk memutar ulang dan melangkahi transisi.
Kode sumber alat WinScope terletak di
platform/development/tools/winscope
.
Interaksi
Audio otomotif
Audio Otomotif menjelaskan arsitektur audio untuk implementasi Android terkait otomotif.
HAL Neural Networks (NN) menentukan abstraksi berbagai akselerator. Driver untuk akselerator ini harus sesuai dengan HAL ini.
HAL Kendaraan
Properti Kendaraan menjelaskan perubahan pada antarmuka HAL kendaraan.
Pemilihan satelit GNSS
Saat menggunakan HAL sistem satelit navigasi global (GNSS) baru (v1.1+), Android Framework akan memantau setelan Android. Partner dapat mengubah setelan dari layanan Google Play atau update sistem lainnya. Setelan ini memberi tahu HAL GNSS jika satelit GNSS tertentu tidak boleh digunakan. Hal ini dapat berguna jika terjadi error konstelasi atau satelit GNSS yang persisten, atau untuk bereaksi lebih cepat terhadap masalah penerapan HAL GNSS yang dapat terjadi saat mencampur konstelasi menggunakan sistem waktu dan peristiwa eksternal yang berbeda, seperti rollover detik kabisat, hari, atau nomor minggu.
Model hardware GNSS
Di Android 9, GNSS HAL versi 1.1 atau yang lebih tinggi dapat
meneruskan informasi tentang API hardware ke platform. Platform harus
menerapkan antarmuka IGnssCallback
dan meneruskan handle ke HAL. HAL GNSS
meneruskan informasi model hardware melalui
metode
LocationManager#getGnssHardwareModelName()
. Produsen perangkat harus bekerja sama dengan penyedia HAL GNSS mereka untuk memberikan
informasi ini jika memungkinkan.
Izin
Mengonfigurasi pembaruan kontrol akses diskresional
Mengonfigurasi Discretionary Access Control (DAC) berisi update pada mekanisme Android ID (AID) untuk memperluas kemampuan sistem file.
Memberikan izin aplikasi dengan hak istimewa
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 dalam rilis sebelumnya.
Data
Peningkatan estimasi bandwidth
Android 9 memberikan dukungan yang ditingkatkan untuk estimasi bandwidth. Aplikasi Android dapat membuat setelan 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 yang lebih tinggi, pemanggil yang menginginkan estimasi bandwidth
untuk panggilan jaringan seluler
ConnectivityManager.requestBandwidthUpdate()
,
dan framework dapat memberikan estimasi bandwidth downlink.
Namun, di perangkat yang menjalankan Android 9 atau yang lebih baru, callback
onCapabilitiesChanged()
akan otomatis diaktifkan saat ada perubahan signifikan pada estimasi
bandwidth, dan memanggil requestBandwidthUpdate()
tidak akan melakukan operasi apa pun;
getLinkDownstreamBandwidthKbps()
dan
getLinkUpstreamBandwidthKbps()
terkait akan 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 jumlah bandwidth (frekuensi) yang tersedia
di sel tertentu. Informasi bandwidth sel tersedia melalui menu tersembunyi sehingga
penguji lapangan dapat memeriksa informasi terbaru.
Pemantauan traffic eBPF
Alat traffic jaringan eBPF menggunakan kombinasi implementasi kernel dan ruang pengguna untuk memantau penggunaan jaringan di perangkat sejak perangkat terakhir kali di-booting. Alat ini menyediakan fungsi tambahan seperti pemberian tag soket, memisahkan traffic latar depan/latar belakang, dan firewall per UID untuk memblokir aplikasi dari akses jaringan, bergantung pada status perangkat.
Memulihkan ke API yang lebih rendah
Perangkat kini dapat dipulihkan dari versi sistem operasi mendatang. Hal ini sangat berguna saat pengguna telah mengupgrade ponsel, tetapi kemudian kehilangan atau merusaknya.
Jika OEM mengubah agen pencadangan untuk paket sistem apa pun (android, sistem, setelan), agen tersebut harus menangani pemulihan set cadangan yang dibuat pada versi platform yang lebih tinggi tanpa error dan dengan memulihkan setidaknya beberapa data.
Sebaiknya gunakan validator untuk memeriksa nilai yang tidak valid dari bagian data cadangan tertentu dan hanya memulihkan data yang valid, seperti dalam core/java/android/provider/SettingsValidators.java
.
Fitur ini diaktifkan secara default. Dukungan SettingsBackupAgent untuk memulihkan dari
versi mendatang dapat dinonaktifkan melalui
Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION
. Tidak ada
implementasi tambahan yang diperlukan kecuali jika produsen perangkat memperluas salah satu
agen pencadangan yang disertakan dalam ROM (atau menambahkan agen kustom).
Fitur ini memungkinkan pemulihan sistem dari versi platform mendatang; tetapi, wajar jika data yang dipulihkan tidak lengkap. Petunjuk berikut berlaku untuk agen pencadangan berikut:
PackageManagerBackupAgent mendukung versi data pencadangan mendatang melalui pembuatan versi format; ekstensi di sini harus kompatibel dengan kode pemulihan saat ini atau mengikuti petunjuk di class, yang mencakup meningkatkan konstanta yang sesuai.
SystemBackupAgent menentukan
restoreAnyVersion = false
di Android 9 dan yang lebih baru. API ini tidak mendukung pemulihan dari versi API yang lebih tinggi.SettingsBackupAgent menentukan
restoreAnyVersion = true
di Android 9 dan yang lebih baru. Dukungan parsial tersedia melalui validator. Setelan dapat dipulihkan dari versi API yang lebih tinggi jika validator untuk setelan tersebut ada di OS target. Penambahan setelan apa pun harus disertai dengan validatornya. Periksa class untuk mengetahui detailnya.Setiap agen pencadangan kustom yang disertakan dalam ROM harus meningkatkan kode versinya setiap kali perubahan yang tidak kompatibel dilakukan pada format data pencadangan dan memastikan
restoreAnyVersion = false
(default) jika agennya tidak siap menangani data pencadangan dari versi kode mendatang.
Enterprise
Peningkatan profil terkelola
Perubahan UX untuk profil terkelola memudahkan pengguna untuk mengidentifikasi, mengakses, dan mengontrol profil terkelola.
Menjeda OTA
@SystemApi baru memungkinkan pemilik perangkat menjeda update OTA tanpa batas, termasuk update keamanan.
Performa
Kesehatan 2.0
Android 9 dan yang lebih tinggi menyertakan android.hardware.health
HAL 2.0, upgrade
versi utama dari HAL health@1.0. Untuk informasi selengkapnya, lihat halaman berikut:
Solusi penyimpanan dalam cache APK
Android 9 dan yang lebih tinggi menyertakan solusi caching APK untuk penginstalan cepat aplikasi yang dimuat sebelumnya di perangkat yang mendukung partisi A/B. OEM dapat menempatkan aplikasi populer dan pramuat di cache APK yang sebagian besar disimpan di partisi B kosong pada perangkat yang dipartisi A/B baru tanpa memengaruhi ruang data yang ditampilkan kepada pengguna.
Pengoptimalan yang dipandu profil
Android 9 dan yang lebih tinggi mendukung penggunaan pengoptimalan yang dipandu profil (PGO) Clang pada modul Android native yang memiliki aturan build blueprint.
Logging write-ahead
Mode khusus SQLiteDatabase yang disebut logging write-ahead
kompatibilitas (WAL) memungkinkan database menggunakan
journal_mode=WAL
sekaligus mempertahankan maksimum satu koneksi per database.
Waktu booting
Android 9 mengubah pengoptimalan waktu booting seperti yang dijelaskan dalam Mengoptimalkan Waktu Booting.
Daya
Pembatasan latar belakang
Android 9 dan yang lebih baru menyertakan batasan latar belakang yang memungkinkan pengguna membatasi aplikasi yang mungkin menghabiskan daya baterai. Sistem juga dapat menyarankan untuk menonaktifkan aplikasi yang berdampak buruk pada kesehatan perangkat.
Perangkat tanpa baterai
Android 9 menangani perangkat tanpa baterai dengan lebih elegan daripada di rilis sebelumnya. Android 9 menghapus kode untuk perangkat tanpa baterai yang secara default mengasumsikan bahwa baterai ada, diisi daya hingga 100%, dan dalam kondisi baik dengan pembacaan suhu normal pada termistornya.