Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan Runtime SDK

Platform Android menggunakan konsep sandbox aplikasi untuk mempertahankan batas keamanan dan eksekusi yang tangguh untuk kode aplikasi, mengikuti batasan proses. Sudah menjadi praktik umum bagi aplikasi untuk menyertakan kode pihak ketiga, sering kali dalam bentuk SDK seperti SDK iklan atau SDK analisis. Penggunaan ulang ini memungkinkan developer aplikasi berfokus pada diferensiasi aplikasi mereka sekaligus memanfaatkan karya para pakar di bidang khusus ini untuk meningkatkan skala eksekusi mereka di luar apa yang dapat mereka lakukan sendiri dengan mudah.

Seperti sebagian besar sistem operasi, SDK Android dieksekusi dalam sandbox aplikasi host dan mewarisi hak istimewa serta izin yang sama dengan aplikasi host, begitu juga akses ke memori dan penyimpanan aplikasi host. Meskipun memungkinkan SDK dan aplikasi untuk berintegrasi secara fleksibel, arsitektur ini juga menciptakan potensi untuk mengumpulkan dan berbagi data pengguna yang tidak diungkapkan. Selain itu, developer aplikasi mungkin tidak sepenuhnya menyadari batasan fungsi SDK pihak ketiga dan data yang diaksesnya sehingga sulit untuk memperhitungkan praktik berbagi dan mengumpulkan data di aplikasi mereka.

Di Android 13, kami telah menambahkan kemampuan platform baru yang memungkinkan SDK pihak ketiga berjalan di lingkungan runtime khusus yang disebut Runtime SDK. Runtime SDK memberikan jaminan dan pengamanan yang lebih kuat seputar pengumpulan dan pembagian data pengguna:

Lingkungan eksekusi yang dimodifikasi
Izin yang ditetapkan dengan baik dan hak akses data untuk SDK

Kami mencari masukan secara aktif dari komunitas periklanan aplikasi seluler tentang desain ini. Kami juga menerima masukan dari komunitas developer yang lebih luas untuk membantu membentuk iterasi Runtime SDK pada masa mendatang, termasuk dukungan untuk kasus penggunaan tambahan.

Tujuan

Proposal ini berupaya mencapai tujuan berikut:

Mengurangi akses dan pembagian data aplikasi pengguna yang tidak diungkapkan oleh SDK pihak ketiga melalui isolasi proses serta API dan kontrol akses data yang ditetapkan dengan baik. Pelajari isolasi proses lebih lanjut di bagian terpisah dalam dokumen ini.
Mengurangi pelacakan penggunaan aplikasi pengguna yang tidak diungkapkan oleh SDK pihak ketiga dengan membatasi ID unik dan persisten agar tidak diakses oleh SDK.
Mempercepat distribusi update SDK ke aplikasi secara aman dengan mengurangi beban pada developer aplikasi dan pengguna akhir. Pelajari lebih lanjut model distribusi SDK tepercaya yang diusulkan di bagian lain dalam dokumen ini.
Membantu developer aplikasi memperhitungkan akses data dan praktik berbagi aplikasi mereka dengan lebih baik.
Membantu developer SDK mencegah gangguan oleh SDK lain melalui pembatasan konstruksi bahasa tertentu yang tidak aman, seperti kode JNI.
Membantu SDK iklan mendeteksi dan mencegah traffic tidak valid dan penipuan iklan melalui kontrol penuh atas tampilan jarak jauh yang menampilkan media.
Meminimalkan sebanyak mungkin dampak yang tidak semestinya kepada developer aplikasi dan SDK.

SDK dieksekusi dalam proses terpisah

Runtime SDK yang diusulkan memungkinkan SDK yang kompatibel—disebut di seluruh bagian lain dokumen ini sebagai SDK dengan dukungan runtime (RE)—untuk beroperasi dalam proses terpisah bagi aplikasi. Platform ini memfasilitasi komunikasi dua arah antara proses aplikasi dan Runtime SDK. Lihat bagian komunikasi dalam dokumen ini untuk mengetahui detailnya. SDK non-RE akan tetap berada dalam proses aplikasi seperti saat ini. Diagram berikut mengilustrasikan perubahan ini:

Diagram sebelum menampilkan semua yang menjalankan proses Aplikasi — Sebelum ditambahkan ke Runtime SDK kode panggilan SDK, beserta SDK yang menerima panggilan dari kode ini, semuanya berada dalam proses aplikasi

Diagram setelah yang menunjukkan pemisahan proses antara proses aplikasi dan proses runtime SDK — Setelah ditambahkan ke Runtime SDK kode panggilan SDK, dalam proses latar depan aplikasi, kode panggilan SDK berkomunikasi dengan antarmuka SDK. Antarmuka ini kemudian melewati batasan proses ke proses Runtime SDK untuk memanggil SDK itu sendiri.

Model distribusi tepercaya baru untuk SDK

Pemisahan SDK yang diusulkan dari aplikasi ini memotivasi konsep pemisahan lain, pemisahan untuk distribusi aplikasi dan SDK. Proposal kami memerlukan mekanisme distribusi dan penginstalan tepercaya, untuk memastikan SDK yang benar diinstal di Runtime SDK aplikasi. Ini membantu melindungi pengguna dan developer aplikasi dari pemuatan SDK yang tidak valid, sekaligus memungkinkan app store mengurangi beban distribusi SDK dari developer aplikasi secara signifikan.

SDK tidak perlu lagi ditautkan dan dikemas secara statis bersama aplikasinya sebelum diupload ke app store untuk didistribusikan. Sebagai gantinya, proses berikut akan terjadi:

