Dasar-Dasar Aplikasi

Aplikasi Android dapat ditulis menggunakan bahasa Kotlin, Java, dan C++. Fitur Android SDK mengompilasi kode Anda bersama data dan file resource menjadi sebuah APK: sebuah paket Android, yang berupa file arsip dengan akhiran .apk. Satu file APK berisi semua konten aplikasi Android dan merupakan file yang digunakan perangkat Android untuk menginstal aplikasi.

Setiap aplikasi Android berada dalam sandbox keamanannya sendiri, yang dilindungi dengan fitur keamanan Android berikut:

• Sistem operasi Android merupakan sistem Linux multi-pengguna yang di dalamnya setiap aplikasi adalah pengguna berbeda.
• Secara default, sistem menetapkan ID pengguna Linux unik kepada setiap aplikasi (ID ini hanya digunakan oleh sistem dan tidak diketahui aplikasi). Sistem menetapkan izin bagi semua file dalam aplikasi sehingga hanya ID pengguna yang diizinkan yang bisa mengaksesnya.
• Setiap proses memiliki mesin virtual (VM) sendiri, sehingga kode aplikasi berjalan secara terisolasi dari aplikasi lainnya.
• Secara default, setiap aplikasi berjalan dalam proses Linux-nya sendiri. Sistem Android memulai proses bila ada komponen aplikasi yang perlu dijalankan, lalu mematikan proses bila tidak lagi diperlukan atau bila sistem harus memulihkan memori untuk digunakan aplikasi lain.

Sistem Android mengimplementasikan prinsip privilese minim. Ini berarti, secara default aplikasi hanya memiliki akses ke komponen yang diperlukannya untuk melakukan pekerjaannya dan tidak lebih dari itu. Hal ini menghasilkan lingkungan yang sangat aman sehingga aplikasi tidak bisa mengakses bagian sistem bila tidak diberi izin. Akan tetapi, ada beberapa cara bagi aplikasi untuk berbagi data dengan aplikasi lain dan bagi aplikasi untuk mengakses layanan sistem:

• Dua aplikasi bisa diatur untuk menggunakan ID pengguna Linux yang sama, dalam hal ini keduanya bisa saling mengakses file masing-masing. Untuk menghemat sumber daya sistem, aplikasi dengan ID pengguna yang sama juga bisa diatur agar berjalan dalam proses Linux yang sama dan menggunakan VM yang sama. Aplikasi tersebut juga harus ditandatangani dengan sertifikat yang sama
• Aplikasi bisa meminta izin akses ke data perangkat seperti kontak pengguna, pesan SMS, penyimpanan lepas-pasang (kartu SD), kamera, dan Bluetooth. Pengguna secara eksplisit harus memberikan izin ini. Untuk informasi selengkapnya, lihat Bekerja dengan Izin Sistem.

Bagian selanjutnya dari dokumen ini memperkenalkan konsep berikut:

• Komponen kerangka kerja inti yang mendefinisikan aplikasi.
• File manifes tempat Anda mendeklarasikan komponen dan fitur yang diperlukan perangkat untuk aplikasi.
• Sumber daya yang terpisah dari kode aplikasi dan memungkinkan aplikasi mengoptimalkan perilakunya untuk beragam konfigurasi perangkat.

Komponen aplikasi

Komponen aplikasi adalah blok pembangun penting dari aplikasi Android. Setiap komponen adalah titik masuk tempat sistem atau pengguna dapat memasuki aplikasi Anda. Beberapa komponen bergantung pada komponen lainnya.

Ada empat macam tipe komponen aplikasi:

• Aktivitas
• Layanan
• Penerima siaran
• Penyedia materi

Setiap tipe memiliki kegunaan tersendiri dan daur hidupnya sendiri yang mendefinisikan cara komponen dibuat dan dimusnahkan. Bagian berikut menguraikan empat tipe komponen aplikasi.

Aktivitas

