Diposting oleh Tim Android

Twitter mengandalkan Jetpack Compose untuk pengembangan fitur

Sebagai salah satu platform media sosial yang paling banyak digunakan, Twitter selalu mencari cara untuk menghubungkan penggunanya dengan lebih baik. Secara bersamaan, untuk membangun fitur baru secara efisien sambil mempertahankan fitur yang sudah ada, developer memerlukan infrastruktur yang mendukung. Tim engineer Twitter beralih ke Jetpack Compose untuk memulai perombakan yang sangat dibutuhkan fondasi UI aplikasi. Dengan Compose, developer bisa dengan mudah menemukan dan menggunakan API yang tepat, dengan cepat mengubah gaya dan memodulasi komponen, serta membangun lebih banyak dengan lebih sedikit kode.


Diposting oleh Tim Android

Twitter mengandalkan Jetpack Compose untuk pengembangan fitur

Sebagai salah satu platform media sosial yang paling banyak digunakan, Twitter selalu mencari cara untuk menghubungkan penggunanya dengan lebih baik. Secara bersamaan, untuk membangun fitur baru secara efisien sambil mempertahankan fitur yang sudah ada, developer memerlukan infrastruktur yang mendukung. Tim engineer Twitter beralih ke Jetpack Compose untuk memulai perombakan yang sangat dibutuhkan fondasi UI aplikasi. Dengan Compose, developer bisa dengan mudah menemukan dan menggunakan API yang tepat, dengan cepat mengubah gaya dan memodulasi komponen, serta membangun lebih banyak dengan lebih sedikit kode.

Twitter meluncurkan perombakan UI

Beberapa tim, seperti tim Android Client UI, Customer Acquisition, Twitter Blue, dan tim Komunitas, mengubah proses pengembangan mereka, yang menginspirasi kegembiraan di antara para engineer Twitter. “Beberapa tim di Twitter telah mengadopsi Compose dalam alur kerja harian mereka,” kata Sneha Patil, senior software engineer dan kepala teknis di tim Komunitas bagi Twitter untuk Android. Dengan menghapus pekerjaan membuat dan menyiapkan tema dan atribut khusus, Compose membuat fungsi penulisan dan penerapan persyaratan desain jauh lebih cepat dan lebih mudah daripada pengalaman mereka selama menggunakan Views. Jetpack Compose memungkinkan tim bekerja lebih cepat dan efektif, memastikan penggunaan kembali dalam kode mereka, dan dengan mudah mengajak engineer baru bergabung.


Merevitalisasi proses pengembangan

Membuat konten dinamis sangatlah mudah dengan Compose. Tim Twitter menggunakan composable LazyColumn untuk membangun UI tanpa memerlukan Adaptor atau ViewHolder, menyederhanakan proses penulisan kode yang secara mulus menghidupkan tata letak, tema, dan gaya. Dengan lebih sedikit baris yang ditulis, tim pengembangan di Twitter mengurangi boilerplate mereka, menemukan lebih sedikit bug selama pengembangan dan rilis, mengaktifkan eksperimen UI, dan mempercepat proses pengujian. Penyempurnaan ini meningkatkan produktivitas sehingga developer bisa menghabiskan lebih banyak waktu untuk membangun hal-hal yang membuat Twitter unik.

Mereka juga menggunakan Compose untuk membuat komponen stateless yang dapat digunakan kembali di seluruh aplikasi. Fleksibilitas Compose membuatnya lebih mudah dan cepat untuk memenuhi persyaratan desain, menjadikan pekerjaan pengaturan tema dan gaya lebih mudah bagi engineer baru dan berpengalaman.


Membangun fitur baru menggunakan Compose

Melihat peningkatan yang dialami, mereka memutuskan untuk membangun seluruh fitur baru menggunakan Compose. Mereka membangun fitur Komunitas, sebuah ruang khusus Twitter di mana pengguna bisa berinteraksi dalam diskusi yang mereka minati, dari awal menggunakan Compose. Berdasarkan pengalaman tim sebelumnya yang menggunakan Views untuk fitur lain, membangun dengan Compose jauh lebih cepat dengan bug lebih sedikit. “Ini seperti sulap,” kata Sneha, “Ini adalah pengubah permainan tentang bagaimana kami bisa mengembangkan di Android dengan Compose.

Kutipan dari Yoali Sotomayer Baqueiro

Compose meningkatkan output pengembangan

Compose meningkatkan kecepatan dan efisiensi pengembangan UI engineer Twitter. Developer dengan mudah menggabungkan dan membangun menggunakan Compose, yang memudahkan mereka untuk memodulasi kode, menggunakan kembali komponen, dan memecah dependensi. Tim secara rutin menggunakan eksperimen UI, dan Compose membantu meningkatkan kepercayaan diri mereka dengan mengetahui komponen yang bereaksi terhadap interaksi pengguna, update data, dan berbagai ukuran layar yang akan terlihat dalam produksi.

Keberhasilan awal tim ini dengan Compose menginspirasi tim pengembangan lain di Twitter untuk mengikutinya. Bahkan sekarang, engineer yang mengerjakan komponen lama yang kompleks sedang mempertimbangkan untuk mengadopsinya.

Secara umum, Compose tidak hanya menghilangkan banyak kendala yang dialami tim dalam Views — ia juga menambahkan kenikmatan ke dalam alur kerja, dengan beberapa developer siap untuk meninggalkan metode lama. “Saya senang sekali bisa menulis lebih banyak Compose dan tidak akan pernah menyentuh tata letak XML lagi,” kata Yoali Sotomayor Baqueiro, software engineer untuk Android Client UI di Twitter. “Ini membuat pengembangan UI tidak hanya lebih mudah tetapi juga jauh lebih menyenangkan dan intuitif.


Memulai

Optimalkan pengembangan UI Anda dengan Compose.


Logo Android13

Hari ini kami merilis Android 13 Beta ketiga, membawa kami ke fase siklus terakhir di mana kami berfokus pada penyempurnaan dan performa. Dengan Android 13, kami membangun tema inti tentang privasi dan keamanan, produktivitas developer, serta dukungan tablet dan layar besar.


Diposting oleh Dave Burke, VP of Engineering

Logo Android13

Hari ini kami merilis Android 13 Beta ketiga, membawa kami ke fase siklus terakhir di mana kami berfokus pada penyempurnaan dan performa. Dengan Android 13, kami membangun tema inti tentang privasi dan keamanan, produktivitas developer, serta dukungan tablet dan layar besar.