Developer SDK dapat mengupload SDK berversi mereka ke app store, terpisah dari aplikasi itu sendiri.
Developer aplikasi dapat menentukan dependensi SDK-nya berdasarkan versi, build, dan mengupload rilis aplikasi yang tidak menyertakan dependensi SDK yang sebenarnya.
Ketika pengguna mendownload aplikasi tersebut, proses penginstalan dapat menggunakan dependensi SDK yang ditentukan aplikasi, lalu mendownloadnya dari app store.

Mekanisme distribusi baru ini akan memungkinkan developer SDK membuat perubahan yang tidak menyebabkan gangguan (yaitu, tidak ada perubahan pada API atau semantik) pada SDK mereka dan mendistribusikan ke perangkat tanpa sedikit pun melibatkan developer aplikasi. Perubahan SDK yang tidak menyebabkan gangguan ini dapat di-deploy atau di-roll back, tanpa perlu menunggu developer aplikasi membangun ulang aplikasi mereka dengan SDK baru, atau menunggu pengguna akhir mengupdate aplikasi mereka. Perubahan yang dapat menyebabkan gangguan masih harus diperbarui oleh developer aplikasi, tetapi developer SDK bisa mendapatkan perubahan terbaru yang tidak menyebabkan gangguan dan memperbaikinya dengan lebih cepat dan lebih seragam untuk lebih banyak orang, idealnya dengan meminimalkan dukungan versi.

Diagram berikut mengilustrasikan perubahan yang diusulkan dalam distribusi SDK:

Diagram sebelum — Sebelum pengenalan Runtime SDK, developer mengirim SDK mereka langsung ke aplikasi.

Diagram setelah — Setelah diperkenalkannya Runtime SDK, d, developer SDK akan menggunakan UI upload SDK untuk memublikasikan SDK mereka ke app store. Selanjutnya, app store akan menangani distribusi aplikasi, bersama dengan dependensi SDK apa pun, ke perangkat pengguna akhir.

Perubahan pada cara SDK dan aplikasi di-build, dijalankan, dan didistribusikan

Ini adalah proposal awal untuk Runtime SDK dan teknologi distribusi yang fleksibel. Bagian berikut mengusulkan serangkaian perubahan di seluruh kategori yang luas:

Akses: Izin, memori, penyimpanan
Eksekusi: Bahasa, perubahan runtime, siklus proses, rendering media
Komunikasi: Aplikasi ke SDK dan SDK ke SDK
Pengembangan: Cara mem-build, men-debug, menguji dalam model ini
Distribusi: Cara mendistribusikan, mengupdate, melakukan roll back untuk seluruh versi Android, aplikasi, dan SDK

Dokumen ini juga menyertakan FAQ untuk membantu menjawab pertanyaan umum.

Ini adalah proposal desain awal, dan kami memahami bahwa ini dapat menjadi perubahan yang berarti bagi beberapa anggota ekosistem. Inilah alasan kami secara aktif meminta masukan Anda dan meminta Anda untuk melakukannya melalui issue tracker ini.

Akses

Mengelola privasi sistem berarti mengelola cara berbagai pihak dapat mengakses resource yang berbeda. Untuk memenuhi proposisi nilai privasi kami, kami mengusulkan pembaruan model untuk mengakses aplikasi, SDK, dan data pengguna agar mengikuti prinsip hak istimewa terendah untuk mencegah akses yang tidak diungkapkan ke data yang mungkin sensitif.

Izin SDK

Sebagai proses terpisah, Runtime SDK akan memiliki sekumpulan izin yang ditetapkan dengan baik, bukan mewarisi izin yang diberikan pengguna kepada aplikasi. Berdasarkan riset awal tentang izin yang digunakan oleh SDK terkait iklan, kami mengusulkan bahwa izin berikut akan dapat diakses oleh SDK di Runtime SDK secara default:

INTERNET: Akses ke internet agar dapat berkomunikasi dengan layanan web.
ACCESS_NETWORK_STATE: Mengakses informasi tentang jaringan.
Izin untuk mengakses API perlindungan privasi, yang memberikan kemampuan iklan inti tanpa memerlukan akses ke ID lintas aplikasi.
AD_ID: Kemampuan untuk meminta ID iklan. Hal ini juga akan dibatasi oleh akses aplikasi ke izin tersebut.
BIND_GET_INSTALL_REFERRER_SERVICE: Kemampuan untuk menggunakan Google Play Install Referrer API untuk mengatribusikan sumber penginstalan aplikasi.

Saat ini kami sedang menyelidiki apakah izin tambahan dapat diberikan dan bagaimana cara memberikan otorisasinya, sehingga membatasi dampak pada pengguna akhir dari sudut pandang kegunaan maupun privasi. Kami meminta masukan tentang kasus penggunaan apa pun yang mungkin tidak dipenuhi oleh kumpulan izin ini.

Memori

Runtime SDK akan memiliki ruang memori sendiri yang terpisah karena telah memiliki prosesnya sendiri. Struktur ini secara default akan menolak akses SDK ke ruang memori aplikasi, dan aplikasi juga tidak akan dapat mengakses ruang memori SDK. Kami mengusulkan agar perilaku default ini tetap selaras dengan prinsip hak istimewa terendah.

Penyimpanan

Proposal ini bermaksud menyeimbangkan perlunya SDK mengakses penyimpanan untuk operasi normalnya sekaligus meminimalkan pelacakan lintas aplikasi dan lintas proses menggunakan penyimpanan persisten. Kami mengusulkan pembaruan berikut terkait cara penyimpanan diakses saat ini:

Aplikasi tidak akan dapat langsung mengakses penyimpanan SDK-nya, begitu pula sebaliknya.
Penyimpanan eksternal perangkat tidak akan dapat diakses oleh SDK.
Dalam setiap Runtime SDK, akan ada penyimpanan yang dapat diakses oleh semua SDK dan penyimpanan yang bersifat pribadi untuk SDK tertentu.

Seperti model penyimpanan saat ini, penyimpanan itu sendiri tidak akan memiliki batas arbitrer untuk ukuran. SDK dapat menggunakan penyimpanan untuk menyimpan aset dalam cache. Penyimpanan ini akan dihapus secara berkala saat SDK tidak aktif berjalan.

Eksekusi

Untuk memastikan sistem pribadi antara aplikasi, SDK, dan pengguna, konteks eksekusi itu sendiri (format kode, konstruksi bahasa, API yang dapat diakses, dan data sistem) perlu memperkuat batas-batas privasi tersebut, atau setidaknya tidak menciptakan peluang untuk mengelakkannya. Pada saat yang sama, kami ingin mempertahankan akses ke platform yang kaya dan sebagian besar kemampuan runtime yang dimiliki SDK saat ini. Di sini, kami mengusulkan serangkaian update pada lingkungan runtime untuk mencapai keseimbangan ini.

Kode

Kode Android (aplikasi dan SDK) sebagian besar ditafsirkan oleh Android Runtime (ART), baik kode tersebut ditulis dalam Kotlin atau Java. Kekayaan ART dan konstruksi bahasa yang ditawarkannya, ditambah dengan verifikasi yang ditawarkannya jika dibandingkan dengan alternatif—dalam kode native tertentu—tampak menyeimbangkan fungsi dan privasi dengan tepat. Kami mengusulkan bahwa kode SDK yang mendukung runtime hanya terdiri dari bytecode Dex, dan tidak mendukung akses JNI.

Kami menyadari bahwa ada kasus penggunaan, seperti penggunaan SQLite paket kustom, yang harus diganti dengan alternatif seperti SQLite versi bawaan SDK Android karena adanya penggunaan kode native.

SELinux

Di Android, setiap proses (termasuk yang berjalan sebagai root) dijalankan dengan konteks SELinux tertentu, yang memungkinkan kernel mengelola kontrol akses ke layanan sistem, file, perangkat, dan proses lainnya. Dalam upaya untuk mempertahankan sebagian besar kasus penggunaan SDK sekaligus meminimalkan pengelakan perlindungan privasi yang kami coba lanjutkan, kami mengusulkan pembaruan berikut dari konteks SELinux aplikasi non-sistem untuk Runtime SDK:

Serangkaian layanan sistem yang terbatas akan dapat diakses. (dalam desain aktif)
SDK hanya dapat memuat dan mengeksekusi kode dalam APK-nya.
Serangkaian properti sistem yang terbatas akan dapat diakses. (dalam desain aktif)

API

Penggunaan API refleksi dan pemanggilan dalam runtime SDK diizinkan. Namun, SDK tidak akan diizinkan untuk menggunakan API refleksi atau pemanggilan di SDK lain dengan dukungan runtime. Kami akan membagikan proposal lengkap tentang API yang dilarang dalam update mendatang.

Selain itu, rilis platform Android terbaru semakin membatasi akses ke ID persisten untuk meningkatkan privasi. Untuk Runtime SDK, kami mengusulkan pembatasan akses lebih lanjut ke ID yang dapat digunakan untuk pelacakan lintas aplikasi.

API Runtime SDK hanya dapat diakses dari aplikasi yang berjalan di latar depan. Mencoba mengakses SdkSandboxManager API dari aplikasi di latar belakang akan mengakibatkan SecurityException ditampilkan.

Terakhir, RE-SDK tidak dapat menggunakan API notifikasi untuk mengirimkan notifikasi kepada pengguna kapan pun.

Siklus Proses

SDK Aplikasi saat ini mengikuti siklus proses aplikasi host mereka, artinya ketika aplikasi masuk atau keluar dari latar depan, dimatikan, atau dipaksa berhenti oleh sistem operasi karena tekanan memori, SDK aplikasi juga mengalami hal yang sama. Proposal kami untuk memisahkan SDK aplikasi ke dalam proses lain menyiratkan perubahan siklus proses berikut:

Aplikasi dapat dihentikan oleh pengguna atau sistem operasi. Runtime SDK akan segera dihentikan secara otomatis setelahnya.
Runtime SDK dapat dihentikan oleh sistem operasi karena beberapa hal, seperti tekanan memori, atau pengecualian yang tidak tertangani.

Untuk Android 13, saat aplikasi berada di latar depan, Runtime SDK akan berjalan dengan prioritas tinggi dan tidak akan dihentikan. Saat aplikasi beralih ke latar belakang, prioritas proses Runtime SDK akan menurun dan memenuhi syarat untuk penghentian. Prioritas proses Runtime SDK tetap rendah meskipun aplikasi kembali ke latar depan. Karenanya, proses itu sangat mungkin dihentikan karena tekanan memori dibandingkan dengan aplikasi.

Untuk Android 14 dan yang lebih baru, prioritas proses aplikasi dan Runtime SDK akan disesuaikan. Prioritas proses untuk ActivityManager.RunningAppProcessInfo.importance bagi aplikasi dan Runtime SDK seharusnya kurang lebih sama.