Aktivitas adalah titik masuk untuk berinteraksi dengan pengguna. Ini mewakili satu layar dengan antarmuka pengguna. Misalnya, aplikasi email mungkin memiliki satu aktivitas yang menampilkan daftar email baru, aktivitas lain untuk menulis email, dan aktivitas satunya lagi untuk membaca email. Walaupun semua aktivitas bekerja sama untuk membentuk pengalaman pengguna yang kohesif dalam aplikasi email, masing-masing tidak saling bergantung. Karenanya, aplikasi berbeda bisa memulai salah satu aktivitas ini (jika aplikasi email mengizinkannya). Misalnya, aplikasi kamera bisa memulai aktivitas dalam aplikasi email yang membuat email baru agar pengguna bisa berbagi gambar. Aktivitas mempermudah interaksi penting berikut di antara sistem dan aplikasi:

• Tetap memantau apa yang penting bagi pengguna saat ini (apa yang ada di layar) untuk memastikan bahwa sistem tetap menjalankan proses yang menjadi host aktivitas.
• Memahami proses yang digunakan sebelumnya berisi sesuatu yang dapat dikembalikan pengguna (aktivitas yang dihentikan), jadi lebih memprioritaskan mempertahankan proses tersebut.
• Membantu menangani aplikasi menghentikan prosesnya sehingga pengguna dapat kembali ke aktivitas dengan status sebelumnya yang dipulihkan.
• Memberikan cara bagi aplikasi untuk menerapkan alur antar pengguna, dan bagi sistem untuk mengoordinasikan alur ini. (Contoh yang paling klasik sedang dibagikan di sini).

Anda menerapkan aktivitas sebagai subclass dari class Activity. Untuk informasi selengkapnya tentang class Activity, lihat panduan developer Aktivitas.

Layanan

Layanan adalah titik masuk serbaguna untuk menjaga aplikasi tetap berjalan di latar belakang bagi semua jenis alasan. Ini adalah komponen yang berjalan di latar belakang untuk melakukan operasi yang berjalan lama atau untuk melakukan pekerjaan bagi proses jarak jauh. Layanan tidak menyediakan antarmuka pengguna. Misalnya, sebuah layanan bisa memutar musik di latar belakang sementara pengguna berada dalam aplikasi lain, atau layanan bisa menarik data lewat jaringan tanpa memblokir interaksi pengguna dengan aktivitas. Komponen lain, seperti aktivitas, bisa memulai layanan dan membiarkannya berjalan atau mengikat layanan untuk berinteraksi dengannya. Sebenarnya ada dua layanan semantik berbeda yang memberi tahu sistem tentang cara mengelola aplikasi: Layanan yang dimulai memberi tahu sistem agar tetap berjalan hingga pekerjaannya selesai. Hal ini bisa jadi untuk menyinkronkan beberapa data di latar belakang atau memutar musik meskipun setelah pengguna meninggalkan aplikasi tersebut. Menyinkronkan data di latar belakang atau memutar musik juga mewakili dua jenis layanan dimulai yang berbeda, yang memodifikasi bagaimana sistem menanganinya:

• Pemutaran musik adalah sesuatu yang disadari secara langsung oleh pengguna, jadi aplikasi tersebut memberi tahu sistem dengan mengatakan ingin berjalan di latar depan dengan notifikasi untuk memberi tahu pengguna tentang hal ini; dalam kasus ini sistem memahami bahwa harus benar-benar berusaha keras untuk menjaga proses layanan itu tetap berjalan, karena pengguna akan merasa tidak senang jika layanan itu hilang.
• Layanan latar belakang regular bukanlah sesuatu yang disadari pengguna secara langsung sebagai layanan yang berjalan, jadi sistem tersebut memiliki kebebasan lebih dalam mengelola prosesnya. Layanan ini mungkin diperbolehkan untuk dimatikan (lalu memulai ulang nanti) jika layanan ini memerlukan RAM untuk hal yang lebih penting bagi pengguna.

Layanan terikat berjalan karena beberapa aplikasi lain (atau sistem) dikatakan ingin menggunakan layanan tersebut. Pada dasarnya ini adalah layanan yang menyediakan API untuk proses lain. Dengan demikian sistem tersebut mengetahui adanya ketergantungan antar proses-proses ini, jadi jika proses A terikat ke layanan dalam proses B, proses A tahu bahwa harus mempertahankan proses B (beserta layanannya) agar tetap berjalan. Lebih lanjut, jika proses A adalah sesuatu yang dianggap penting bagi pengguna, maka proses A tersebut paham untuk memperlakukan proses B sebagai sesuatu yang juga dianggap penting bagi pengguna. Oleh karena fleksibilitasnya (baik atau buruk), layanan telah menjadi blok bangunan yang benar-benar berguna bagi semua jenis konsep sistem dengan level lebih tinggi. Wallpaper animasi, listener notifikasi, screen saver, metode masukan, layanan aksesibilitas, dan berbagai fitur sistem inti yang lain dibangun sebagai layanan yang menerapkan aplikasi dan mengikat sistem saat harus dijalankan.