Banyak hal yang bisa dipelajari di Android 13, mulai dari fitur privasi seperti izin notifikasi baru dan pemilih foto, hingga fitur produktivitas seperti ikon aplikasi bertema dan dukungan bahasa per aplikasi, serta fitur standar modern seperti video HDR, Bluetooth LE Audio, dan MIDI 2.0 melalui USB. Kami juga memperluas update terbaru yang kami buat di 12L, sehingga memberi Anda alat yang lebih baik untuk memaksimalkan potensi lebih dari 270 juta tablet dan perangkat layar besar yang digunakan secara aktif.

Versi Beta 3 membawa Android 13 ke Stabilitas Platform, artinya sekarang API developer dan semua perilaku aplikasi sudah final. Kami berterima kasih atas semua masukan yang Anda berikan sehingga kami bisa mencapai titik ini! Untuk developer, fokusnya sekarang adalah menguji kompatibilitas dan kualitas saat Anda menyiapkan aplikasi untuk rilis resmi di akhir tahun!

Anda bisa mendapatkan versi Beta 3 di perangkat Pixel dengan mendaftar di sini untuk mendapatkan update over the air (OTA). Jika sebelumnya sudah mendaftar, Anda akan mendapatkan update hari ini secara otomatis. Anda juga bisa mencoba Android 13 Beta di perangkat tertentu dari beberapa mitra kami - pelajari lebih lanjut di android.com/beta. Baca terus untuk melihat sekilas tentang cara menyiapkan aplikasi Anda, dan kunjungi situs developer Android 13 untuk detailnya.


Stabilitas Platform

Dengan versi Beta 3, Android 13 mencapai Stabilitas Platform, sebuah tahap pencapaian yang berarti semua perilaku aplikasi dan API, termasuk API NDK dan API Level 33 SDK resmi, kini sudah final. Jadi dari versi Beta 3, Anda bisa percaya diri mengembangkan dan merilis update kompatibilitas karena tahu bahwa platform ini tidak akan berubah.

Lini masa stabilitas platform dengan versi stabil ditandai pada bulan Juni

Kami meminta semua developer aplikasi dan game untuk memulai pengujian kompatibilitas akhir sekarang dan bersiap memublikasikan update kompatibilitas Anda sesegera mungkin sebelum rilis final.

Untuk semua developer SDK, library, fitur, dan game engine, perlu sekali memulai pengujian sekarang dan merilis update yang kompatibel sesegera mungkin -- developer hilir aplikasi dan game Anda mungkin diblokir hingga mereka menerima update. Jadi ketika Anda sudah merilis update yang kompatibel, umumkan dan beri tahu developer!


Kompatibilitas aplikasi

Kompatibilitas aplikasi berarti aplikasi Anda berjalan sesuai harapan pada platform versi baru. Dengan setiap rilis, kami membuat perubahan integral pada platform untuk meningkatkan privasi dan keamanan serta pengalaman pengguna secara seluruh di OS. Ini bisa memengaruhi aplikasi Anda, jadi sangatlah penting untuk menguji aplikasi Anda sekarang, membuat update yang diperlukan, dan memublikasikan update yang kompatibel kepada pengguna sebelum rilis final. Ini adalah dasar tetapi merupakan faktor kualitas penting yang akan disukai oleh pengguna Anda saat mereka mempelajari hal hal baru di Android 13.

Untuk menguji kompatibilitas aplikasi Anda, cukup instal aplikasi produksi dari Google Play atau sumber lain ke perangkat yang menjalankan Android 13 Beta 3. Ikuti semua alur aplikasi dan perhatikan masalah fungsionalitas atau UI. Tinjau perubahan perilaku untuk memfokuskan pengujian Anda. Berikut ini beberapa perubahan yang harus diperhatikan:

  • Izin runtime untuk notifikasi - Android 13 memperkenalkan izin runtime baru untuk mengirim notifikasi dari aplikasi. Pastikan Anda memahami cara kerja izin baru ini, dan menargetkan Android 13 (API 33) sesegera mungkin. Selengkapnya di sini.
  • Pratinjau papan klip - Pastikan aplikasi Anda menyembunyikan data sensitif di pratinjau papan klip baru Android 13, seperti kata sandi atau informasi kartu kredit. Selengkapnya di sini.
  • Pengambilan data JobScheduler - JobScheduler sekarang mengantisipasi peluncuran berikutnya aplikasi Anda dan akan terlebih dahulu menjalankan tugas pengambilan data yang dibutuhkan. Jika Anda menggunakan tugas pengambilan data, uji apakah tugas tersebut berfungsi seperti yang diharapkan. Selengkapnya di sini.

Ingatlah juga untuk menguji kompatibilitas library dan SDK di aplikasi Anda. Jika Anda menemukan masalah, cobalah update ke versi library atau SDK terbaru atau hubungi developer untuk mendapatkan bantuan.

Setelah memublikasikan versi aplikasi yang kompatibel, Anda bisa memulai proses untuk meng-update targetSdkVersion aplikasi. Tinjau perubahan perilaku untuk aplikasi yang menargetkan Android 13 dan gunakan framework kompatibilitas untuk membantu Anda mendeteksi masalah dengan cepat. Berikut ini beberapa perubahan yang perlu diuji (ini hanya berlaku untuk aplikasi dengan targetSdkVersion disetel ke API 33 atau yang lebih tinggi):

  • Izin perangkat di sekitar untuk Wi-Fi - Aplikasi yang mengelola koneksi perangkat ke titik akses terdekat harus menggunakan izin runtime NEARBY_WIFI_DEVICES baru untuk operasi Wi-Fi seperti pemindaian, tanpa memerlukan akses ke lokasi perangkat. Beberapa API Wi-Fi mengharuskan aplikasi Anda memiliki izin baru ini. Selengkapnya di sini.
  • Izin media terperinci - Jika aplikasi Anda menargetkan Android 13 dan membaca file media dari penyimpanan data biasa, Anda harus meminta satu atau beberapa izin terperinci baru, sebagai ganti izin READ_EXTERNAL_STORAGE. Selengkapnya di sini.
  • Perubahan izin untuk sensor tubuh - Android 13 memperkenalkan akses "saat digunakan" untuk sensor tubuh. Jika aplikasi Anda perlu mengakses informasi sensor tubuh dari latar belakang, aplikasi harus mendeklarasikan izin BODY_SENSORS_BACKGROUND yang baru. Selengkapnya di sini.
  • Filter intent memblokir intent yang tidak cocok - Jika aplikasi Anda mengirim intent ke komponen yang diekspor dari aplikasi lain yang menargetkan Android 13 (API 33) atau yang lebih tinggi, intent tersebut harus sama dengan filter intent di aplikasi penerima. Selengkapnya di sini.
  • Kontrol media yang berasal dari PlaybackState - Android 13 mendapatkan lebih banyak kontrol media dari tindakan PlaybackState, untuk menampilkan kumpulan kontrol yang beragam dan konsisten pada berbagai tipe perangkat. Pastikan aplikasi Anda menangani perubahan ini. Selengkapnya di sini