Jika Runtime SDK berakhir saat aplikasi aktif—misalnya jika ada pengecualian yang tidak tertangani di SDK—status Runtime SDK, termasuk semua SDK yang dimuat sebelumnya dan tampilan jarak jauh, akan hilang. Developer aplikasi dapat menangani penghentian Runtime SDK menggunakan salah satu metode berikut:
- Proposal ini menawarkan metode callback siklus proses terkait kepada developer aplikasi untuk mendeteksi kapan penghentian Runtime SDK telah terjadi.
- Jika Runtime SDK berakhir saat iklan ditampilkan, iklan mungkin tidak berfungsi sesuai yang diharapkan. Misalnya, tampilan mungkin dibekukan di layar dan tidak interaktif lagi. Aplikasi dapat menghapus penayangan iklan jika tidak memengaruhi pengalaman pengguna.
- Aplikasi dapat mencoba lagi untuk memuat SDK dan meminta iklan.
- Untuk Android 14, jika Runtime SDK dihentikan saat SDK dimuat, dan jika developer aplikasi belum mendaftarkan metode callback siklus proses yang disebutkan di atas, aplikasi akan dihentikan secara default. Hanya proses aplikasi yang telah memuat SDK yang akan berakhir dan keluar secara normal.
- Objek Binder yang ditampilkan oleh SDK untuk berkomunikasi dengannya (seperti SandboxedSdk) akan menampilkan DeadObjectException jika digunakan oleh aplikasi.
Model siklus proses ini dapat berubah dalam update mendatang.

Dalam kasus kegagalan persisten, developer aplikasi harus merencanakan degradasi halus tanpa SDK atau memberi tahu pengguna jika SDK sangat penting untuk fungsi inti aplikasi. Untuk mengetahui detail lebih lanjut mengenai interaksi aplikasi ke SDK ini, baca bagian komunikasi dalam dokumen ini.

SDK non-RE dapat terus menggunakan primitif OS standar yang tersedia untuk aplikasi tersematnya—termasuk layanan, aktivitas, dan siaran—sedangkan SDK RE tidak dapat melakukannya.

Kasus tertentu

Kasus berikut tidak didukung, dan dapat menghasilkan perilaku yang tidak diharapkan:

Jika beberapa aplikasi memiliki UID yang sama, Runtime SDK mungkin tidak berfungsi dengan benar. Dukungan untuk UID bersama dapat ditambahkan di masa mendatang.
Untuk aplikasi dengan beberapa proses, pemuatan SDK harus dilakukan dalam proses utama.

Rendering media

Ada SDK yang merender konten seperti teks, gambar, dan video dalam tampilan yang ditentukan aplikasi. Untuk melakukannya, kami mengusulkan pendekatan rendering jarak jauh, dengan SDK yang merender media dari dalam Runtime SDK, tetapi menggunakan SurfaceControlViewHost API untuk memungkinkan media dirender dalam tampilan yang ditentukan aplikasi. Hal ini memberikan SDK kemampuan untuk merender media tersebut dengan cara yang bersifat pribadi bagi pengguna, sekaligus membantu mencegah dan mendeteksi interaksi pengguna yang tidak valid atau menipu dengan media yang dirender.

Iklan native, iklan yang tidak dirender oleh SDK tetapi oleh aplikasi, akan didukung oleh SDK di Runtime SDK. Proses pengumpulan sinyal dan pengambilan materi iklan akan terjadi secara konsisten dengan iklan non-native. Kami sedang mempelajari area ini secara aktif.

Iklan video in-stream adalah iklan yang berjalan in-stream dengan video, yang ditampilkan di pemutar dalam aplikasi. Mengingat video diputar dalam pemutar di aplikasi, bukan pemutar atau penayangan di SDK, model renderingnya berbeda dengan format iklan lainnya. Kami mempelajari secara aktif mekanisme untuk mendukung penyisipan iklan sisi server maupun penyisipan iklan berbasis SDK.

Kesehatan sistem

Kami ingin meminimalkan dampak kesehatan sistem yang dibawa Runtime SDK terhadap perangkat pengguna akhir, dan kami sedang mendesain cara untuk melakukannya. Kemungkinan besar, beberapa perangkat Android 13 entry-level dengan resource sistem yang sangat terbatas, seperti Android (edisi Go), tidak akan mendukung Runtime SDK karena dampak kesehatan sistem tersebut. Kami akan segera memberitahukan persyaratan minimum yang diperlukan agar berhasil menggunakan Runtime SDK.

Komunikasi

Karena aplikasi dan SDK saat ini berjalan dalam proses yang sama, komunikasi antar-aplikasi tidak terhalang dan tidak dimediasi. Selain itu, Android memungkinkan komunikasi antar-aplikasi meskipun komunikasi dimulai dan diakhiri dengan SDK. Model komunikasi yang mengalir bebas ini memungkinkan berbagai kasus penggunaan, sekaligus memperkenalkan kemungkinan pembagian data yang tidak diungkapkan antar-aplikasi dan antar-SDK dalam dan di antara aplikasi. Kami mengusulkan pembaruan berikut untuk model komunikasi itu, yang berupaya menemukan keseimbangan antara nilai komunikasi tersebut dan realisasi tujuan yang kami nyatakan.

Aplikasi ke SDK

Antarmuka antara aplikasi dan SDK adalah jalur komunikasi paling umum ke SDK, dan API SDK adalah tempat banyak diferensiasi dan inovasi dilihat oleh pengguna. Kami berusaha mempertahankan kemampuan SDK untuk berinovasi dan melakukan diferensiasi di sini. Oleh karena itu, proposal kami mendukung SDK untuk mengekspos API ke aplikasi, dan memastikan aplikasi dapat memanfaatkan semua inovasi tersebut.