Suatu layanan diterapkan sebagai subclass Service. Untuk informasi selengkapnya tentang class Service, lihat panduan developer Layanan.

Catatan: Apabila aplikasi Anda menargetkan Android 5.0 (API level 21) atau yang lebih baru, gunakan kelas JobScheduler untuk menjadwalkan tindakan. JobScheduler memiliki keuntungan dari penghematan baterai dengan menjadwalkan tugas secara optimal untuk mengurangi konsumsi daya, dan dengan menggunakan API Doze. Untuk informasi selengkapnya tentang menggunakan kelas ini, lihat dokumentasi referensi JobScheduler.

Penerima siaran

Penerima siaran adalah komponen yang memungkinkan sistem menyampaikan kejadian di luar alur pengguna regular, menjadikan aplikasi tersebut dapat merespons pengumuman siaran seluruh sistem. Oleh karena penerima siaran adalah entri yang didefinisikan dengan baik ke dalam aplikasi, sistem dapat mengirimkan siaran meskipun ke aplikasi yang saat ini tidak berjalan. Jadi, misalnya, suatu aplikasi dapat menjadwalkan alarm untuk mengirimkan notifikasi agar pengguna tahu tentang acara yang akan datang... dan dengan mengirimkan alarm tersebut ke Penerima Siaran aplikasi, aplikasi tersebut tidak perlu untuk tetap berjalan hingga alarm mati. Banyak siaran berasal dari sistem—misalnya, siaran yang mengumumkan bahwa layar sudah dimatikan, baterai lemah, atau gambar sudah diambil. Aplikasi juga dapat mengawali siaran—misalnya, untuk memberi tahu aplikasi lain bahwa beberapa data sudah didownload ke perangkat dan tersedia untuk digunakan. Walaupun penerima siaran tidak menampilkan antarmuka pengguna, penerima bisa membuat notifikasi bilah status untuk memberi tahu pengguna kapan kejadian siaran dilakukan. Meskipun penerima siaran umumnya cuma menjadi gerbang untuk komponen lain dan dimaksudkan untuk melakukan pekerjaan dalam jumlah sangat minim. Misalnya, mungkin dijadwalkan JobService melakukan beberapa pekerjaan berdasarkan acara dengan JobScheduler

Penerima siaran diimplementasikan sebagai subclass BroadcastReceiver dan setiap siaran dikirim sebagai objek Intent. Untuk informasi selengkapnya, lihat class BroadcastReceiver.

Penyedia materi

Penyedia materi mengelola set data aplikasi secara bersama-sama, yang dapat Anda simpan di sistem file, di database SQLite, di web, atau di lokasi penyimpanan persisten lain yang dapat diakses aplikasi Anda. Melalui penyedia materi, aplikasi lain bisa melakukan kueri atau memodifikasi data jika penyedia materi mengizinkannya. Misalnya, sistem Android menyediakan penyedia materi yang mengelola informasi kontak pengguna. Karenanya, setiap aplikasi dengan izin yang sesuai bisa melakukan kueri mengenai bagian dari penyedia materi, seperti ContactsContract.Data, untuk membaca dan menulis informasi tentang orang tertentu. Aplikasi ini membujuk agar memikirkan penyedia konten sebagai abstraksi di database, karena terdapat banyak API dan dukungan dibuat untuk kasus umum tersebut. Namun demikian, penyedia konten memiliki beragam tujuan inti untuk perspektif desain-sistem. Bagi sistem, penyedia konten adalah titik masuk ke dalam suatu aplikasi untuk memublikasikan item data bernama, yang diidentifikasi oleh skema URI. Jadi sebuah aplikasi dapat memutuskan bagaimana ia ingin memetakan data yang ada di dalamnya ke ruang nama URI, membagikan URI tersebut ke entitas lain yang dapat menggunakannya guna mengakses data. Ada beberapa hal tertentu yang dapat dilakukan sistem dalam mengelola sebuah aplikasi:

• Menetapkan URI tidak mengharuskan aplikasi tetap berjalan, sehingga URI dapat terus ada setelah aplikasi yang memilikinya keluar. Sistem hanya perlu memastikan bahwa aplikasi yang memilikinya masih berjalan saat harus mengambil data aplikasi tersebut dari URI yang terkait.
• URI ini juga menyediakan model keamanan halus yang penting. Misalnya, sebuah aplikasi dapat menempatkan URO untuk gambar yang ada di papan klip, namun membiarkan penyedia kontennya terkunci sehingga aplikasi lain tidak dapat mengaksesnya secara bebas. Apabila aplikasi kedua berupaya mengakses URI tersebut di papan klip, sistem dapat mengizinkan aplikasi tersebut untuk mengakses data melalui pemberian izin URI sementara sehingga diizinkan mengakses data hanya di belakang URI tersebut, namun tidak ada data lainnya di aplikasi kedua itu.

Penyedia materi juga berguna untuk membaca dan menulis data privat ke aplikasi Anda dan tidak dibagikan.

Penyedia materi diimplementasikan sebagai subclass ContentProvider dan harus mengimplementasikan seperangkat standar API yang memungkinkan aplikasi lain melakukan transaksi. Untuk informasi selengkapnya, lihat panduan developer Penyedia Materi.

Aspek unik dari desain sistem Android adalah aplikasi mana pun bisa memulai komponen aplikasi lain. Misalnya, jika Anda menginginkan pengguna mengambil foto dengan kamera perangkat, bisa saja aplikasi lain yang melakukannya dan aplikasi Anda bisa menggunakannya, sebagai ganti mengembangkan aktivitas sendiri untuk mengambil foto. Anda tidak perlu menggabungkan atau bahkan menghubungkan ke kode dari aplikasi kamera. Sebagai gantinya, Anda dapat memulai aktivitas di aplikasi kamera yang berupa aktivitas mengambil sebuah foto. Bila selesai, foto akan dikembalikan ke aplikasi sehingga Anda bisa menggunakannya. Bagi pengguna, kamera seakan menjadi bagian dari aplikasi Anda.

Saat sistem memulai komponen, sistem akan memulai proses untuk aplikasi itu (jika belum berjalan) dan membuat instance class yang diperlukan untuk komponen. Misalnya, jika aplikasi Anda memulai aktivitas dalam aplikasi kamera yang berupa aktivitas mengambil foto, aktivitas itu akan berjalan dalam proses yang dimiliki oleh aplikasi kamera, bukan dalam proses aplikasi Anda. Karenanya, tidak seperti aplikasi di sebagian besar sistem lain, aplikasi Android tidak memiliki titik masuk tunggal (tidak ada main() fungsi).

Karena sistem menjalankan setiap aplikasi dalam proses terpisah dengan izin file yang membatasi akses ke aplikasi lain, aplikasi Anda tidak bisa langsung mengaktifkan komponen dari aplikasi lain. Namun demikian, sistem Android dapat melakukan hal tersebut. Untuk mengaktifkan komponen dalam aplikasi lain, kirim pesan ke sistem yang menetapkan intent Anda untuk memulai komponen tertentu. Selanjutnya sistem akan mengaktifkan komponen untuk Anda.

Mengaktifkan komponen

Tiga dari empat tipe komponen—aktivitas, layanan, dan penerima siaran—diaktifkan oleh pesan asinkron yang disebut intent. Intents mengikat antar masing-masing komponen di runtime. Anda dapat menganggap intent sebagai messenger yang meminta tindakan dari komponen lain, entah komponen milik aplikasi Anda atau komponen lainnya.

Intent dibuat dengan objek Intent, yang mendefinisikan pesan untuk mengaktifkan komponen tertentu (intent ekspolisit) atau tipe komponen spesifik (intent implisit).

Untuk aktivitas dan layanan, intent mendefinisikan aksi yang akan dilakukan (misalnya, untuk melihat atau mengirim sesuatu) dan mungkin menetapkan URI data untuk ditindaklanjuti, salah satu hal yang mungkin perlu diketahui oleh komponen yang akan dimulai. Misalnya, intent mungkin menyampaikan permintaan suatu aktivitas untuk menampilkan gambar atau membuka halaman web. Dalam beberapa kasus, Anda dapat mengawali aktivitas untuk menerima hasil, dalam kasus ini aktivitas juga mengembalikan hasil dalam Intent. Misalnya, Anda bisa mengeluarkan intent agar pengguna dapat memilih kontak pribadi dan mengembalikannya kepada Anda. Inten yang dikembalikan mencakup URI yang menunjuk ke kontak terpilih.

