Senario
Anda menguruskan aplikasi Android yang menggabungkan View warisan, Jetpack Compose dan SDK pihak ketiga. Untuk aplikasi yang menyasarkan Android 16+, windowOptOutEdgeToEdgeEnforcement telah dibuang, jadi aplikasi mesti mengendalikan inset tetingkap dengan betul. Terangkan cara anda mencari risiko, mengubah susun atur, mengesahkan faktor bentuk peranti dan mengawal risiko pelepasan.
Perkara yang dinilai oleh penemu duga
- Memisahkan “berjalan secara serasi pada Android 16” daripada “menaikkan targetSdkVersion ke 16.”
- Memeriksa bar sistem, IME, potongan skrin (cutouts), kawasan gerak isyarat dan bekas tatalan secara sistematik.
- Merangkumi gabungan View, Compose, perpustakaan dan SDK.
- Mereka bentuk togol keserasian, pelepasan canary dan rollback yang boleh diperhatikan.
Soalan penjelasan
Sahkan SDK sasaran dan kompilasi, versi Android yang disokong, pecahan View/Compose, liputan potret/landskap dan peranti boleh lipat, serta penggunaan kamera skrin penuh, peta atau WebView. Minta garis dasar ujian tangkapan skrin, ranap sistem (crashes) dan aduan susun atur, serta sama ada SDK pihak ketiga mendokumentasikan sokongan edge-to-edge.
Jawapan 30 saat
Saya akan menggunakan dua fasa. Pertama, dedahkan perubahan tingkah laku pada Android 16 tanpa menaikkan sasaran, kemudian pisahkan pembetulan inset daripada peningkatan sasaran. Periksa susun atur induk (root), bar, IME, kawasan gerak isyarat dan penatalan merentasi View dan Compose. Hantar binaan khusus keserasian kepada kohort kecil dan pantau ranap sistem, aduan halangan visual (occlusion) dan penyelesaian aliran utama. Naikkan sasaran hanya selepas ujian regresi tangkapan skrin dan matriks peranti lulus. Pastikan perubahan sasaran diasingkan daripada ciri-ciri besar supaya susun atur yang bermasalah boleh diundur balik (rollback) dengan bersih.
Penaakulan langkah demi langkah
1. Pisahkan keserasian daripada peningkatan sasaran
Panduan migrasi Android mengesyorkan untuk menguji aplikasi sedia ada pada Android 16 terlebih dahulu; banyak pembetulan tidak memerlukan perubahan sasaran serta-merta. Kemudian selesaikan perubahan tingkah laku untuk aplikasi yang menyasarkan Android 16, memastikan punca regresi kekal jelas.
2. Bina senarai semak inset
Periksa sama ada susun atur induk menggunakan inset bar sistem dan sama ada bar alat, navigasi bawah, item senarai terakhir, medan input dan dialog terlindung. Tetapkan satu konvensyen inset untuk Compose dan elakkan padding berganda dalam View warisan. Uji skrin kamera, peta dan WebView dengan peraturan kawasan selamat (safe-area) masing-masing.
3. Gunakan alatan keserasian untuk mengecilkan skop
Togol keserasian Android 16 boleh mendayakan tingkah laku yang disasarkan tanpa mengubah targetSdkVersion. Tambahkannya pada matriks peranti automatik yang meliputi halaman 4 KB/16 KB, orientasi, navigasi tiga butang/gerak isyarat, peranti boleh lipat dan penskalaan fon. Rekod ID perubahan dan perbezaan tangkapan skrin.
4. Canary dan rollback
Hantar binaan keserasian khusus susun atur, kemudian naikkan sasaran dalam versi beta dan 1% trafik pengeluaran. Pantau ranap semasa pelancaran, ANR, kejayaan ketukan halaman utama, aduan halangan di bahagian bawah dan ralat SDK. Pastikan migrasi sasaran diasingkan; undur balik (rollback) ke binaan sebelumnya atau nyahdayakan entri yang terjejas apabila perlu.
Contoh jawapan berkualiti tinggi
Saya akan mewujudkan garis dasar keserasian dengan memasang binaan pengeluaran semasa pada emulator dan peranti fizikal Android 16, menjalankan setiap aliran dan menangkap kawasan tepi skrin. Kemudian saya hanya akan mendayakan tingkah laku edge-to-edge melalui togol keserasian untuk mengenal pasti sama ada susun atur induk, SDK atau perubahan sasaran yang menyebabkan isu tersebut. Saya akan membina satu lapisan pengendalian inset, menetapkan penggunaan atas, bawah dan IME secara eksplisit, serta mengelakkan padding berganda View/Compose; kamera, peta, WebView dan dialog mendapat ujian kawasan selamat yang berasingan. Hantar pembetulan keserasian tanpa mengubah sasaran. Selepas ujian tangkapan skrin, kebolehcapaian, orientasi, peranti boleh lipat dan IME lulus, naikkan sasaran sebagai perubahan terasing: beta dahulu, kemudian canary 1%. Jejak ranap sistem, ANR, penukaran teras dan maklum balas halangan; lakukan rollback atau nyahdayakan entri baharu jika berlaku regresi. Ini memenuhi perubahan platform sambil mengekalkan atribusi yang jelas dan keupayaan rollback.
Kesilapan lazim
- Menaikkan targetSdkVersion serta-merta dan kehilangan keupayaan atribusi regresi.
- Hanya membetulkan bar status tetapi terlepas pandang navigasi, IME, peranti boleh lipat, hujung senarai dan dialog.
- Menggunakan inset dalam pelbagai lapisan dan menghasilkan padding berganda.
- Menguji hanya pada emulator sambil mengabaikan SDK, peranti fizikal dan penskalaan fon.
- Menggabungkan migrasi edge-to-edge dengan ciri besar lalu kehilangan keupayaan rollback secara bebas.
Soalan susulan dan respons
“Adakah targetSdkVersion mesti menjadi 16 serta-merta?”
Tidak. Uji sasaran semasa pada Android 16 dan betulkan keserasian dahulu. Naik taraf sasaran secara berasingan mengikut keperluan Play dan perancangan masa produk.
“Bagaimanakah anda mengendalikan SDK pihak ketiga?”
Buat inventori SDK tersebut dan uji pada peranti fizikal dengan togol keserasian. Utamakan versi yang mendokumentasikan sokongan edge-to-edge; jika tidak, tambahkan pembalut safe-area atau asingkan skrin yang terjejas.
“Bagaimanakah anda membuktikan versi Android yang lebih lama masih berfungsi?”
Jalankan matriks tangkapan skrin dan aliran kritikal yang sama pada versi minimum yang disokong, Android 15 dan Android 16 merentasi orientasi, mod navigasi dan skala fon. Bandingkan kawasan yang boleh diketuk dan halangan visual, bukan sekadar kejayaan pelancaran aplikasi.