Dukungan tablet dan layar besar

Android 13 dibangun di atas pengoptimalan tablet yang diperkenalkan di 12L, jadi sebagai bagian dari pengujian, pastikan aplikasi Anda tampil optimal di tablet dan perangkat layar besar lainnya. Anda bisa mengujinya menggunakan fitur layar besar dengan menyiapkan emulator Android di Android Studio, atau Anda dapat menggunakan perangkat layar besar dari mitra Android 13 Beta kami. Berikut ini beberapa area yang harus diperhatikan:

  • Interaksi taskbar - Lihat cara aplikasi Anda merespons saat dilihat dengan taskbar baru di layar besar. Pastikan UI aplikasi Anda tidak terpotong atau diblokir oleh taskbar. Selengkapnya di sini.
  • Mode multi-jendela - Mode multi-jendela sekarang diaktifkan secara default untuk semua aplikasi, terlepas dari konfigurasi aplikasi, jadi pastikan aplikasi menangani split-screen dengan tepat. Anda bisa mengujinya dengan menarik dan melepaskan aplikasi ke mode split-screen dan mengatur ukuran jendela. Selengkapnya di sini.
  • Pengalaman kompatibilitas yang disempurnakan - jika aplikasi Anda belum dioptimalkan untuk tablet, seperti menggunakan orientasi tetap atau tidak dapat diubah ukurannya, periksa cara aplikasi Anda merespons penyesuaian mode kompatibilitas seperti letterboxing. Selengkapnya di sini.
  • Proyeksi media - Jika aplikasi Anda menggunakan proyeksi media, periksa cara aplikasi Anda merespons saat memutar, streaming, atau mentransmisikan media di layar besar. Pastikan juga memperhitungkan perubahan posisi perangkat pada perangkat foldable. Selengkapnya di sini.
  • Pratinjau Kamera - Untuk aplikasi kamera, periksa cara UI mempratinjau kamera merespons di layar besar saat aplikasi Anda dibatasi ke sebagian layar dalam mode multi-jendela atau mode split-screen. Periksa juga cara aplikasi Anda merespons saat posisi perangkat foldable berubah. Selengkapnya di sini.

Anda bisa membaca selengkapnya tentang fitur tablet di Android 13 dan hal-hal yang harus diuji di sini.


Memulai dengan Android 13!

Rilis Beta hari ini memiliki semua yang Anda butuhkan untuk menguji aplikasi dan mencoba fitur Android 13. Cukup daftarkan perangkat Pixel Anda untuk mendapatkan update over the air (OTA). Untuk memulai, siapkan Android 13 SDK.

Anda juga bisa menguji aplikasi dengan Android 13 Beta di perangkat dari beberapa mitra kami. Kunjungi android.com/beta untuk melihat daftar mitra selengkapnya, dengan link ke situs mereka untuk mendapatkan detail tentang perangkat yang didukung dan versi Beta, dimulai dengan versi Beta 1. Setiap mitra akan menangani pendaftaran dan dukungan mereka sendiri, serta memberikan update versi Beta kepada Anda secara langsung. Untuk pengujian yang lebih luas, Anda bisa mencoba Android 13 Beta 3 pada image GSI Android, dan jika tidak memiliki perangkat, Anda dapat mengujinya di Android Emulator.

Untuk detail selengkapnya tentang Android 13, kunjungi situs developer Android 13.




Diposting oleh Dave Burke, VP of Engineering

Logo Android13

Hari ini kami merilis Android 13 Beta ketiga, membawa kami ke fase siklus terakhir di mana kami berfokus pada penyempurnaan dan performa. Dengan Android 13, kami membangun tema inti tentang privasi dan keamanan, produktivitas developer, serta dukungan tablet dan layar besar.

Banyak hal yang bisa dipelajari di Android 13, mulai dari fitur privasi seperti izin notifikasi baru dan pemilih foto, hingga fitur produktivitas seperti ikon aplikasi bertema dan dukungan bahasa per aplikasi, serta fitur standar modern seperti video HDR, Bluetooth LE Audio, dan MIDI 2.0 melalui USB. Kami juga memperluas update terbaru yang kami buat di 12L, sehingga memberi Anda alat yang lebih baik untuk memaksimalkan potensi lebih dari 270 juta tablet dan perangkat layar besar yang digunakan secara aktif.

Versi Beta 3 membawa Android 13 ke Stabilitas Platform, artinya sekarang API developer dan semua perilaku aplikasi sudah final. Kami berterima kasih atas semua masukan yang Anda berikan sehingga kami bisa mencapai titik ini! Untuk developer, fokusnya sekarang adalah menguji kompatibilitas dan kualitas saat Anda menyiapkan aplikasi untuk rilis resmi di akhir tahun!

Anda bisa mendapatkan versi Beta 3 di perangkat Pixel dengan mendaftar di sini untuk mendapatkan update over the air (OTA). Jika sebelumnya sudah mendaftar, Anda akan mendapatkan update hari ini secara otomatis. Anda juga bisa mencoba Android 13 Beta di perangkat tertentu dari beberapa mitra kami - pelajari lebih lanjut di android.com/beta. Baca terus untuk melihat sekilas tentang cara menyiapkan aplikasi Anda, dan kunjungi situs developer Android 13 untuk detailnya.


Stabilitas Platform

Dengan versi Beta 3, Android 13 mencapai Stabilitas Platform, sebuah tahap pencapaian yang berarti semua perilaku aplikasi dan API, termasuk API NDK dan API Level 33 SDK resmi, kini sudah final. Jadi dari versi Beta 3, Anda bisa percaya diri mengembangkan dan merilis update kompatibilitas karena tahu bahwa platform ini tidak akan berubah.

Lini masa stabilitas platform dengan versi stabil ditandai pada bulan Juni

Kami meminta semua developer aplikasi dan game untuk memulai pengujian kompatibilitas akhir sekarang dan bersiap memublikasikan update kompatibilitas Anda sesegera mungkin sebelum rilis final.