Untuk penerima siaran, intent hanya mendefinisikan pengumuman yang sedang disiarkan. Misalnya, siaran untuk menunjukkan baterai perangkat hampir habis hanya menyertakan string tindakan yang menunjukkan baterai hampir habis.

Tidak seperti aktivitas, layanan, dan penerima siaran, penyedia konten tidak diaktifkan oleh intent. Melainkan, diaktifkan saat ditargetkan oleh permintaan dari ContentResolver. Resolver konten menangani semua transaksi langsung dengan penyedia konten sehingga komponen yang melakukan transaksi dengan penyedia tidak perlu dan sebagai gantinya memanggil metode pada objek ContentResolver. Ini membuat layer abstraksi antara penyedia konten dan komponen yang meminta informasi (demi keamanan).

Ada beberapa metode terpisah untuk mengaktifkan masing-masing tipe komponen:

• Anda bisa memulai aktivitas (atau memberinya pekerjaan baru) dengan meneruskan Intent ke startActivity() atau startActivityForResult() (bila Anda ingin aktivitas mengembalikan hasil).
• Dengan Android 5.0 (API level 21) dan sesudahnya, Anda dapat menggunakan class JobScheduler untuk menjadwalkan tindakan. Untuk versi Android sebelumnya, Anda bisa memulai layanan (atau memberikan petunjuk baru ke layanan yang sedang berlangsung) dengan meneruskan Intent ke startService(). Anda bisa mengikat ke layanan dengan meneruskan Intent ke bindService().
• Anda bisa memulai siaran dengan meneruskan Intent ke metode-metode seperti sendBroadcast(), sendOrderedBroadcast(), atau sendStickyBroadcast().
• Anda bisa melakukan kueri ke penyedia konten dengan memanggil query() pada ContentResolver.

Untuk informasi selengkapnya tentang menggunakan intent, lihat dokumen Intent dan Filter Intent. Dokumen berikut memberikan informasi lebih lanjut tentang mengaktifkan komponen tertentu: Aktivitas, Layanan, BroadcastReceiver, dan Penyedia Konten.

File manifes

Sebelum sistem Android bisa memulai komponen aplikasi, sistem harus mengetahui bahwa komponen ada dengan membaca file manifes, AndroidManifest.xml aplikasi. Aplikasi Anda harus mendeklarasikan semua komponennya dalam file ini, yang harus menjadi root dari direktori proyek aplikasi.

Manifes melakukan banyak hal selain mendeklarasikan komponen aplikasi, seperti yang berikut:

• Mengidentifikasi izin pengguna yang diperlukan aplikasi, seperti akses Internet atau akses-baca ke kontak pengguna.
• Mendeklarasikan API Level minimum yang diperlukan aplikasi, berdasarkan API yang digunakan aplikasi.
• Mendeklarasikan fitur perangkat keras dan perangkat lunak yang diperlukan aplikasi, seperti kamera, layanan Bluetooth, atau layar multisentuh.
• Mendeklarasikan pustaka API aplikasi perlu ditautkan (selain Android framework API), seperti library Google Maps.

Mendeklarasikan komponen

Tugas utama manifes adalah menginformasikan komponen aplikasi pada sistem. Misalnya, file manifes bisa mendeklarasikan aktivitas sebagai berikut:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

Dalam elemen <application>, atribut android:icon menunjuk ke sumber daya untuk ikon yang mengidentifikasi aplikasi.

Dalam elemen <activity>, atribut android:name menetapkan nama class yang sepenuhnya memenuhi syarat subclass Activity dan atribut android:label menetapkan string yang akan digunakan sebagai label yang terlihat oleh pengguna untuk aktivitas tersebut.

Anda harus mendeklarasikan semua komponen aplikasi menggunakan elemen berikut:

• Elemen <activity> untuk aktivitas.
• Elemen <service> untuk layanan.
• Elemen <receiver> untuk penerima siaran.
• Elemen <provider> untuk penyedia konten.