Mengingat struktur batasan proses Runtime SDK, kami mengusulkan untuk mem-build lapisan marshaling yang dapat diakses dalam aplikasi, untuk membawa panggilan dan respons atau callback API melintasi batasan ini antara aplikasi dan SDK. Kami mengusulkan agar antarmuka ke lapisan marshaling ini ditentukan oleh developer SDK, dan dihasilkan oleh alat build open source resmi yang akan kami kembangkan.

Dengan proposal ini, kami berusaha menghapus tugas marshaling boilerplate dari developer aplikasi dan SDK, sekaligus memberikan fleksibilitas bagi developer SDK dan memastikan bahwa kode SDK berjalan di Runtime SDK untuk mewujudkan tujuan privasi kami. Jika kami mengambil jalur ini, alat dan bahasa definisi API harus didesain dengan input Anda.

Model interaksi umumnya adalah sebagai berikut:

Aplikasi memanggil SDK melalui antarmuka, yang meneruskan callback.
SDK secara asinkron memenuhi permintaan itu dan merespons menggunakan callback.
Hal ini dapat digeneralisasi ke model penayang-pelanggan apa pun, yang berarti aplikasi dapat berlangganan peristiwa di SDK dengan callback, dan ketika peristiwa ini terjadi, callback akan dipicu.

Konsekuensi dari struktur lintas proses baru dalam proposal ini adalah bahwa ada dua siklus proses yang perlu dikelola: satu untuk aplikasi itu sendiri dan satu lagi untuk Runtime SDK. Proposal kami berupaya untuk mengotomatiskan sebanyak mungkin, sehingga meminimalkan dampak bagi developer SDK dan aplikasi. Diagram berikut menunjukkan pendekatan yang sedang kami pertimbangkan:

Diagram urutan yang menunjukkan interaksi aplikasi ke SDK selama startup aplikasi dan SDK.

Platform ini akan mengekspos API baru untuk aplikasi agar dapat memuat SDK secara dinamis ke dalam proses Runtime SDK, mendapatkan notifikasi tentang perubahan status proses, dan berinteraksi dengan SDK yang dimuat ke dalam Runtime SDK.

Grafik pada gambar sebelumnya menunjukkan komunikasi aplikasi ke SDK pada level yang lebih rendah, tanpa lapisan marshaling.

Aplikasi berkomunikasi dengan SDK yang berjalan dalam proses Runtime SDK melalui langkah-langkah berikut:

Sebelum aplikasi dapat berinteraksi dengan SDK, aplikasi akan meminta agar platform memuat SDK. Untuk memastikan integritas sistem, aplikasi akan menentukan SDK yang ingin dimuat dalam file manifesnya, dan SDK ini akan menjadi satu-satunya yang diizinkan untuk dimuat.

Cuplikan kode berikut memberikan contoh API ilustrasi:
```
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
```
SDK akan mendapatkan notifikasi bahwa SDK telah dimuat dan menampilkan antarmukanya. Antarmuka ini dimaksudkan untuk digunakan oleh proses aplikasi. Untuk membagikan antarmuka di luar batas proses, antarmuka harus ditampilkan sebagai objek IBinder.

Panduan layanan terikat menyediakan berbagai cara untuk menyediakan IBinder. Apa pun pilihannya, SDK dan aplikasi pemanggil harus konsisten. Diagram menggunakan AIDL sebagai contoh.
SdkSandboxManager menerima antarmuka IBinder dan menampilkannya ke aplikasi.

Aplikasi akan mendapatkan IBinder dan mentransmisikannya ke antarmuka SDK, yang memanggil fungsinya:

IBinder binder = sandboxSdk.getInterface();
ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
mySdkInterface.something();

Aplikasi juga dapat merender media dari SDK dengan mengikuti langkah-langkah berikut:

Seperti yang dijelaskan di bagian rendering media pada dokumen ini, agar aplikasi mendapatkan SDK untuk merender media dalam tampilan, aplikasi dapat melakukan panggilan ke requestSurfacePackage() dan mengambil SurfaceControlViewHost.SurfacePackage yang sesuai.

Cuplikan kode berikut memberikan contoh API ilustrasi:
```
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
```
Selanjutnya, aplikasi dapat menyematkan SurfacePackage yang ditampilkan ke SurfaceView melalui setChildSurfacePackage API di SurfaceView.

Cuplikan kode berikut memberikan contoh API ilustrasi:
```
SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
```

Proposal kami adalah ingin membuat API IBinder dan requestSurfacePackage() bersifat generik dan tidak dimaksudkan untuk dipanggil langsung oleh aplikasi. Sebaliknya, API itu akan dipanggil oleh referensi API yang dihasilkan dan telah dibahas di atas, dalam lapisan “shim”, untuk mengurangi beban developer aplikasi.

SDK ke SDK

Dua SDK dalam aplikasi yang sama sering kali perlu berkomunikasi. Hal ini dapat terjadi ketika SDK tertentu dirancang untuk tersusun dari SDK konstituen, dan dapat terjadi jika dua SDK dari pihak yang berbeda perlu berkolaborasi untuk memenuhi permintaan dari aplikasi panggilan.

Ada dua kasus utama yang perlu dipertimbangkan:

Saat kedua SDK mendukung runtime. Dalam hal ini, kedua SDK berjalan di Runtime SDK dengan semua perlindungannya. SDK tidak dapat berkomunikasi seperti yang dilakukan dalam aplikasi saat ini. Dengan demikian, satu API di SdkSandboxController telah ditambahkan untuk mengaktifkan pengambilan objek SandboxedSdk untuk semua RE-SDK yang dimuat. Hal ini memungkinkan RE-SDK berkomunikasi dengan SDK lain yang dimuat di Runtime SDK.
Jika hanya satu SDK yang mendukung runtime.
- Jika SDK panggilan berjalan di aplikasi, cara kerjanya tidak berbeda dengan aplikasi yang memanggil SDK kedua dalam Runtime SDK.
- Jika SDK panggilan berjalan dalam Runtime SDK, proposal ini merekomendasikan pengajuan metode menggunakan IBinder yang dijelaskan di bagian aplikasi ke SDK yang diterima, diproses, dan direspons oleh kode di dalam aplikasi dengan callback yang disediakan.
- SDK iklan yang tidak mendukung runtime mungkin tidak dapat mendaftarkan diri sendiri. Kami mengusulkan pembuatan SDK mediator yang menyertakan SDK aplikasi atau partner apa pun sebagai dependensi langsung aplikasi dan menangani pendaftaran. SDK mediator ini menetapkan komunikasi antara SDK yang tidak mendukung runtime atau dependensi aplikasi lainnya dan mediator yang mendukung runtime yang bertindak sebagai adaptor.

Set fitur untuk komunikasi SDK-SDK telah dibagi menjadi kategori berikut:

Komunikasi SDK-SDK dalam Runtime SDK (tersedia di Pratinjau Developer terbaru)
Komunikasi SDK-SDK antara aplikasi dan Runtime SDK (tersedia di Pratinjau Developer terbaru)
Cara kerja tampilan dan rendering jarak jauh untuk mediasi (proposal dalam pengembangan)

Kasus penggunaan berikut sedang dipertimbangkan ketika primitif sedang dirancang:

Mediasi dan Bidding. Banyak SDK iklan menawarkan kemampuan mediasi atau bidding, dengan SDK tersebut memanggil berbagai SDK lain untuk menghasilkan tayangan iklan (mediasi), atau untuk mengumpulkan sinyal guna menjalankan lelang (bidding). Biasanya, SDK koordinasi memanggil SDK lain melalui adaptor yang dilengkapi oleh SDK koordinasi. Dengan primitif di atas, SDK yang berkoordinasi, RE atau bukan, harus dapat mengakses semua SDK RE maupun non-RE untuk beroperasi secara normal. Rendering dalam konteks ini masih dipelajari secara aktif.
Penemuan fitur. Beberapa produk SDK terdiri dari SDK yang lebih kecil, yang melalui proses penemuan antar-SDK, menentukan kumpulan fitur utama yang diekspos ke developer aplikasi. Primitif pendaftaran dan penemuan diperkirakan akan mengaktifkan kasus penggunaan ini.
Model langganan penayang. Beberapa SDK dirancang untuk memiliki penayang peristiwa pusat yang dapat diikuti oleh SDK atau aplikasi lain untuk mendapatkan notifikasi melalui callback. Primitif di atas harus mendukung kasus penggunaan ini.

Aplikasi ke aplikasi

Komunikasi aplikasi ke aplikasi adalah ketika setidaknya satu dari dua proses yang berkomunikasi adalah SDK yang mendukung runtime dan merupakan vektor potensial untuk berbagi data yang tidak diungkapkan. Akibatnya, Runtime SDK tidak dapat membuat saluran komunikasi langsung dengan aplikasi apa pun selain aplikasi klien, atau dengan SDK dalam runtime SDK lain yang dibuat untuk aplikasi lain. Hal ini dicapai dengan cara berikut:

SDK tidak dapat menentukan komponen seperti <service>, <contentprovider>, atau <activity> dalam manifesnya.
SDK tidak dapat memublikasikan ContentProvider atau mengirim siaran.
SDK dapat meluncurkan aktivitas milik aplikasi lain, tetapi dengan batasan tentang apa yang dapat dikirim dalam Intent. Misalnya, tidak ada tambahan atau tindakan kustom yang dapat ditambahkan ke Intent ini.
SDK hanya dapat memulai atau mengikat ke daftar layanan yang diizinkan.
SDK ini hanya dapat mengakses subset dari ContentProvider sistem (seperti com.android.providers.settings.SettingsProvider), saat data yang diperoleh tidak memiliki ID dan tidak dapat digunakan untuk membuat sidik jari pengguna. Pemeriksaan ini juga berlaku untuk mengakses ContentProvider menggunakan ContentResolver.
SDK hanya dapat mengakses subset penerima siaran yang dilindungi (seperti android.intent.action.AIRPLANE_MODE).

Tag manifes

Saat SDK diinstal, PackageManager akan mengurai manifes SDK dan gagal menginstal SDK jika ada tag manifes yang diblokir. Misalnya, SDK mungkin tidak menentukan komponen seperti <service>, <activity>, <provider> atau <receiver>, dan mungkin tidak mendeklarasikan <permission> dalam manifes. Tag yang menggagalkan penginstalan tidak didukung di Runtime SDK. Tag yang tidak menggagalkan penginstalan tetapi diabaikan secara diam-diam mungkin akan didukung di versi Android mendatang.

Pemeriksaan ini mungkin juga diterapkan oleh alat waktu build apa pun yang digunakan SDK untuk membuat SDK bundle, dan pada saat mengupload ke app store.

Dukungan aktivitas

SDK di lingkungan Runtime SDK tidak dapat menambahkan tag aktivitas ke file manifesnya dan tidak dapat memulai aktivitasnya sendiri menggunakan Context.startActivity. Sebagai gantinya, platform akan membuat aktivitas untuk SDK saat diminta dan membagikannya dengan SDK.

Aktivitas platform adalah dari jenis android.app.Activity. Aktivitas platform dimulai dari salah satu aktivitas aplikasi dan merupakan bagian dari tugas aplikasi. FLAG_ACTIVITY_NEW_TASK tidak didukung.

Agar dapat memulai aktivitas, SDK harus mendaftarkan instance jenis SdkSandboxActivityHandler yang digunakan untuk memberi tahu tentang pembuatan aktivitas saat aplikasi memanggil SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) untuk memulai aktivitas.

Alur permintaan aktivitas ditampilkan dalam grafik berikut.

Pengembangan

Prinsip utama dalam proposal ini adalah meminimalkan dampak terhadap ekosistem developer sebanyak mungkin. Proposal ini menawarkan rangkaian alat pengembangan yang komprehensif kepada developer untuk menulis, membangun, men-debug aplikasi dan SDK RE. Untuk memastikan integritas proposal ini, ada beberapa perubahan pada cara aplikasi dan SDK RE dikonfigurasi, ditulis, dan dibangun.

Pembuatan

Android Studio dan alat terkait akan diupdate agar menggunakan Runtime SDK, membantu memastikan bahwa developer telah mengonfigurasi dengan benar aplikasi dan SDK RE mereka, serta memastikan bahwa panggilan yang lalu atau yang tidak didukung telah diperbarui ke alternatif yang lebih baru jika relevan. Selama fase pembuatan, ada beberapa langkah yang harus dilakukan developer berdasarkan proposal kami.

Developer aplikasi

Aplikasi harus menentukan dependensi sertifikat SDK dan SDK RE dalam manifes aplikasinya. Dalam proposal kami, kami memperlakukan ini sebagai sumber kebenaran dari developer aplikasi di seluruh proposal ini. Contoh:

Nama: Nama paket SDK atau library.
Versi utama: Kode versi utama SDK.
Ringkasan sertifikat: Ringkasan sertifikat build SDK. Untuk build tertentu, kami mengusulkan agar developer SDK mendapatkan dan mendaftarkan nilai tersebut melalui app store yang relevan.

Hal ini hanya berlaku untuk SDK yang didistribusikan app store, baik RE maupun tidak. Aplikasi yang secara statis menautkan SDK akan menggunakan mekanisme dependensi saat ini.

Mengingat tujuan kami untuk meminimalkan dampak pada developer, seharusnya developer aplikasi hanya perlu memiliki satu build setelah level API target yang mendukung Runtime SDK ditentukan. Build tersebut bisa berupa build yang berjalan di perangkat yang mendukung atau tidak mendukung Runtime SDK.

Developer SDK

Dalam desain yang diusulkan, developer SDK RE perlu secara eksplisit mendeklarasikan elemen baru yang mewakili entity SDK atau library dalam manifes. Selain itu, kumpulan nilai yang serupa dengan dependensi harus disediakan bersama versi minornya:

Nama: Nama paket SDK atau library.
Versi utama: Kode versi utama SDK.
Versi minor: Kode versi minor SDK.

Jika developer SDK RE memiliki SDK RE lain sebagai dependensi waktu build, mereka mungkin harus mendeklarasikannya dengan cara yang sama seperti cara developer aplikasi mendeklarasikan dependensi yang sama. SDK RE bergantung pada SDK non-RE yang akan menautkannya secara statis. Hal ini dapat menimbulkan masalah yang akan terdeteksi pada waktu build atau selama pengujian berjalan jika SDK non-RE memerlukan fungsi yang tidak didukung oleh Runtime SDK, atau jika SDK non-RE harus dijalankan dalam proses aplikasi.

Developer SDK RE kemungkinan besar ingin melanjutkan dukungan untuk perangkat yang tidak mendukung RE, seperti Android 12 atau yang lebih rendah, dan seperti yang disebutkan dalam bagian Kesehatan Sistem pada dokumen ini, perangkat Android 13 level entri dengan resource sistem yang sangat terbatas. Kami sedang melakukan pendekatan untuk memastikan developer SDK dapat mempertahankan satu code base untuk mendukung lingkungan RE dan non-RE.

Build

Developer aplikasi

Kami memperkirakan developer aplikasi akan mengalami sedikit perubahan pada langkah build. Dependensi SDK, baik yang didistribusikan secara lokal atau didistribusikan oleh app store (RE atau tidak), harus ada di mesin untuk analisis lint, kompilasi, dan build. Kami mengusulkan agar Android Studio memisahkan detail ini dari developer aplikasi dengan penggunaan normal dan membuatnya setransparan mungkin.

Meskipun kami memperkirakan bahwa build DEBUG perlu menyertakan semua kode dan simbol yang ada di build DEBUG untuk kemampuan di-debug, build RILIS akan menghapus semua SDK yang didistribusikan app store (RE atau tidak) dari artefak akhir.

Kami berada di tahap awal desain saat ini dan akan memberikan lebih banyak informasi setelah terwujud.

Developer SDK

Kami sedang mengupayakan jalur untuk memastikan bahwa SDK versi non-RE dan RE dapat dibangun menjadi satu artefak untuk distribusi. Dengan demikian, developer aplikasi tidak perlu mendukung build terpisah untuk SDK versi RE dan non-RE.

Sama seperti aplikasi, setiap SDK dependensi yang didistribusikan app store harus ada di mesin untuk analisis lint, kompilasi, dan build, dan kami berharap Android Studio dapat memfasilitasi proses ini dengan lancar.

Pengujian

Developer aplikasi

Seperti dijelaskan dalam proposal kami, developer aplikasi dapat menguji aplikasi mereka di perangkat yang menjalankan Android 13 seperti biasanya. Setelah mereka mem-build aplikasi, aplikasi dapat diinstal di emulator atau perangkat RE. Proses penginstalan ini akan memastikan SDK yang benar diinstal ke Runtime SDK untuk perangkat atau emulator, baik SDK tersebut ditarik dari repositori SDK jarak jauh atau cache dari sistem build.

