Pembaruan yang dilakukan pada area khusus tampilan ini diberikan di bawah:
- Mengubah ukuran aktivitas dan tampilan
- Ukuran layar dan rasio aspek
- Kebijakan Display
- Setelan periode tampilan
- ID Display statis
- Menggunakan lebih dari dua layar
- Fokus per layar
Mengubah ukuran aktivitas dan tampilan
Untuk menunjukkan bahwa aplikasi mungkin tidak mendukung mode multi-aplikasi atau pengubahan ukuran,
aktivitas menggunakan atribut resizeableActivity=false
. Masalah
umum yang dialami aplikasi saat aktivitas diubah ukurannya meliputi:
- Aktivitas dapat memiliki konfigurasi yang berbeda dari aplikasi atau komponen non-visual lainnya. Kesalahan umum adalah membaca metrik tampilan dari konteks aplikasi. Nilai yang ditampilkan tidak akan disesuaikan dengan metrik area yang terlihat tempat aktivitas ditampilkan.
- Aktivitas mungkin tidak dapat menangani pengubahan ukuran dan error, menampilkan UI yang terdistorsi, atau kehilangan status karena diluncurkan ulang tanpa menyimpan status instance.
- Aplikasi dapat mencoba menggunakan koordinat input absolut (bukan yang relatif terhadap posisi jendela), yang dapat merusak input dalam multi-aplikasi.
Di Android 7 (dan yang lebih baru), aplikasi dapat ditetapkan
resizeableActivity=false
agar selalu berjalan dalam mode layar penuh. Dalam
hal ini, platform mencegah aktivitas yang tidak dapat diubah ukurannya agar tidak masuk ke layar
terpisah. Jika pengguna mencoba memanggil aktivitas yang tidak dapat diubah ukurannya dari peluncur
saat sudah dalam mode layar terpisah, platform akan keluar dari mode layar terpisah dan
meluncurkan aktivitas yang tidak dapat diubah ukurannya dalam mode layar penuh.
Aplikasi yang secara eksplisit menetapkan atribut ini ke false
dalam
manifes tidak boleh diluncurkan dalam mode multi-aplikasi, kecuali jika mode
kompatibilitas diterapkan:
- Konfigurasi yang sama diterapkan ke proses, yang berisi semua aktivitas dan komponen non-aktivitas.
- Konfigurasi yang diterapkan memenuhi persyaratan CDD untuk layar yang kompatibel dengan aplikasi.
Di Android 10, platform ini masih mencegah aktivitas yang tidak dapat diubah ukurannya untuk masuk ke mode layar terpisah, tetapi aktivitas tersebut dapat disederhanakan untuk sementara jika aktivitas telah mendeklarasikan orientasi atau rasio aspek tetap. Jika tidak, aktivitas akan diubah ukurannya untuk mengisi seluruh layar seperti di Android 9 dan yang lebih rendah.
Implementasi default menerapkan kebijakan berikut:
Jika aktivitas dinyatakan tidak kompatibel dengan multi-aplikasi melalui
penggunaan atribut android:resizeableActivity
dan jika
aktivitas tersebut memenuhi salah satu kondisi yang dijelaskan di bawah, maka saat konfigurasi
layar yang diterapkan harus berubah, aktivitas dan proses akan disimpan dengan
konfigurasi asli dan pengguna akan diberi kemampuan untuk meluncurkan ulang
proses aplikasi untuk menggunakan konfigurasi layar yang diperbarui.
- Adalah orientasi tetap melalui penerapan
android:screenOrientation
- Aplikasi memiliki rasio aspek maksimum atau minimum default dengan menargetkan API level atau mendeklarasikan rasio aspek secara eksplisit
Gambar ini menampilkan aktivitas yang tidak dapat diubah ukurannya dengan rasio aspek yang dideklarasikan. Saat perangkat dilipat, jendela akan diskalakan ke bawah agar sesuai dengan area sekaligus mempertahankan rasio aspek menggunakan letterbox yang sesuai. Selain itu, opsi mulai ulang aktivitas disediakan kepada pengguna setiap kali area tampilan untuk aktivitas diubah.
Saat membentangkan perangkat, konfigurasi, ukuran, dan rasio aspek aktivitas tidak berubah, tetapi opsi untuk memulai ulang aktivitas akan ditampilkan.
Jika resizeableActivity
tidak ditetapkan (atau ditetapkan ke
true
), aplikasi sepenuhnya mendukung pengubahan ukuran.
Implementasi
Aktivitas yang tidak dapat diubah ukurannya dengan orientasi atau rasio aspek tetap disebut
mode kompatibilitas ukuran (SCM) dalam kode. Kondisi ditentukan di
ActivityRecord#shouldUseSizeCompatMode()
. Saat aktivitas SCM
diluncurkan, konfigurasi terkait layar (seperti ukuran atau kepadatan) diperbaiki
dalam konfigurasi penggantian yang diminta, sehingga aktivitas tidak lagi bergantung
pada konfigurasi tampilan saat ini.
Jika aktivitas SCM tidak dapat mengisi seluruh layar, aktivitas tersebut akan disejajarkan di bagian atas dan
dipusatkan secara horizontal. Batas aktivitas dihitung oleh
AppWindowToken#calculateCompatBoundsTransformation()
.
Jika aktivitas SCM menggunakan konfigurasi layar yang berbeda dengan
penampungnya (misalnya, ukuran layar diubah, atau aktivitas dipindahkan ke layar
lain), ActivityRecord#inSizeCompatMode()
bernilai benar dan
SizeCompatModeActivityController
(di UI Sistem) menerima
callback untuk menampilkan tombol mulai ulang proses.
Ukuran dan rasio aspek tampilan
Android 10 menyediakan dukungan untuk rasio aspek baru
dari rasio tinggi layar panjang dan tipis hingga rasio 1:1. Aplikasi dapat menentukan
ApplicationInfo#maxAspectRatio
dan ApplicationInfo#minAspectRatio
layar yang
dapat ditanganinya.
Gambar 1. Contoh rasio aplikasi yang didukung di Android 10
Implementasi perangkat dapat memiliki layar sekunder dengan ukuran dan
resolusi yang lebih kecil dari yang diperlukan oleh Android 9, dan lebih rendah (minimum lebar atau tinggi
2,5 inci, minimum 320 DP untuk smallestScreenWidth
),
tetapi hanya aktivitas yang memilih untuk mendukung layar kecil ini yang dapat ditempatkan
di sana.
Aplikasi dapat memilih ikut serta dengan mendeklarasikan ukuran minimum yang didukung yang lebih kecil dari
atau sama dengan ukuran tampilan target. Gunakan atribut tata letak aktivitas android:minHeight
dan
android:minWidth
di
AndroidManifest untuk melakukannya.
Menampilkan kebijakan
Android 10 memisahkan dan memindahkan kebijakan tampilan
tertentu dari penerapan WindowManagerPolicy
default di
PhoneWindowManager
ke class per tampilan, seperti:
- Status dan rotasi tampilan
- Beberapa tombol dan pelacakan peristiwa gerakan
- UI sistem dan jendela dekorasi
Di Android 9 (dan yang lebih rendah), class PhoneWindowManager
menangani
kebijakan tampilan, status dan setelan, rotasi, pelacakan frame jendela
dekorasi, dan lainnya. Android 10 memindahkan sebagian besar hal ini ke
class DisplayPolicy
, kecuali untuk pelacakan rotasi, yang telah
dipindahkan ke DisplayRotation
.
Setelan jendela tampilan
Di Android 10, setelan jendela per tampilan yang dapat dikonfigurasi telah diperluas untuk menyertakan:
- Mode jendela tampilan default
- Nilai overscan
- Rotasi pengguna dan mode rotasi
- Ukuran, kepadatan, dan mode penskalaan yang dipaksakan
- Mode penghapusan konten (saat tampilan dihapus)
- Dukungan untuk dekorasi sistem dan IME
Class DisplayWindowSettings
berisi setelan untuk opsi
ini. Data tersebut dipertahankan ke disk di partisi /data
di
display_settings.xml
setiap kali setelan diubah. Untuk
mengetahui detailnya, lihat DisplayWindowSettings.AtomicFileStorage
dan
DisplayWindowSettings#writeSettings()
. Produsen perangkat dapat
memberikan nilai default di display_settings.xml
untuk konfigurasi
perangkat mereka. Namun, karena file disimpan di /data
,
logika tambahan mungkin diperlukan untuk memulihkan file jika dihapus oleh penghapusan total.
Secara default, Android 10 menggunakan
DisplayInfo#uniqueId
sebagai ID untuk layar saat mempertahankan
setelan. uniqueId
harus diisi untuk semua tampilan. Selain itu, hal ini stabil untuk tampilan fisik dan jaringan. Anda juga dapat
menggunakan port layar fisik sebagai ID, yang dapat ditetapkan di
DisplayWindowSettings#mIdentifier
. Setelah setiap operasi tulis, semua setelan
akan ditulis sehingga aman untuk memperbarui kunci yang digunakan untuk entri tampilan di
penyimpanan. Untuk mengetahui detailnya, lihat
ID tampilan statis.
Setelan dipertahankan di direktori /data
karena alasan historis. Awalnya, setelan ini digunakan untuk mempertahankan setelan yang ditetapkan pengguna, seperti
rotasi layar.
ID tampilan statis
Android 9 (dan yang lebih lama) tidak menyediakan ID yang stabil untuk layar dalam
framework. Saat layar ditambahkan ke sistem,
Display#mDisplayId
atau DisplayInfo#displayId
dibuat untuk layar tersebut dengan menambahkan penghitung statis. Jika sistem
menambahkan dan menghapus tampilan yang sama, ID yang dihasilkan akan berbeda.
Jika perangkat memiliki beberapa tampilan yang tersedia dari booting, tampilan tersebut dapat
diberi ID yang berbeda, bergantung pada waktunya. Meskipun Android 9 (dan
versi sebelumnya) menyertakan DisplayInfo#uniqueId
, Android 9 tidak berisi informasi
yang cukup untuk membedakan antara layar karena layar fisik
diidentifikasi sebagai local:0
atau local:1
, untuk mewakili
layar bawaan dan eksternal.
Android 10 mengubah DisplayInfo#uniqueId
untuk menambahkan ID yang stabil dan membedakan antara layar lokal, jaringan, dan
virtual.
Jenis tampilan | Format |
---|---|
Lokal | local:<stable-id> |
Jaringan | network:<mac-address> |
Virtual | virtual:<package-name-and-name> |
Selain update ke uniqueId
,
DisplayInfo.address
berisi DisplayAddress
, ID tampilan yang stabil di seluruh mulai ulang. Di Android
10, DisplayAddress
mendukung tampilan
fisik dan jaringan. DisplayAddress.Physical
berisi ID tampilan
yang stabil (sama seperti di uniqueId
) dan dapat dibuat dengan
DisplayAddress#fromPhysicalDisplayId()
.
Android 10 juga menyediakan metode yang mudah untuk mendapatkan
informasi port (Physical#getPort()
). Metode ini dapat digunakan dalam
framework untuk mengidentifikasi layar secara statis. Misalnya, digunakan di
DisplayWindowSettings
). DisplayAddress.Network
berisi alamat MAC dan dapat dibuat dengan
DisplayAddress#fromMacAddress()
.
Penambahan ini memungkinkan produsen perangkat mengidentifikasi layar dalam
penyiapan multi-layar statis dan mengonfigurasi berbagai setelan dan fitur sistem
menggunakan ID layar statis, seperti port untuk layar fisik. Metode
ini disembunyikan dan hanya ditujukan untuk digunakan dalam
system_server
.
Dengan ID tampilan HWC (yang dapat buram dan tidak selalu stabil), metode
ini menampilkan nomor port 8-bit (khusus platform) yang mengidentifikasi
konektor fisik untuk output tampilan, serta blob EDID tampilan.
SurfaceFlinger mengekstrak informasi produsen atau model dari EDID untuk
menghasilkan ID tampilan 64-bit yang stabil yang diekspos ke framework. Jika metode ini
tidak didukung atau error, SurfaceFlinger akan kembali ke mode MD lama,
dengan DisplayInfo#address
null dan
DisplayInfo#uniqueId
di-hardcode, seperti yang dijelaskan di atas.
Untuk memverifikasi bahwa fitur ini didukung, jalankan:
$ dumpsys SurfaceFlinger --display-id # Example output. Display 21691504607621632 (HWC display 0): port=0 pnpId=SHP displayName="LQ123P1JX32" Display 9834494747159041 (HWC display 2): port=1 pnpId=HWP displayName="HP Z24i" Display 1886279400700944 (HWC display 1): port=2 pnpId=AUS displayName="ASUS MB16AP"
Menggunakan lebih dari dua layar
Di Android 9 (dan yang lebih lama), SurfaceFlinger dan DisplayManagerService
menganggap ada maksimal dua layar fisik dengan ID hard code 0
dan 1.
Mulai dari Android 10, SurfaceFlinger dapat memanfaatkan Hardware Composer (HWC) API untuk menghasilkan ID tampilan yang stabil, yang memungkinkannya mengelola jumlah tampilan fisik arbitrer. Untuk mempelajari lebih lanjut, lihat ID tampilan statis.
Framework dapat mencari token IBinder
untuk layar
fisik melalui SurfaceControl#getPhysicalDisplayToken
setelah mendapatkan
ID layar 64-bit dari SurfaceControl#getPhysicalDisplayIds
atau
dari peristiwa hotplug DisplayEventReceiver
.
Di Android 10 (dan yang lebih lama), layar internal utama adalah
TYPE_INTERNAL
dan semua layar sekunder ditandai sebagai TYPE_EXTERNAL
terlepas dari jenis koneksinya. Oleh karena itu, layar internal tambahan diperlakukan sebagai eksternal.
Sebagai solusi, kode khusus perangkat dapat membuat asumsi tentang
DisplayAddress.Physical#getPort
jika HWC diketahui dan logika alokasi
port dapat diprediksi.
Batasan ini dihapus di Android 11 (dan yang lebih baru).
- Di Android 11, layar pertama yang dilaporkan selama booting adalah layar utama. Jenis koneksi (internal versus eksternal) tidak relevan. Namun, tetap benar bahwa layar utama tidak dapat diputuskan dan mengikuti bahwa layar tersebut harus berupa layar internal dalam praktiknya. Perhatikan bahwa beberapa ponsel foldable memiliki beberapa layar internal.
- Layar sekunder dikategorikan dengan benar sebagai
Display.TYPE_INTERNAL
atauDisplay.TYPE_EXTERNAL
(sebelumnya dikenal sebagaiDisplay.TYPE_BUILT_IN
danDisplay.TYPE_HDMI
) bergantung pada jenis koneksinya.
Implementasi
Di Android 9 dan yang lebih lama, layar diidentifikasi dengan ID 32-bit,
dengan 0 adalah layar internal, 1 adalah layar eksternal, [2, INT32_MAX]
adalah layar virtual HWC, dan -1 mewakili layar yang tidak valid atau layar virtual non-HWC.
Mulai Android 10, layar diberi ID yang stabil
dan persisten, yang memungkinkan SurfaceFlinger dan DisplayManagerService
melacak lebih dari dua layar dan mengenali layar yang sebelumnya terlihat. Jika HWC
mendukung IComposerClient.getDisplayIdentificationData
dan menyediakan data
identifikasi tampilan, SurfaceFlinger akan mengurai struktur EDID dan mengalokasikan ID tampilan
64-bit yang stabil untuk tampilan fisik dan virtual HWC. ID dinyatakan menggunakan
jenis opsi, dengan nilai null mewakili tampilan yang tidak valid atau tampilan virtual
non-HWC. Tanpa dukungan HWC, SurfaceFlinger akan kembali ke perilaku lama dengan
maksimal dua layar fisik.
Fokus per layar
Untuk mendukung beberapa sumber input yang menargetkan setiap layar secara bersamaan, Android 10 dapat dikonfigurasi untuk mendukung beberapa jendela yang difokuskan, maksimal satu per layar. Hal ini hanya ditujukan untuk jenis perangkat khusus saat beberapa pengguna berinteraksi dengan perangkat yang sama pada waktu yang sama dan menggunakan metode atau perangkat input yang berbeda, seperti Android Automotive.
Sebaiknya fitur ini tidak diaktifkan untuk perangkat biasa, termasuk perangkat multilayar atau perangkat yang digunakan untuk pengalaman seperti desktop. Hal ini terutama disebabkan oleh masalah keamanan yang dapat menyebabkan pengguna bertanya-tanya jendela mana yang memiliki fokus input.
Bayangkan pengguna yang memasukkan informasi aman ke kolom input teks, mungkin login ke aplikasi perbankan atau memasukkan teks yang berisi informasi sensitif. Aplikasi berbahaya dapat membuat tampilan virtual di luar layar untuk menjalankan aktivitas, juga dengan kolom input teks. Aktivitas yang sah dan berbahaya memiliki fokus dan keduanya menampilkan indikator input aktif (kursor berkedip).
Namun, karena input dari keyboard (hardware atau software) hanya dimasukkan ke aktivitas teratas (aplikasi yang baru saja diluncurkan), dengan membuat layar virtual tersembunyi, aplikasi berbahaya dapat mengambil input pengguna, bahkan saat menggunakan keyboard virtual di layar perangkat utama.
Gunakan com.android.internal.R.bool.config_perDisplayFocusEnabled
untuk menetapkan fokus per tampilan.
Kompatibilitas
Masalah: Di Android 9 dan yang lebih lama, maksimal satu jendela di sistem memiliki fokus dalam satu waktu.
Solusi: Dalam kasus yang jarang terjadi saat dua jendela dari proses yang sama akan difokuskan, sistem hanya memberikan fokus ke jendela yang lebih tinggi dalam urutan Z. Batasan ini dihapus untuk aplikasi yang menargetkan Android 10, yang pada saat itu diharapkan dapat mendukung beberapa jendela yang difokuskan secara bersamaan.
Implementasi
WindowManagerService#mPerDisplayFocusEnabled
mengontrol
ketersediaan fitur ini. Di ActivityManager
,
ActivityDisplay#getFocusedStack()
kini digunakan, bukan pelacakan
global dalam variabel. ActivityDisplay#getFocusedStack()
menentukan fokus berdasarkan urutan Z, bukan meng-cache nilai. Hal ini agar
hanya satu sumber, WindowManager, yang perlu melacak urutan Z aktivitas.
ActivityStackSupervisor#getTopDisplayFocusedStack()
menggunakan
pendekatan serupa untuk kasus tersebut saat stack yang difokuskan paling atas dalam sistem
harus diidentifikasi. Stack dilalui dari atas ke bawah, menelusuri
stack pertama yang memenuhi syarat.
InputDispatcher
kini dapat memiliki beberapa jendela yang difokuskan
(satu per layar). Jika peristiwa input khusus layar, peristiwa tersebut akan dikirim
ke jendela yang difokuskan di layar yang sesuai. Jika tidak, pesan akan dikirim
ke jendela yang difokuskan di tampilan yang difokuskan, yaitu tampilan yang
paling baru berinteraksi dengan pengguna.
Lihat InputDispatcher::mFocusedWindowHandlesByDisplay
dan
InputDispatcher::setFocusedDisplay()
. Aplikasi yang difokuskan juga diperbarui
secara terpisah di InputManagerService melalui
NativeInputManager::setFocusedApplication()
.
Di WindowManager
, jendela yang difokuskan juga dilacak secara terpisah.
Lihat DisplayContent#mCurrentFocus
dan
DisplayContent#mFocusedApp
serta penggunaannya masing-masing. Metode pelacakan
dan pembaruan fokus terkait telah dipindahkan dari
WindowManagerService
ke DisplayContent
.