Aktivitas, layanan, dan penyedia konten yang Anda sertakan dalam kode sumber, namun tidak dideklarasikan dalam manifes, tidak akan terlihat pada sistem dan, akibatnya, tidak pernah bisa berjalan. Akan tetapi, penerima siaran bisa dideklarasikan dalam manifes atau dibuat secara dinamis dalam kode sebagai objek BroadcastReceiver dan didaftarkan pada sistem dengan memanggil registerReceiver().

Untuk informasi selengkapnya tentang cara menstrukturkan file manifes untuk aplikasi Anda, lihat dokumentasi File AndroidManifest.xml.

Mendeklarasikan kemampuan komponen

Seperti telah dibahas di atas, dalam Mengaktifkan omponen, Anda bisa menggunakan Intent untuk memulai aktivitas, layanan, dan penerima siaran. Anda bisa menggunakan Intent dengan menamai komponen sasaran secara eksplisit (menggunakan nama class komponen) dalam intent. Anda juga dapat menggunakan intent implisit, yang menjelaskan tipe tindakan yang dilakukan dan, secara opsional, data tempat Anda ingin melakukan tindakan. Dengan intent implisit, sistem dapat menemukan komponen di perangkat yang dapat menjalankan tindakan dan memulainya. Jika ada banyak komponen yang bisa melakukan tindakan yang dijelaskan oleh intent, maka pengguna bisa memilih komponen yang akan digunakan.

Perhatian: Jika Anda menggunakan intent untuk memulai Service, pastikan bahwa aplikasi Anda aman dengan menggunakan intent eksplisit. Menggunakan intent implisit untuk memulai layanan akan menimbulkan bahaya keamanan karena Anda tidak bisa memastikan layanan apa yang akan merespons intent, dan pengguna tidak bisa melihat layanan mana yang dimulai. Mulai dari Android 5.0 (API level 21), sistem melontarkan pengecualian jika Anda memanggil bindService() dengan intent implisit. Jangan mendeklarasikan filtern intent untuk layanan Anda.

Sistem mengidentifikasi komponen yang bisa merespons maksud adalah dengan membandingkan intent yang diterima dengan filter intent yang disediakan dalam file manifes aplikasi lainnya pada perangkat.

Bila mendeklarasikan aktivitas dalam manifes aplikasi, secara opsional Anda bisa menyertakan filter intent yang mendeklarasikan kemampuan aktivitas agar bisa merespons intent dari aplikasi lain. Anda bisa mendeklarasikan filter intent untuk komponen dengan menambahkan elemen <intent-filter> sebagai anak elemen deklarasi komponen.

Misalnya, jika Anda membuat aplikasi email dengan aktivitas untuk menulis email baru, Anda bisa mendeklarasikan filter maksud untuk merespons intent "kirim" (untuk mengirim email baru) seperti yang ditunjukkan di contoh berikut:

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

Kemudian, jika aplikasi lain membuat intent dengan aksi ACTION_SEND dan meneruskannya ke startActivity(), sistem mungkin akan memulai aktivitas Anda agar pengguna bisa menulis draf dan mengirim email.

Untuk informasi selengkapnya tentang membuat filter intent, lihat dokumen Intent dan Filter Intent.

Mendeklarasikan persyaratan aplikasi

Ada berbagai macam perangkat yang didukung oleh Android dan tidak semuanya menyediakan fitur dan kemampuan yang sama. Untuk mencegah aplikasi Anda diinstal pada perangkat yang tidak memiliki fitur yang diperlukan aplikasi, Anda harus jelas mendefinisikan profil mengenai tipe perangkat yang didukung aplikasi dengan mendeklarasikan kebutuhan perangkat dan perangkat lunak dalam file manifes. Kebanyakan deklarasi ini hanya bersifat informasi dan sistem tidak membacanya, namun layanan eksternal seperti Google Play akan membacanya untuk menyediakan penyaringan bagi pengguna saat mereka menelusuri aplikasi dari perangkat.

Misalnya, jika aplikasi memerlukan kamera dan menggunakan API yang disediakan dalam Android 2.1 (API Level 7), Anda harus mendeklarasikannya sebagai kebutuhan dalam file manifes seperti ditunjukkan dalam contoh berikut:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" />
    ...
</manifest>