Untuk semua developer SDK, library, fitur, dan game engine, perlu sekali memulai pengujian sekarang dan merilis update yang kompatibel sesegera mungkin -- developer hilir aplikasi dan game Anda mungkin diblokir hingga mereka menerima update. Jadi ketika Anda sudah merilis update yang kompatibel, umumkan dan beri tahu developer!


Kompatibilitas aplikasi

Kompatibilitas aplikasi berarti aplikasi Anda berjalan sesuai harapan pada platform versi baru. Dengan setiap rilis, kami membuat perubahan integral pada platform untuk meningkatkan privasi dan keamanan serta pengalaman pengguna secara seluruh di OS. Ini bisa memengaruhi aplikasi Anda, jadi sangatlah penting untuk menguji aplikasi Anda sekarang, membuat update yang diperlukan, dan memublikasikan update yang kompatibel kepada pengguna sebelum rilis final. Ini adalah dasar tetapi merupakan faktor kualitas penting yang akan disukai oleh pengguna Anda saat mereka mempelajari hal hal baru di Android 13.

Untuk menguji kompatibilitas aplikasi Anda, cukup instal aplikasi produksi dari Google Play atau sumber lain ke perangkat yang menjalankan Android 13 Beta 3. Ikuti semua alur aplikasi dan perhatikan masalah fungsionalitas atau UI. Tinjau perubahan perilaku untuk memfokuskan pengujian Anda. Berikut ini beberapa perubahan yang harus diperhatikan:

  • Izin runtime untuk notifikasi - Android 13 memperkenalkan izin runtime baru untuk mengirim notifikasi dari aplikasi. Pastikan Anda memahami cara kerja izin baru ini, dan menargetkan Android 13 (API 33) sesegera mungkin. Selengkapnya di sini.
  • Pratinjau papan klip - Pastikan aplikasi Anda menyembunyikan data sensitif di pratinjau papan klip baru Android 13, seperti kata sandi atau informasi kartu kredit. Selengkapnya di sini.
  • Pengambilan data JobScheduler - JobScheduler sekarang mengantisipasi peluncuran berikutnya aplikasi Anda dan akan terlebih dahulu menjalankan tugas pengambilan data yang dibutuhkan. Jika Anda menggunakan tugas pengambilan data, uji apakah tugas tersebut berfungsi seperti yang diharapkan. Selengkapnya di sini.

Ingatlah juga untuk menguji kompatibilitas library dan SDK di aplikasi Anda. Jika Anda menemukan masalah, cobalah update ke versi library atau SDK terbaru atau hubungi developer untuk mendapatkan bantuan.

Setelah memublikasikan versi aplikasi yang kompatibel, Anda bisa memulai proses untuk meng-update targetSdkVersion aplikasi. Tinjau perubahan perilaku untuk aplikasi yang menargetkan Android 13 dan gunakan framework kompatibilitas untuk membantu Anda mendeteksi masalah dengan cepat. Berikut ini beberapa perubahan yang perlu diuji (ini hanya berlaku untuk aplikasi dengan targetSdkVersion disetel ke API 33 atau yang lebih tinggi):

  • Izin perangkat di sekitar untuk Wi-Fi - Aplikasi yang mengelola koneksi perangkat ke titik akses terdekat harus menggunakan izin runtime NEARBY_WIFI_DEVICES baru untuk operasi Wi-Fi seperti pemindaian, tanpa memerlukan akses ke lokasi perangkat. Beberapa API Wi-Fi mengharuskan aplikasi Anda memiliki izin baru ini. Selengkapnya di sini.
  • Izin media terperinci - Jika aplikasi Anda menargetkan Android 13 dan membaca file media dari penyimpanan data biasa, Anda harus meminta satu atau beberapa izin terperinci baru, sebagai ganti izin READ_EXTERNAL_STORAGE. Selengkapnya di sini.
  • Perubahan izin untuk sensor tubuh - Android 13 memperkenalkan akses "saat digunakan" untuk sensor tubuh. Jika aplikasi Anda perlu mengakses informasi sensor tubuh dari latar belakang, aplikasi harus mendeklarasikan izin BODY_SENSORS_BACKGROUND yang baru. Selengkapnya di sini.
  • Filter intent memblokir intent yang tidak cocok - Jika aplikasi Anda mengirim intent ke komponen yang diekspor dari aplikasi lain yang menargetkan Android 13 (API 33) atau yang lebih tinggi, intent tersebut harus sama dengan filter intent di aplikasi penerima. Selengkapnya di sini.
  • Kontrol media yang berasal dari PlaybackState - Android 13 mendapatkan lebih banyak kontrol media dari tindakan PlaybackState, untuk menampilkan kumpulan kontrol yang beragam dan konsisten pada berbagai tipe perangkat. Pastikan aplikasi Anda menangani perubahan ini. Selengkapnya di sini

Dukungan tablet dan layar besar

Android 13 dibangun di atas pengoptimalan tablet yang diperkenalkan di 12L, jadi sebagai bagian dari pengujian, pastikan aplikasi Anda tampil optimal di tablet dan perangkat layar besar lainnya. Anda bisa mengujinya menggunakan fitur layar besar dengan menyiapkan emulator Android di Android Studio, atau Anda dapat menggunakan perangkat layar besar dari mitra Android 13 Beta kami. Berikut ini beberapa area yang harus diperhatikan:

  • Interaksi taskbar - Lihat cara aplikasi Anda merespons saat dilihat dengan taskbar baru di layar besar. Pastikan UI aplikasi Anda tidak terpotong atau diblokir oleh taskbar. Selengkapnya di sini.
  • Mode multi-jendela - Mode multi-jendela sekarang diaktifkan secara default untuk semua aplikasi, terlepas dari konfigurasi aplikasi, jadi pastikan aplikasi menangani split-screen dengan tepat. Anda bisa mengujinya dengan menarik dan melepaskan aplikasi ke mode split-screen dan mengatur ukuran jendela. Selengkapnya di sini.
  • Pengalaman kompatibilitas yang disempurnakan - jika aplikasi Anda belum dioptimalkan untuk tablet, seperti menggunakan orientasi tetap atau tidak dapat diubah ukurannya, periksa cara aplikasi Anda merespons penyesuaian mode kompatibilitas seperti letterboxing. Selengkapnya di sini.
  • Proyeksi media - Jika aplikasi Anda menggunakan proyeksi media, periksa cara aplikasi Anda merespons saat memutar, streaming, atau mentransmisikan media di layar besar. Pastikan juga memperhitungkan perubahan posisi perangkat pada perangkat foldable. Selengkapnya di sini.
  • Pratinjau Kamera - Untuk aplikasi kamera, periksa cara UI mempratinjau kamera merespons di layar besar saat aplikasi Anda dibatasi ke sebagian layar dalam mode multi-jendela atau mode split-screen. Periksa juga cara aplikasi Anda merespons saat posisi perangkat foldable berubah. Selengkapnya di sini.

Anda bisa membaca selengkapnya tentang fitur tablet di Android 13 dan hal-hal yang harus diuji di sini.


Memulai dengan Android 13!

Rilis Beta hari ini memiliki semua yang Anda butuhkan untuk menguji aplikasi dan mencoba fitur Android 13. Cukup daftarkan perangkat Pixel Anda untuk mendapatkan update over the air (OTA). Untuk memulai, siapkan Android 13 SDK.

Anda juga bisa menguji aplikasi dengan Android 13 Beta di perangkat dari beberapa mitra kami. Kunjungi android.com/beta untuk melihat daftar mitra selengkapnya, dengan link ke situs mereka untuk mendapatkan detail tentang perangkat yang didukung dan versi Beta, dimulai dengan versi Beta 1. Setiap mitra akan menangani pendaftaran dan dukungan mereka sendiri, serta memberikan update versi Beta kepada Anda secara langsung. Untuk pengujian yang lebih luas, Anda bisa mencoba Android 13 Beta 3 pada image GSI Android, dan jika tidak memiliki perangkat, Anda dapat mengujinya di Android Emulator.

Untuk detail selengkapnya tentang Android 13, kunjungi situs developer Android 13.


Sebagai bagian dari upaya kami memodernisasi panduan arsitektur aplikasi, kami ingin bereksperimen dengan pola UI berbeda untuk mengetahui pola terbaik, menemukan persamaan dan perbedaan di antara beberapa alternatifnya, dan pada akhirnya menggabungkan pembelajaran tersebut sebagai praktik terbaik.


Sebagai bagian dari upaya kami memodernisasi panduan arsitektur aplikasi, kami ingin bereksperimen dengan pola UI berbeda untuk mengetahui pola terbaik, menemukan persamaan dan perbedaan di antara beberapa alternatifnya, dan pada akhirnya menggabungkan pembelajaran tersebut sebagai praktik terbaik.

Agar temuan kami mudah diikuti, kami membutuhkan sampel yang memiliki kasus bisnis yang familier dan tidak terlalu rumit. Dan… siapa yang tidak tahu dengan aplikasi TODO ? Kami memilih Architecture Blueprints! Secara historis, Blueprints berfungsi sebagai taman bermain eksperimental untuk pilihan arsitektur. Sangat cocok untuk ini!

Aplikasi Architecture Blueprints sedang digunakan

Pola yang ingin kami uji jelas dipengaruhi oleh berbagai API yang tersedia saat ini. API terbaru saat ini adalah Jetpack Compose State API! Karena Compose bekerja secara mulus dengan setiap pola Aliran Data Searah , kami akan menggunakan Compose untuk merender UI guna membuat perbandingan yang adil.

Postingan blog ini menceritakan cara tim memigrasikan Architecture Blueprints ke Jetpack Compose. Karena LiveData juga dianggap sebagai alternatif dalam eksperimen, kami membiarkan sampel seperti pada saat migrasi. Dalam pemfaktoran ulang ini, class ViewModel dan layer data tidak disentuh.

⚠️ Arsitektur yang digunakan dalam codebase berbasis LiveData ini tidak sepenuhnya mengikuti praktik terbaik arsitektur terbaru. Secara khusus, LiveData tidak boleh digunakan dalam layer data atau domain — Flows dan coroutine bisa digunakan sebagai gantinya.

Sekarang setelah konteksnya jelas, mari kita dalami cara melakukan pendekatan pemfaktoran ulang Blueprints ke Jetpack Compose. Anda bisa melihat kode lengkapnya di cabang dev-compose.

✍️ Merencanakan migrasi bertahap

Sebelum benar-benar mengerjakan coding, tim membuat rencana migrasi untuk memastikan semua orang setuju dengan perubahan yang diusulkan. Tujuan utamanya adalah menjadikan Blueprints sebagai aplikasi aktivitas tunggal dengan layar sebagai fungsi yang dapat dikomposisi, dan menggunakan library Compose Navigation yang direkomendasikan untuk berpindah antar layar.

Untungnya, Blueprints sudah menjadi aplikasi aktivitas tunggal yang menggunakan Jetpack Navigation untuk berpindah antar layar yang diimplementasikan dengan Fragment. Untuk bermigrasi ke Compose, kami mengikuti panduan interoperabilitas Navigation yang merekomendasikan aplikasi hibrid untuk menggunakan komponen Navigation berbasis fragmen dan menggunakan fragmen untuk menahan layar berbasis tampilan, layar Compose, serta layar yang menggunakan tampilan dan Compose. Sayangnya, tidak mungkin menggabungkan tujuan Fragment dan Compose dalam grafik Navigation yang sama.

Tujuan dari migrasi bertahap ini adalah untuk memudahkan peninjauan kode dan menjaga produk yang dapat dikirim selama migrasi. Rencana migrasi melibatkan tiga langkah:

  1. Migrasikan konten setiap layar ke Compose. Setiap layar dapat dimigrasikan satu per satu ke Compose, termasuk pengujian UI-nya. Fragmen kemudian menjadi container/host dari setiap layar yang dimigrasikan.
  2. Migrasikan aplikasi ke Navigation Compose — yang menghapus semua Fragmen dari project — dan migrasikan logika UI Activity ke composable root. Pengujian end-to-end juga dimigrasikan pada titik ini.
  3. Hapus dependensi sistem Tampilan.

Dan itulah yang kami lakukan! 🧑‍💻 Maju cepat ⏩ dua minggu, kami melakukan migrasi layar Layar Statistik (PR), layar Tambah/Edit tugas (PR), layar Detail tugas (PR), dan layar Tugas (PR); dan kami menggabungkan PR final yang memigrasikan logika Navigation dan Activity ke Compose, termasuk menghapus dependensi sistem Tampilan yang tidak digunakan.

Cara kami memigrasikan Blueprints ke Compose secara bertahap

💡 Sorotan migrasi

Selama migrasi, kami menemukan beberapa ciri khusus Compose yang perlu disoroti:

🧪 Pengujian UI

Setelah Anda mulai menambahkan Compose ke aplikasi, pengujian yang menyatakan UI Compose harus menggunakan API pengujian Compose.

Untuk pengujian UI tingkat layar, sebagai ganti menggunakan API launchFragmentInContainer<FragmentType>, kami menggunakan API createAndroidComposeRule<ComponentActivity> yang memungkinkan kami mengambil resource string dalam pengujian. Pengujian ini berjalan dalam Espresso dan Robolectric. Karena Compose sudah mendukung ini semua, maka tidak diperlukan perubahan tambahan. Sebagai contoh, Anda bisa membandingkan kode dalam AddEditTaskFragmentTest yang dimigrasikan ke AddEditTaskScreenTest. Perhatikan, jika menggunakan ComponentActivity, Anda harus bergantung pada artefak androidx.compose.ui:ui-test-manifest.

Untuk pengujian integrasi atau end-to-end, kami juga tidak menemukan masalah! Berkat interoperabilitas Espresso dan Compose, kami menggunakan pernyataan Espresso untuk memeriksa Tampilan, dan API Compose untuk memeriksa UI Compose. Inilah sekilas tampilan AppNavigationTest selama migrasi ke Compose.

🤙 Event ViewModel

Kami memang memiliki masalah dengan cara menangani event ViewModel di Blueprints. Blueprints menerapkan solusi Event wrapper untuk mengirim perintah dari ViewModel ke UI. Namun, itu bukan sesuatu yang bisa berfungsi di Compose. Panduan terbaru kami merekomendasikan pemodelan “event” tersebut sebagai status, dan itulah yang kami lakukan selama migrasi.

Dengan melihat kasus penggunaan event menampilkan pesan di layar , kami mengganti tipe Event<Int> dari LiveData menjadi Int? Ini juga memodelkan skenario ketika tidak ada pesan untuk ditampilkan kepada pengguna. Dalam kasus penggunaan khusus ini, ViewModel juga memerlukan konfirmasi dari UI setiap kali pesan ditampilkan. Lihat perbedaan antara kedua implementasinya dalam kode berikut:

Meskipun sekilas mungkin terlihat lebih merepotkan, ini menjamin setiap pesan ditampilkan di layar!

Dalam kode UI, cara untuk memastikan event hanya ditangani sekali adalah dengan memanggil event.getContentIfNotHandled(). Pendekatan ini bekerja dengan baik di Fragmen tetapi gagal di Compose! Karena rekomposisi dapat terjadi sewaktu-waktu di Compose, event wrapper bukanlah solusi yang cocok. Jika event diproses dan fungsinya dikomposisi ulang (sesuatu yang sering terjadi saat menguji pendekatan ini), maka snackbar akan dibatalkan, dan pengguna mungkin melewatkan pesannya. Ini adalah masalah UX yang tidak dapat diterima! Solusi event wrapper tidak boleh digunakan di aplikasi Compose.

Lihat cuplikan kode berikut dengan kode sebelum (event wrapper) dan setelah (event as state). Karena menampilkan pesan di layar adalah logika UI dan composable layar semakin kompleks, kami menggunakan class holder status biasa untuk mengelola kompleksitas itu (mis. lihat AddEditTaskState).

👌 Jika ragu, pilih kebenaran aplikasi

Saat pemfaktoran ulang, Anda mungkin tergoda untuk memigrasikan semua yang ada ke Compose. Meskipun bukan masalah, Anda tidak boleh mengorbankan Pengalaman Pengguna atau kebenaran aplikasi Anda. Inti dari memigrasikan bertahap adalah aplikasi selalu dalam status dapat dikirim.

Ini terjadi pada kami saat memigrasikan beberapa layar ke Compose. Kami tidak ingin melakukan terlalu banyak migrasi secara bersamaan, dan memigrasikan beberapa layar ke Compose sebelum memigrasikan dari Event wrapper. Sebagai ganti menangani Event wrapper di Compose dan memberikan pengalaman yang kurang optimal, kami terus menangani pesan-pesan tersebut di Fragmen sedangkan kode lainnya untuk layar di Compose. Sebagai contoh, lihat status TasksFragment selama migrasi.

🧐 Tantangan

Tidak semuanya berjalan semulus kelihatannya. 🫤 Meskipun mengonversi isi Fragmen ke Compose sangatlah mudah, melakukan migrasi dari Navigation Fragment ke Navigation Compose membutuhkan banyak waktu dan pertimbangan.

Ada kebutuhan untuk memperluas dan menyempurnakan panduan mengenai berbagai aspek yang akan mempermudah migrasi ke Compose di masa mendatang. Pekerjaan ini memicu percakapan dan kami berharap bisa segera mendapatkan panduan baru tentang hal ini! 🎊

Sebagai pemula Navigation ✋ dan orang yang menangani migrasi ke Navigation Compose, saya menghadapi tantangan berikut:

  • Tidak ada kode dalam dokumen yang menunjukkan cara menavigasi dengan argumen opsional! Berkat grafik navigasi Tivi, saya menemukan cara dan memecahkan masalahnya (ikuti masalah untuk meningkatkan dokumen di sini).
  • Memigrasikan dari grafik Navigation berbasis XML dan SafeArgs ke Kotlin DSL seharusnya merupakan tugas mekanis yang mudah. Namun, ternyata tidak mudah mengingat saya tidak mengerjakan implementasi aslinya. Beberapa panduan tentang cara melakukannya dengan benar akan membantu saya (mengikuti masalah untuk meningkatkan dokumen di sini).
  • Bukan sekadar tantangan, poin ini adalah sebuah kemenangan besar! UI Navigation sudah melakukan beberapa tugas untuk Anda dalam hal navigasi. Karena ini tidak tersedia di Compose, Anda harus mengawasinya dan melakukannya secara manual. Sebagai contoh, menjaga backstack tetap bersih saat membuka beberapa layar Panel Samping memerlukan NavigationOptions khusus (lihat contohnya di sini). Hal ini sudah dibahas dalam dokumen, tetapi Anda perlu menyadari bahwa Anda membutuhkannya!

🧑‍🏫 Kesimpulan

Secara keseluruhan, melakukan migrasi dari Navigation Fragment ke Navigation Compose adalah tugas yang menyenangkan untuk dilakukan! Lucunya, kami menghabiskan banyak waktu menunggu tinjauan pembanding daripada memigrasikan proyek itu sendiri! Membuat rencana migrasi dan mengarahkan semua orang ke area yang sama pasti membantu menetapkan ekspektasi lebih awal dan memperingatkan rekan-rekan tentang ulasan yang masuk.

Kami harap Anda senang membaca pendekatan kami tentang migrasi ke Compose, dan kami berharap bisa berbagi lebih banyak hal tentang eksperimen dan peningkatan yang akan kami kerjakan dalam Architecture Blueprints.

Jika Anda tertarik melihat Blueprints dengan kode Compose, lihat cabang dev-compose. Dan jika Anda ingin melihat PR dari migrasi bertahap, berikut daftarnya:

👋


Diposting oleh Marwa Mabrouk, Android Camera Platform Product Manager

tangan memegang ponsel

Kamera Android adalah bidang yang menarik. Kamera merupakan salah satu alasan utama konsumen membeli ponsel. Kamera Android sekarang mendukung developer melalui berbagai alat. Camera 2 adalah API framework yang disertakan dalam Android sejak Android 5.0 Lollipop, dan CameraX adalah library dukungan Jetpack yang berjalan di atas Camera 2, dan tersedia untuk semua developer Android. Solusi ini dimaksudkan untuk saling melengkapi dalam memenuhi kebutuhan ekosistem Kamera Android.


Diposting oleh Marwa Mabrouk, Android Camera Platform Product Manager

tangan memegang ponsel

Kamera Android adalah bidang yang menarik. Kamera merupakan salah satu alasan utama konsumen membeli ponsel. Kamera Android sekarang mendukung developer melalui berbagai alat. Camera 2 adalah API framework yang disertakan dalam Android sejak Android 5.0 Lollipop, dan CameraX adalah library dukungan Jetpack yang berjalan di atas Camera 2, dan tersedia untuk semua developer Android. Solusi ini dimaksudkan untuk saling melengkapi dalam memenuhi kebutuhan ekosistem Kamera Android.

Untuk developer yang mulai dengan Kamera Android, memperbarui aplikasi mereka ke versi terbaru, atau memigrasikan aplikasi mereka dari Camera 1, CameraX adalah alat terbaik untuk memulai! CameraX menawarkan manfaat penting untuk mendukung developer, dan mengatasi kompleksitas ekosistem.

  1. Kecepatan pengembangan adalah pendorong utama di balik desain CameraX. SDK ini tidak hanya memungkinkan developer untuk membangun dan berjalan lebih cepat, tetapi juga membangun praktik pengembangan terbaik dan pengetahuan fotografi untuk memaksimalkan kamera.
  2. Perangkat Android yang mendukungnya datang dalam jumlah besar dengan banyak variasi. CameraX bertujuan untuk menjadi konsisten di banyak perangkat Android dan memiliki kompleksitasnya sendiri, untuk menawarkan kepada developer sebuah SDK yang bekerja secara konsisten di 150+ model ponsel, dengan kompatibilitas ke belakang hingga Android 5.0 (API level 21). CameraX diuji setiap hari oleh Google pada masing-masing perangkat tersebut di lab kami, untuk memastikan kompleksitas tidak dihadapi developer, sekaligus menjaga kualitasnya tetap tinggi.
  3. Rilis library yang cepat adalah fleksibilitas yang didapat CameraX sebagai library dukungan Jetpack. Peluncuran CameraX bisa datang lebih sering dan rutin, atau secara ad hoc, untuk merespons masukan, dan memberikan kemampuan baru. Kami berencana untuk lebih memperluasnya di postingan blog lain.

Bagi developer yang membangun fungsionalitas sangat khusus dengan Kamera untuk kontrol tingkat rendah dari alur pengambilan gambar, dengan mempertimbangkan variasi perangkat, seharusnya menggunakan Camera 2.

Camera 2 adalah API umum yang memungkinkan hardware kamera di setiap perangkat Android dan digunakan di miliaran perangkat Android di seluruh dunia yang ada di pasaran saat ini. Sebagai API framework, Camera 2 memungkinkan developer memanfaatkan pengetahuan mendalam mereka tentang fotografi dan implementasi perangkat. Untuk memastikan kualitas Camera 2, produsen perangkat menunjukkan kepatuhan dengan menguji perangkat mereka. Variasi perangkat muncul di API berdasarkan pilihan produsen perangkat, sehingga fitur khusus bisa memanfaatkan variasi tersebut pada perangkat tertentu sesuai keinginan mereka.

Untuk lebih memahaminya, mari kita gunakan sebuah contoh. Kami akan membandingkan kemampuan pengambilan kamera. Camera 2 menawarkan kontrol khusus dari pipeline pengambilan gambar individual untuk masing-masing kamera di ponsel pada saat yang sama, selain setelan manual yang sangat mendetail. CameraX memungkinkan pengambilan gambar resolusi tinggi dan berkualitas tinggi, serta menyediakan fungsionalitas keseimbangan putih otomatis, eksposur otomatis, dan fokus otomatis, selain kontrol kamera manual yang mudah.

Pertimbangan contoh aplikasi: Samsung menggunakan Camera Framework API untuk membantu sistem kamera kelas profesional yang canggih untuk mengambil foto berkualitas studio dalam berbagai pencahayaan dan setelan pada perangkat Samsung Galaxy. Meskipun API ini bersifat umum, Samsung telah mengaktifkan variasi yang unik untuk setiap kemampuan perangkat, dan memanfaatkannya di aplikasi kamera pada setiap perangkat. Camera Framework API memungkinkan Samsung menjangkau kemampuan kamera tingkat rendah, dan menyesuaikan aplikasi native untuk perangkat

Contoh lain, Microsoft memutuskan untuk mengintegrasikan CameraX pada semua aplikasi produktivitas yang menggunakan Microsoft Lens (yaitu Office, Outlook, OneDrive), untuk memastikan penggunaan gambar berkualitas tinggi di semua aplikasi ini. Dengan beralih ke CameraX, tim Microsoft Lens tidak hanya dapat meningkatkan pengalaman developernya dengan melihat API yang lebih sederhana, tetapi juga meningkatkan performa, meningkatkan produktivitas developer, dan mempercepat waktu untuk memasuki pasar. Anda bisa mempelajarinya lebih lanjut di sini.


Ini adalah waktu yang sangat menarik untuk Kamera Android, dengan banyak fitur baru di kedua API:

  • CameraX telah meluncurkan beberapa fitur baru, yang paling penting adalah Video Capture yang tersedia untuk developer dalam versi beta pada tanggal 26 Januari.
  • Dengan peluncuran Android 12, Camera 2 memiliki sejumlah fitur yang sekarang sudah tersedia.

Seiring pengembangan, kami berencana membagikan lebih banyak detail kepada Anda tentang fitur menarik yang telah kami rencanakan untuk Kamera Android. Kami nantikan partisipasi dan masukan Anda, melalui milis CameraX: camerax-developers@android.com dan issue tracker AOSP.

Terima kasih atas minat Anda pada Kamera Android, dan kami berharap dapat membangun pengalaman kamera luar biasa bagi pengguna yang berkolaborasi dengan Anda!


Diposting oleh Max Bires, Software Engineer

Latar belakang Android biru

Pengesahan sebagai fitur telah dimandatkan sejak Android 8.0. Seiring rilis yang datang dan pergi, kepercayaan menjadi semakin penting untuk berbagai fitur dan layanan seperti SafetyNet, Kredensial Identitas, Kunci Mobil Digital, dan berbagai library pihak ketiga. Mengingat hal tersebut, inilah saatnya kami meninjau kembali infrastruktur pengesahan untuk memperketat keamanan rantai kepercayaan kami dan meningkatkan kepercayaan pemulihan perangkat jika ada kerentanan yang telah diketahui.


Diposting oleh Max Bires, Software Engineer

Latar belakang Android biru

Pengesahan sebagai fitur telah dimandatkan sejak Android 8.0. Seiring rilis yang datang dan pergi, kepercayaan menjadi semakin penting untuk berbagai fitur dan layanan seperti SafetyNet, Kredensial Identitas, Kunci Mobil Digital, dan berbagai library pihak ketiga. Mengingat hal tersebut, inilah saatnya kami meninjau kembali infrastruktur pengesahan untuk memperketat keamanan rantai kepercayaan kami dan meningkatkan kepercayaan pemulihan perangkat jika ada kerentanan yang telah diketahui.

Mulai Android 12.0, kami akan menyediakan opsi untuk mengganti penyediaan kunci pribadi dalam pabrik dengan kombinasi ekstraksi kunci publik dalam pabrik dan penyediaan sertifikat over the air (OTA) dengan sertifikat jangka pendek. Skema ini akan dimandatkan dalam Android 13.0. Kami menyebut skema baru ini Remote Key Provisioning.


Siapa yang Terpengaruh?

OEM/ODM

Produsen perangkat tidak akan lagi menyediakan kunci pribadi pengesahan secara langsung ke perangkat di pabrik, bebannya lebih ringan karena tidak perlu mengelola rahasia pengesahan di pabrik.

Pihak yang Mengandalkan, Potensial

Dijelaskan lebih lanjut di bawah ini, format, algoritme, dan panjang rantai sertifikat dalam pengesahan akan berubah. Jika pihak yang mengandalkannya telah menyiapkan kode validasi sertifikat agar sesuai dengan struktur rantai sertifikat lama, maka kode ini harus diupdate.


Mengapa Berubah?

Dua faktor motivasi utama yang mengubah cara kami menyediakan sertifikat pengesahan ke perangkat adalah agar perangkat bisa dipulihkan setelah dirusak dan memperketat supply chain pengesahan. Dalam skema pengesahan saat ini, jika sebuah model perangkat ternyata dirusak dengan cara yang memengaruhi sinyal kepercayaan pengesahan, atau jika kunci bocor melalui suatu mekanisme, maka kunci tersebut harus dicabut. Karena semakin banyak layanan yang mengandalkan sinyal kunci pengesahan, hal ini bisa berdampak besar pada konsumen yang perangkatnya terpengaruh.

Perubahan ini memungkinkan kami menghentikan penyediaan ke perangkat yang menggunakan software yang diketahui telah dirusak, dan menghapus potensi kebocoran kunci yang tidak disengaja. Hal ini akan sangat membantu mengurangi potensi gangguan layanan untuk pengguna.

Gambar Server Google

Bagaimana Cara Kerjanya?

Pasangan kunci statis unik dihasilkan oleh setiap perangkat, dan bagian publik dari pasangan kunci ini diekstraks oleh OEM di pabriknya. Kunci publik ini kemudian diupload ke server Google, di sana mereka berfungsi sebagai dasar kepercayaan untuk penyediaan nantinya. Kunci pribadi tidak pernah meninggalkan lingkungan aman yang menghasilkannya.

Bila telah dibuka dari kemasannya dan terhubung ke internet, perangkat akan menghasilkan permintaan penandatanganan sertifikat untuk kunci yang telah dihasilkannya, yang menandatanganinya dengan kunci pribadi sesuai dengan kunci publik yang dikumpulkan di pabrik. Server backend akan memverifikasi keaslian permintaan dan kemudian menandatangani kunci publik, dengan mengembalikan rantai sertifikat. Keystore akan menyimpan rantai sertifikat ini, menetapkannya ke aplikasi setiap kali pengesahan diminta.

Aliran ini akan terjadi secara teratur setelah berakhirnya sertifikat atau habisnya pasokan kunci saat ini. Skema ini menjaga privasi karena setiap aplikasi menerima kunci pengesahan yang berbeda, dan kunci diedarkan secara teratur. Selain itu, server backend Google tersegmentasi sedemikian rupa sehingga server yang memverifikasi kunci publik perangkat tidak akan melihat kunci pengesahan yang dilampirkan. Ini berarti Google tidak mungkin menghubungkan kembali kunci pengesahan ke perangkat tertentu yang memintanya.


Apa yang Berubah dari Sudut Pandang Teknis?

Pengguna akhir tidak akan melihat perubahan apa pun. Developer yang memanfaatkan pengesahan perlu memperhatikan perubahan berikut:

  • Struktur Rantai Sertifikat
    • Dengan sifat infrastruktur penyediaan online baru kami, panjang rantai menjadi lebih panjang dari sebelumnya, dan dapat berubah.
  • Root of Trust
    • Root of trust nantinya akan diupdate dari kunci RSA saat ini ke kunci ECDSA.
  • Dihilangkannya Pengesahan RSA
    • Semua kunci yang dihasilkan dan disahkan oleh KeyMint akan ditandatangani dengan kunci ECDSA dan rantai sertifikat yang sesuai. Sebelumnya, kunci asimetris ditandatangani oleh algoritme yang sesuai.
  • Sertifikat Jangka Pendek dan Kunci Pengesahan
    • Sertifikat yang disediakan untuk perangkat pada umumnya akan berlaku hingga dua bulan sebelum kedaluwarsa dan dirotasi.