Developer SDK

Developer SDK umumnya menggunakan aplikasi pengujian internal di perangkat dan emulator untuk menguji pengembangannya. Proposal kami tidak mengubah ini, dan validasi dalam aplikasi akan mengikuti langkah yang sama seperti yang diuraikan untuk developer aplikasi di atas, dengan satu artefak build untuk aplikasi RE maupun non-RE. Developer SDK dapat menyelesaikan kode mereka baik di Runtime SDK atau tidak, meskipun mungkin terdapat beberapa batasan pada alat pembuatan profil dan alat debug lanjutan. Kami sedang mempelajari area ini secara aktif.

Distribusi

Proposal desain kami untuk pemisahan aplikasi dari SDK-nya telah menciptakan kemungkinan untuk distribusi SDK melalui app store. Ini adalah kemungkinan umum, tidak hanya untuk app store tertentu. Manfaatnya jelas:

Memastikan kualitas dan konsistensi SDK.
Menyederhanakan publikasi untuk developer SDK.
Mempercepat peluncuran update SDK versi minor ke aplikasi yang diinstal.

Untuk mendukung distribusi SDK, app store kemungkinan harus menyediakan sebagian besar kemampuan berikut:

Mekanisme bagi developer SDK untuk mengupload SDK mereka yang dapat didistribusikan oleh app store ke toko, mengupdatenya, melakukan roll back, dan mungkin menghapusnya.
Mekanisme untuk memastikan integritas SDK dan sumbernya, aplikasi dan sumbernya, serta menyelesaikan dependensinya.
Mekanisme untuk men-deploynya ke perangkat dengan cara yang selalu dapat diandalkan dan berperforma baik.

Perubahan pembatasan dari waktu ke waktu

Pembatasan yang dialami kode dalam runtime SDK mungkin akan berubah dengan versi Android yang lebih baru. Untuk memastikan kompatibilitas aplikasi, kami tidak akan mengubah batasan ini dengan update modul mainline untuk level SDK tertentu. Perilaku yang terkait dengan targetSdkVersion tertentu dipertahankan hingga dukungan untuk targetSdkVersion tersebut tidak digunakan lagi melalui kebijakan app store, dan penghentian targetSdkVersion dapat terjadi pada ritme yang lebih cepat daripada aplikasi. Pembatasan mungkin akan sering berubah di seluruh versi Android SDK, terutama pada beberapa rilis pertama.

Selain itu, kami sedang membuat mekanisme canary untuk memungkinkan penguji eksternal dan internal bergabung dengan grup yang mendapatkan serangkaian pembatasan yang diusulkan untuk versi Android berikutnya. Tindakan ini akan membantu kami mendapatkan masukan dan kepercayaan terhadap perubahan yang diusulkan pada rangkaian batasan.

FAQ

Apa yang dimaksud dengan SDK terkait iklan?

SDK terkait iklan adalah SDK yang memfasilitasi setiap bagian penargetan pengguna dengan pesan untuk tujuan komersial, pada aplikasi yang tidak dimiliki oleh pengiklan. Hal ini mencakup, tetapi tidak terbatas pada, SDK analisis tempat grup pengguna dapat dibuat untuk penargetan selanjutnya, SDK penayangan iklan, SDK anti-penyalahgunaan dan antipenipuan untuk iklan, SDK interaksi, dan SDK atribusi.
Apakah setiap SDK dapat dijalankan di Runtime SDK?

Meskipun fokus awalnya adalah untuk SDK terkait iklan, developer SDK yang tidak terkait iklan yang mencari postur pro-privasi dan yakin bahwa mereka dapat beroperasi dalam kondisi yang diuraikan di atas dapat memberi masukan tentang SDK mereka yang berjalan di Runtime SDK. Namun, Runtime SDK tidak dirancang agar kompatibel dengan semua desain SDK. Di luar batasan yang didokumentasikan, Runtime SDK kemungkinan tidak cocok untuk SDK yang memerlukan komunikasi throughput tinggi atau real-time dengan aplikasi hosting.
Mengapa memilih isolasi proses, bukan isolasi dalam runtime berbasis Java pada proses?

Saat ini, runtime berbasis Java belum memfasilitasi batasan keamanan yang diperlukan untuk jaminan privasi yang diinginkan bagi pengguna Android. Upaya penerapan hal seperti ini kemungkinan memerlukan upaya selama beberapa tahun, tanpa jaminan keberhasilan. Oleh karena itu, Privacy Sandbox menggunakan batas proses penggunaan, yakni teknologi yang telah teruji waktu dan dipahami dengan baik.
Apakah memindahkan SDK ke dalam proses Runtime SDK akan menghemat ruang atau ukuran download?

Jika beberapa aplikasi diintegrasikan dengan SDK yang mengaktifkan runtime dari versi yang sama, hal ini dapat mengurangi ukuran download dan menghemat kapasitas disk.
Peristiwa siklus proses aplikasi seperti apa, misalnya saat aplikasi beralih ke latar belakang, yang aksesnya dimiliki SDK di Runtime SDK?

Kami sedang mengupayakan secara aktif dukungan desain untuk memberi tahu runtime SDK pada peristiwa siklus proses level aplikasi tentang aplikasi kliennya (mis. aplikasi yang beralih ke latar belakang, aplikasi yang beralih ke latar depan). Desain dan kode contoh akan dibagikan dalam pratinjau developer mendatang.

Direkomendasikan untuk Anda

Catatan: teks link ditampilkan saat JavaScript nonaktif
Panduan developer Runtime SDK