Dengan deklarasi yang ditunjukkan dalam contoh tersebut, perangkat yang tidak memiliki kamera dan menggunakan Android versi lebih rendah dari 2.1 tidak bisa menginstal aplikasi Anda dari Google Play. Akan tetapi, Anda dapat mendeklarasikan bahwa aplikasi Anda menggunakan kamera, namun tidak mengharuskannya. Dalam hal itu, aplikasi Anda harus menyetel atribut required ke false dan memeriksa pada waktu proses apakah perangkat memiliki kamera dan menonaktifkan setiap fitur kamera yang sesuai.

Informasi selengkapnya tentang cara mengelola kompatibilitas aplikasi dengan perangkat yang berbeda disediakan dalam dokumen Kompatibilitas Perangkat.

Sumber daya aplikasi

Aplikasi Android tidak hanya terdiri dari kode—aplikasi memerlukan sumber daya yang terpisah dari kode sumber, seperti gambar, file audio, dan apa saja yang berkaitan dengan presentasi visual suatu aplikasi. Misalnya, Anda dapat mendefinisikan animasi, menu, gaya, warna, dan layout antarmuka pengguna aktivitas dengan file XML. Dengan menggunakan sumber daya aplikasi mempermudah dalam mengupdate berbagai karakteristik aplikasi Anda tanpa memodifikasi kode. Menyediakan seperangkat sumber daya alternatif memungkinkan Anda mengoptimalkan aplikasi untuk berbagai konfigurasi perangkat berbeda (seperti bahasa dan ukuran layar yang berbeda).

Untuk setiap sumber daya yang Anda sertakan dalam proyek Android, alat bawaan SDK akan mendefinisikan ID integer unik, yang bisa Anda gunakan untuk mengacu sumber daya dari kode aplikasi atau dari sumber daya lainnya yang didefinisikan dalam XML. Misalnya, jika aplikasi berisi file gambar bernama logo.png (disimpan dalam direktori res/drawable/), alat SDK akan menghasilkan ID sumber daya bernama R.drawable.logo. Peta ID ini untuk integer khusus aplikasi, yang dapat Anda gunakan untuk mereferensikan gambar dan memasukkannya dalam antarmuka pengguna.

Salah satu aspek paling penting dari penyediaan sumber daya yang terpisah dari kode sumber adalah kemampuan untuk menyediakan sumber daya alternatif untuk konfigurasi perangkat yang berbeda. Misalnya, dengan mendefinisikan string UI dalam XML, Anda bisa menerjemahkan string ke dalam bahasa lain dan menyimpan string itu dalam file terpisah. Lalu Android menerapkan string bahasa yang sesuai ke UI Anda berdasarkan qualifier bahasa yang Anda tambahkan ke nama direktori sumber daya (seperti res/values-fr/ untuk nilai string bahasa Prancis) dan setelan bahasa pengguna.

Android mendukung banyak qualifier berbeda untuk sumber daya alternatif Anda. Qualifier adalah string pendek yang Anda sertakan dalam nama direktori sumber daya untuk mendefinisikan konfigurasi perangkat yang harus digunakan sumber daya tersebut. Misalnya, Anda harus membuat layout berbeda untuk aktivitas, bergantung pada orientasi layar dan ukuran perangkat. Apabila layar perangkat dalam orientasi potret, Anda mungkin ingin layout tombolnya vertikal (tinggi), tetapi saat layar dalam orientasi lanskap (lebar), tombolnya dapat disejajarkan secara horizontal. Untuk mengubah layout sesuai orientasi, Anda bisa mendefinisikan dua layout berbeda dan menerapkan qualifier yang tepat untuk setiap nama direktori layout. Kemudian, sistem secara otomatis menerapkan layout yang tepat sesuai dengan orientasi perangkat saat ini.

Untuk informasi selengkapnya tentang berbagai jenis sumber daya yang bisa disertakan dalam aplikasi dan cara membuat sumber daya alternatif untuk konfigurasi perangkat berbeda, bacalah Menyediakan Sumber Daya. Untuk mengetahui tentang praktik terbaik dan mendesain aplikasi berkualitas produksi yang kuat, lihat Panduan untuk Arsitektur Aplikasi.

Sumber daya tambahan

Jika Anda ingin mempelajari dengan video dan tutorial kode, baca kursus Udacity Mengembangkan Aplikasi Android Apps dengan Kotlin, atau kunjungi halaman lain di panduan online ini: