Dasar-dasar aplikasi

Aplikasi Android dapat ditulis menggunakan Kotlin, bahasa pemrograman Java, dan bahasa C++. Android SDK Tools mengompilasi kode Anda bersama dengan file data dan resource apa pun ke dalam APK atau Android App Bundle.

Paket Android, yang merupakan file arsip dengan akhiran .apk, berisi konten aplikasi Android yang diperlukan saat runtime, dan merupakan file yang digunakan perangkat Android untuk menginstal aplikasi.

Android App Bundle, yang merupakan file arsip dengan akhiran .aab, berisi konten project aplikasi Android, termasuk beberapa metadata tambahan yang tidak diperlukan saat runtime. AAB adalah format publikasi dan tidak dapat diinstal di perangkat Android. Kebijakan ini menunda pembuatan dan penandatanganan APK ke tahap berikutnya.

Misalnya, saat mendistribusikan aplikasi melalui Google Play, server Google Play membuat APK yang dioptimalkan dan hanya berisi resource dan kode yang diperlukan oleh perangkat tertentu yang meminta penginstalan aplikasi.

Setiap aplikasi Android berada di sandbox keamanannya sendiri, yang dilindungi oleh fitur keamanan Android berikut:

  • Sistem operasi Android merupakan sistem Linux multi-pengguna yang di dalamnya setiap aplikasi adalah pengguna yang berbeda.
  • Secara default, sistem menetapkan ID pengguna Linux unik kepada setiap aplikasi, yang hanya digunakan oleh sistem dan tidak diketahui oleh aplikasi. Sistem menetapkan izin untuk semua file dalam aplikasi sehingga hanya ID pengguna yang ditetapkan ke aplikasi tersebut yang dapat mengaksesnya.
  • Setiap proses memiliki mesin virtual (VM) sendiri, sehingga kode aplikasi berjalan secara terpisah dari aplikasi lain.
  • Secara default, setiap aplikasi berjalan dalam proses Linux-nya sendiri. Sistem Android memulai proses saat salah satu komponen aplikasi perlu dijalankan, lalu menghentikan proses saat tidak lagi diperlukan atau saat sistem harus memulihkan memori untuk aplikasi lain.

Sistem Android menerapkan prinsip hak istimewa terendah. Artinya, secara default, setiap aplikasi hanya memiliki akses ke komponen yang diperlukannya untuk melakukan pekerjaannya dan tidak lebih. Hal ini menghasilkan lingkungan yang sangat aman sehingga aplikasi tidak dapat mengakses bagian sistem yang izinnya tidak diberikan.

Namun, ada cara bagi aplikasi untuk berbagi data dengan aplikasi lain dan agar aplikasi dapat mengakses layanan sistem:

  • Dua aplikasi dapat diatur agar memiliki ID pengguna Linux yang sama, sehingga keduanya dapat saling mengakses file masing-masing. Untuk menghemat resource sistem, aplikasi dengan ID pengguna yang sama juga dapat diatur agar berjalan dalam proses Linux yang sama dan berbagi VM yang sama. Aplikasi juga harus ditandatangani dengan sertifikat yang sama.
  • Aplikasi dapat meminta izin untuk mengakses data perangkat seperti lokasi perangkat, kamera, dan koneksi Bluetooth. Pengguna harus memberikan izin ini secara eksplisit. Untuk mengetahui informasi selengkapnya tentang izin, lihat Izin di Android.

Bagian selanjutnya dari dokumen ini memperkenalkan konsep berikut:

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

Komponen aplikasi

Komponen aplikasi adalah elemen penyusun penting aplikasi Android. Setiap komponen adalah titik entri tempat sistem atau pengguna dapat memasuki aplikasi Anda. Beberapa komponen bergantung pada komponen lainnya.

Ada empat jenis komponen aplikasi:

  • Aktivitas
  • Layanan
  • Penerima siaran
  • Penyedia konten

Setiap jenis memiliki kegunaan tersendiri dan siklus proses yang menentukan cara komponen dibuat dan dihancurkan. Bagian berikut menguraikan empat tipe komponen aplikasi.

Aktivitas
Aktivitas adalah titik entri untuk berinteraksi dengan pengguna. Class 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 lain untuk membaca email. Meskipun aktivitas bekerja sama untuk membentuk pengalaman pengguna yang kohesif di aplikasi email, masing-masing tidak saling bergantung.

Aplikasi lain dapat memulai salah satu aktivitas ini jika aplikasi email mengizinkannya. Misalnya, aplikasi kamera mungkin memulai aktivitas di aplikasi email untuk menulis email baru agar pengguna dapat berbagi gambar.

Aktivitas mempermudah interaksi penting berikut di antara sistem dan aplikasi:

  • Melacak hal yang saat ini penting bagi pengguna—apa yang ada di layar—sehingga sistem terus menjalankan proses yang menghosting aktivitas tersebut.
  • Mengetahui proses yang digunakan sebelumnya berisi aktivitas yang dihentikan yang mungkin digunakan kembali oleh pengguna dan memprioritaskan proses tersebut dengan lebih tinggi agar tetap tersedia.
  • Membantu aplikasi menangani penghentian prosesnya sehingga pengguna dapat kembali ke aktivitas dengan status sebelumnya dipulihkan.
  • Memberikan cara bagi aplikasi untuk mengimplementasikan alur penggunaan antara satu sama lain, dan bagi sistem untuk mengoordinasikan alur ini. Contoh utamanya adalah berbagi.

Anda menerapkan aktivitas sebagai subclass dari class Activity. Untuk informasi selengkapnya tentang class Activity, lihat Pengantar aktivitas.

Layanan
Layanan adalah titik entri dengan tujuan umum untuk menjaga aplikasi tetap berjalan di latar belakang karena segala jenis alasan. Ini adalah komponen yang berjalan di latar belakang untuk menjalankan operasi yang berjalan lama atau untuk melakukan pekerjaan bagi proses jarak jauh. Layanan tidak menyediakan antarmuka pengguna.

Misalnya, layanan mungkin memutar musik di latar belakang saat pengguna berada dalam aplikasi lain, atau layanan dapat mengambil data melalui jaringan tanpa memblokir interaksi pengguna dengan aktivitas. Komponen lain, seperti aktivitas, bisa memulai layanan dan membiarkannya berjalan atau mengikatnya untuk berinteraksi dengannya.

Ada dua jenis layanan yang memberi tahu sistem cara mengelola aplikasi: layanan yang dimulai dan layanan terikat.

Layanan yang dimulai memberi tahu sistem untuk tetap berjalan hingga pekerjaannya selesai. Hal ini mungkin dilakukan untuk menyinkronkan beberapa data di latar belakang atau memutar musik bahkan setelah pengguna meninggalkan aplikasi. Menyinkronkan data di latar belakang atau memutar musik mewakili berbagai jenis layanan dimulai, yang ditangani sistem secara berbeda:

  • Pemutaran musik adalah sesuatu yang diketahui pengguna secara langsung, dan aplikasi menyampaikan ini kepada sistem dengan menunjukkan bahwa aplikasi ingin berada di latar depan, dengan notifikasi untuk memberi tahu pengguna bahwa aplikasi sedang berjalan. Dalam hal ini, sistem memprioritaskan menjaga proses layanan tersebut tetap berjalan, karena pengguna akan mendapatkan pengalaman buruk jika layanan tersebut dihentikan.
  • Layanan latar belakang reguler bukanlah sesuatu yang diketahui pengguna secara langsung, sehingga sistem memiliki lebih banyak kebebasan dalam mengelola prosesnya. Layanan mungkin membiarkannya dimatikan, memulai ulang layanan nanti, jika memerlukan RAM untuk hal-hal yang menjadi masalah yang lebih mendesak bagi pengguna.

Layanan terikat berjalan karena beberapa aplikasi lain (atau sistem) telah mengatakan bahwa aplikasi tersebut ingin menggunakan layanan tersebut. Layanan terikat menyediakan API ke proses lain, dan sistem mengetahui bahwa ada dependensi di antara proses tersebut. Jadi, jika proses A terikat ke layanan dalam proses B, sistem akan tahu bahwa proses B dan layanannya harus tetap berjalan untuk A. Selanjutnya, jika proses A merupakan sesuatu yang penting bagi pengguna, proses B akan diperlakukan sebagai hal yang juga penting bagi pengguna.

Karena fleksibilitasnya, layanan adalah elemen penyusun yang berguna untuk semua jenis konsep sistem pada level yang lebih tinggi. Wallpaper animasi, pemroses notifikasi, screensaver, metode input, layanan aksesibilitas, dan banyak fitur sistem inti lainnya dibuat sebagai layanan yang diimplementasikan aplikasi dan terikat oleh sistem saat aplikasi berjalan.

Layanan diimplementasikan sebagai subclass dari Service. Untuk informasi selengkapnya tentang class Service, lihat Ringkasan layanan.

Catatan: Jika aplikasi Anda menargetkan Android 5.0 (API level 21) atau yang lebih tinggi, gunakan class JobScheduler untuk menjadwalkan tindakan. JobScheduler memiliki keuntungan dalam menghemat baterai dengan menjadwalkan tugas secara optimal untuk mengurangi konsumsi daya dan dengan menggunakan Doze API. Untuk mengetahui informasi selengkapnya tentang penggunaan class ini, lihat dokumentasi referensi JobScheduler.

Penerima siaran
Penerima siaran adalah komponen yang memungkinkan sistem mengirim peristiwa ke aplikasi di luar alur pengguna reguler, sehingga aplikasi dapat merespons pengumuman siaran seluruh sistem. Karena penerima siaran adalah entri lain yang didefinisikan dengan baik ke dalam aplikasi, sistem dapat mengirimkan siaran bahkan ke aplikasi yang saat ini tidak berjalan.

Jadi, misalnya, aplikasi dapat menjadwalkan alarm untuk memposting notifikasi guna memberi tahu pengguna tentang acara mendatang. Karena alarm dikirim ke BroadcastReceiver dalam aplikasi, aplikasi tidak perlu tetap berjalan hingga alarm berbunyi.

Banyak siaran berasal dari sistem, seperti siaran yang mengumumkan bahwa layar dimatikan, baterai lemah, atau gambar diambil. Aplikasi juga dapat memulai siaran, seperti memberi tahu aplikasi lain bahwa beberapa data didownload ke perangkat dan tersedia untuk digunakan.

Meskipun penerima siaran tidak menampilkan antarmuka pengguna, penerima dapat membuat notifikasi status bar untuk memberi tahu pengguna saat peristiwa siaran terjadi. Namun, biasanya penerima siaran hanyalah gateway untuk komponen lain dan dimaksudkan untuk melakukan pekerjaan yang sangat minim.

Misalnya, penerima siaran mungkin menjadwalkan JobService untuk melakukan beberapa tugas berdasarkan peristiwa menggunakan JobScheduler. Penerima siaran sering kali melibatkan aplikasi yang berinteraksi satu sama lain, sehingga penting untuk mengetahui implikasi keamanan saat menyiapkannya.

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

Penyedia konten
Penyedia konten mengelola kumpulan data aplikasi bersama yang dapat Anda simpan dalam sistem file, dalam database SQLite, di web, atau di lokasi penyimpanan persisten lainnya yang dapat diakses oleh aplikasi Anda. Melalui penyedia konten, aplikasi lain dapat membuat kueri atau mengubah data tersebut, jika penyedia konten mengizinkannya.

Misalnya, sistem Android menyediakan penyedia konten yang mengelola informasi kontak pengguna. Semua aplikasi dengan izin yang tepat dapat mengkueri penyedia konten, seperti menggunakan ContactsContract.Data, untuk membaca dan menulis informasi tentang orang tertentu.

Anda mungkin tergoda untuk menganggap penyedia konten sebagai abstraksi pada database, karena terdapat banyak API dan dukungan bawaan untuk kasus umum tersebut. Namun demikian, mereka memiliki tujuan inti yang berbeda dari perspektif desain sistem.

Bagi sistem, penyedia konten adalah titik entri ke aplikasi untuk memublikasikan item data bernama, yang diidentifikasi oleh skema URI. Dengan demikian, aplikasi dapat memutuskan cara memetakan data yang ada di dalamnya ke namespace URI, yang membagikan URI tersebut ke entity lain yang kemudian dapat menggunakannya untuk mengakses data. Ada beberapa hal tertentu yang dapat dilakukan sistem dalam mengelola aplikasi:

  • Menetapkan URI tidak mengharuskan aplikasi tetap berjalan, sehingga URI dapat tetap ada setelah aplikasi yang memilikinya keluar. Sistem hanya perlu memastikan bahwa aplikasi yang memiliki masih berjalan saat mengambil data aplikasi dari URI yang sesuai.
  • URI ini juga menyediakan model keamanan halus yang penting. Misalnya, aplikasi dapat menempatkan URI untuk gambar yang ada di papan klip, tetapi membiarkan penyedia kontennya terkunci sehingga aplikasi lain tidak dapat mengaksesnya dengan bebas. Saat aplikasi kedua mencoba mengakses URI tersebut di papan klip, sistem dapat mengizinkan aplikasi tersebut mengakses data menggunakan pemberian izin URI sementara sehingga aplikasi hanya dapat mengakses data di belakang URI tersebut, dan bukan data lainnya di aplikasi kedua.

Penyedia konten juga berguna untuk membaca dan menulis data yang bersifat pribadi untuk aplikasi Anda dan tidak dibagikan.

Penyedia konten diterapkan sebagai subclass ContentProvider dan harus mengimplementasikan sekumpulan API standar yang memungkinkan aplikasi lain melakukan transaksi. Untuk mengetahui informasi selengkapnya, lihat panduan developer Penyedia konten.

Aspek unik dari desain sistem Android adalah aplikasi apa pun dapat memulai komponen aplikasi lain. Misalnya, jika Anda ingin pengguna mengambil foto dengan kamera perangkat, mungkin ada aplikasi lain yang melakukannya—dan aplikasi Anda dapat menggunakannya, bukan mengembangkan aktivitas untuk mengambil foto sendiri. Anda tidak perlu menggabungkan atau bahkan menautkan ke kode dari aplikasi kamera. Sebagai gantinya, Anda dapat memulai aktivitas di aplikasi kamera yang mengambil foto. Bila selesai, foto akan dikembalikan ke aplikasi sehingga Anda bisa menggunakannya. Bagi pengguna, kamera seakan-akan merupakan bagian dari aplikasi Anda.

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

Karena sistem menjalankan setiap aplikasi dalam proses terpisah dengan izin file yang membatasi akses ke aplikasi lain, aplikasi Anda tidak dapat langsung mengaktifkan komponen dari aplikasi lain. Namun, sistem Android dapat melakukannya. Untuk mengaktifkan komponen dalam aplikasi lain, Anda harus mengirim pesan ke sistem yang menentukan intent Anda untuk memulai komponen tertentu. Selanjutnya sistem akan mengaktifkan komponen untuk Anda.

Mengaktifkan komponen

Pesan asinkron yang disebut intent mengaktifkan tiga dari empat jenis komponen: aktivitas, layanan, dan penerima siaran. Intents mengikat antar masing-masing komponen di runtime. Anda dapat menganggapnya sebagai pesan yang meminta tindakan dari komponen lain, baik komponen tersebut milik aplikasi Anda maupun komponen lainnya.

Intent dibuat dengan objek Intent, yang mendefinisikan pesan untuk mengaktifkan komponen tertentu (intent eksplisit) atau jenis komponen tertentu (intent implisit).

Untuk aktivitas dan layanan, intent menentukan tindakan yang akan dilakukan, seperti untuk melihat atau mengirim sesuatu, dan mungkin menentukan URI data yang akan ditindaklanjuti, di antara hal-hal lain yang mungkin perlu diketahui oleh komponen yang dimulai.

Misalnya, intent mungkin menyampaikan permintaan suatu aktivitas untuk menampilkan gambar atau membuka halaman web. Dalam beberapa kasus, Anda dapat memulai aktivitas untuk menerima hasil. Dalam hal ini, aktivitas juga akan menampilkan hasil tersebut dalam Intent. Anda juga dapat memberikan intent untuk memungkinkan pengguna memilih kontak pribadi dan mengembalikannya kepada Anda. Intent yang ditampilkan menyertakan URI yang mengarah ke kontak yang dipilih.

Untuk penerima siaran, intent tersebut menentukan pengumuman siaran. Misalnya, siaran untuk menunjukkan bahwa baterai perangkat hampir habis hanya menyertakan string tindakan yang diketahui yang menunjukkan baterai hampir habis.

Tidak seperti aktivitas, layanan, dan penerima siaran, penyedia konten diaktifkan saat ditargetkan oleh permintaan dari ContentResolver. Resolver konten menangani semua transaksi langsung dengan penyedia konten, dan komponen yang melakukan transaksi dengan penyedia yang memanggil metode pada objek ContentResolver. Hal ini meninggalkan lapisan abstraksi karena alasan keamanan antara penyedia konten dan komponen yang meminta informasi.

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

  • Anda dapat memulai suatu aktivitas atau memberinya tugas baru dengan meneruskan Intent ke startActivity() atau, saat Anda ingin aktivitas menampilkan hasil, startActivityForResult().
  • Di Android 5.0 (API level 21) dan yang lebih tinggi, Anda dapat menggunakan class JobScheduler untuk menjadwalkan tindakan. Untuk versi Android sebelumnya, Anda dapat memulai layanan atau memberikan instruksi baru ke layanan yang sedang berlangsung dengan meneruskan Intent ke startService(). Anda dapat mengikat ke layanan dengan meneruskan Intent ke bindService().
  • Anda dapat memulai siaran dengan meneruskan Intent ke metode seperti sendBroadcast() atau sendOrderedBroadcast().
  • Anda dapat membuat kueri ke penyedia konten dengan memanggil query() di ContentResolver.

Untuk informasi selengkapnya tentang penggunaan intent, lihat dokumen Intent dan Filter Intent. Dokumen berikut memberikan informasi selengkapnya tentang cara mengaktifkan komponen tertentu: Pengantar aktivitas, Ringkasan layanan, BroadcastReceiver, dan Penyedia konten.

File manifes

Sebelum sistem Android dapat memulai komponen aplikasi, sistem harus mengetahui bahwa komponen itu ada dengan membaca file manifes aplikasi, AndroidManifest.xml. Aplikasi Anda mendeklarasikan semua komponennya dalam file ini, yang berada di root direktori project aplikasi.

Manifes melakukan banyak hal selain mendeklarasikan komponen aplikasi, seperti 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 hardware dan software yang digunakan atau diperlukan oleh aplikasi, seperti kamera, layanan Bluetooth, atau layar multisentuh.
  • Mendeklarasikan library API yang perlu ditautkan dengan aplikasi (selain API framework Android), seperti library Google Maps.

Mendeklarasikan komponen

Tugas utama manifes adalah menginformasikan komponen aplikasi ke sistem. Misalnya, file manifes dapat 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 resource untuk ikon yang mengidentifikasi aplikasi.

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

Anda harus mendeklarasikan semua komponen aplikasi menggunakan elemen berikut:

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

Untuk informasi selengkapnya tentang cara membuat struktur file manifes untuk aplikasi, lihat Ringkasan manifes aplikasi.

Mendeklarasikan kemampuan komponen

Seperti yang dibahas di bagian Mengaktifkan komponen, Anda dapat menggunakan Intent untuk memulai aktivitas, layanan, dan penerima siaran. Anda melakukannya dengan menamai komponen target secara eksplisit, menggunakan nama class komponen, dalam intent. Anda juga dapat menggunakan intent implisit, yang menjelaskan jenis tindakan yang akan dilakukan dan, secara opsional, data yang ingin Anda lakukan. Intent implisit memungkinkan sistem menemukan komponen pada perangkat yang dapat melakukan tindakan dan memulainya. Jika ada beberapa komponen yang dapat melakukan tindakan yang dijelaskan oleh intent, pengguna dapat memilih komponen yang akan digunakan.

Perhatian: Jika Anda menggunakan intent untuk memulai Service, pastikan aplikasi Anda aman dengan menggunakan intent eksplisit. Menggunakan intent implisit untuk memulai layanan dapat membahayakan keamanan, karena Anda tidak dapat memastikan layanan yang merespons intent dan pengguna tidak dapat melihat layanan mana yang dimulai. Mulai dari Android 5.0 (API level 21), sistem menampilkan pengecualian jika Anda memanggil bindService() dengan intent implisit. Jangan mendeklarasikan filter intent untuk layanan Anda.

Sistem mengidentifikasi komponen yang dapat merespons intent dengan membandingkan intent yang diterima dengan filter intent yang disediakan dalam file manifes aplikasi lain di perangkat.

Saat mendeklarasikan aktivitas dalam manifes aplikasi, Anda dapat secara opsional menyertakan filter intent yang mendeklarasikan kemampuan aktivitas agar dapat merespons intent dari aplikasi lain. Anda dapat melakukannya dengan menambahkan elemen <intent-filter> sebagai turunan dari elemen deklarasi komponen.

Misalnya, jika mem-build aplikasi email dengan aktivitas untuk menulis email baru, Anda dapat mendeklarasikan filter intent untuk merespons intent "kirim" guna mengirim email baru, seperti yang ditunjukkan pada 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>

Jika aplikasi lain membuat intent dengan tindakan ACTION_SEND dan meneruskannya ke startActivity(), sistem mungkin akan memulai aktivitas Anda agar pengguna dapat membuat draf dan mengirim email.

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

Mendeklarasikan persyaratan aplikasi

Ada berbagai perangkat yang didukung oleh Android, dan tidak semuanya menyediakan fitur dan kemampuan yang sama. Untuk mencegah aplikasi Anda diinstal di perangkat yang tidak memiliki fitur yang diperlukan oleh aplikasi Anda, Anda harus menentukan secara jelas profil untuk jenis perangkat yang didukung aplikasi Anda dengan mendeklarasikan persyaratan perangkat dan software dalam file manifes.

Sebagian besar deklarasi ini hanya bersifat informatif. Sistem tidak membacanya, tetapi layanan eksternal seperti Google Play akan membacanya untuk memberikan pemfilteran bagi pengguna saat mereka menelusuri aplikasi dari perangkat.

Misalnya, anggaplah aplikasi Anda memerlukan kamera dan menggunakan API yang diperkenalkan di Android 8.0 (API level 26). Anda harus menyatakan persyaratan ini. Nilai untuk minSdkVersion dan targetSdkVersion ditetapkan dalam file build.gradle modul aplikasi Anda:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

Catatan: Jangan tetapkan minSdkVersion dan targetSdkVersion secara langsung dalam file manifes, karena keduanya ditimpa oleh Gradle selama proses build. Untuk mengetahui informasi selengkapnya, lihat Menentukan persyaratan API level.

Anda mendeklarasikan fitur kamera dalam file manifes aplikasi:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

Dengan deklarasi yang ditampilkan dalam contoh ini, perangkat yang tidak memiliki kamera atau memiliki versi Android yang lebih rendah dari 8.0 tidak dapat menginstal aplikasi Anda dari Google Play. Namun, Anda juga dapat mendeklarasikan bahwa aplikasi Anda menggunakan kamera, tetapi tidak memerlukannya. Untuk melakukannya, tetapkan atribut required ke false, periksa pada runtime apakah perangkat memiliki kamera, dan nonaktifkan fitur kamera sesuai kebutuhan.

Informasi selengkapnya tentang cara mengelola kompatibilitas aplikasi dengan berbagai perangkat disediakan dalam Ringkasan kompatibilitas perangkat.

Resource aplikasi

Aplikasi Android tidak hanya terdiri dari kode. Class ini memerlukan resource yang terpisah dari kode sumber, seperti gambar, file audio, dan apa pun yang berkaitan dengan presentasi visual aplikasi. Misalnya, Anda dapat menentukan animasi, menu, gaya, warna, dan tata letak antarmuka pengguna aktivitas dengan file XML.

Penggunaan resource aplikasi memudahkan pembaruan berbagai karakteristik aplikasi tanpa mengubah kode. Menyediakan serangkaian resource alternatif memungkinkan Anda mengoptimalkan aplikasi untuk berbagai konfigurasi perangkat, seperti berbagai bahasa dan ukuran layar.

Untuk setiap resource yang disertakan dalam project Android, alat build SDK akan menentukan ID bilangan bulat unik, yang dapat digunakan untuk mereferensikan resource dari kode aplikasi Anda atau dari resource lain yang ditentukan dalam XML. Misalnya, jika aplikasi Anda berisi file gambar bernama logo.png (disimpan di direktori res/drawable/), SDK Tools akan menghasilkan ID resource bernama R.drawable.logo. ID ini dipetakan ke bilangan bulat khusus aplikasi, yang dapat Anda gunakan untuk mereferensikan gambar dan memasukkannya dalam antarmuka pengguna.

Salah satu aspek terpenting dalam menyediakan resource yang terpisah dari kode sumber adalah kemampuan untuk menyediakan resource alternatif untuk konfigurasi perangkat yang berbeda.

Misalnya, dengan menentukan string UI dalam XML, Anda dapat menerjemahkan string ke dalam bahasa lain dan menyimpan string tersebut dalam file terpisah. Kemudian Android akan menerapkan string bahasa yang sesuai ke UI Anda berdasarkan penentu bahasa yang Anda tambahkan ke nama direktori resource, seperti res/values-fr/ untuk nilai string Prancis, dan setelan bahasa pengguna.

Android mendukung banyak penentu untuk resource alternatif Anda. Penentu adalah string pendek yang Anda sertakan dalam nama direktori resource untuk menentukan konfigurasi perangkat yang digunakan resource tersebut.

Misalnya, Anda dapat membuat tata letak berbeda untuk aktivitas, bergantung pada orientasi layar dan ukuran perangkat. Saat layar perangkat dalam orientasi potret (tinggi), Anda mungkin ingin tata letak dengan tombol disusun secara vertikal, tetapi saat layar dalam orientasi lanskap (lebar), Anda mungkin ingin tombol disejajarkan secara horizontal. Untuk mengubah tata letak bergantung pada orientasi, Anda dapat menentukan dua tata letak dan menerapkan pengontrol kualitas yang sesuai ke setiap nama direktori tata letak. Kemudian, sistem secara otomatis akan menerapkan tata letak yang sesuai berdasarkan orientasi perangkat saat ini.

Untuk mengetahui informasi selengkapnya tentang berbagai jenis resource yang dapat Anda sertakan dalam aplikasi, dan cara membuat resource alternatif untuk konfigurasi perangkat yang berbeda, baca Ringkasan resource aplikasi. Untuk mempelajari lebih lanjut praktik terbaik dan mendesain aplikasi yang tangguh dan berkualitas produksi, lihat Panduan arsitektur aplikasi.

Referensi lainnya

Untuk mempelajari pengembangan Android menggunakan video dan tutorial kode, lihat kursus Mengembangkan Aplikasi Android dengan Kotlin.

Lanjutkan membaca tentang:

Intent dan Filter Intent
Pelajari cara menggunakan Intent API untuk mengaktifkan komponen aplikasi, seperti aktivitas dan layanan, dan cara menyediakan komponen aplikasi untuk digunakan oleh aplikasi lain.
Pengantar aktivitas
Pelajari cara membuat instance class Activity, yang menyediakan layar tersendiri dengan antarmuka pengguna di aplikasi Anda.
Ringkasan resource aplikasi
Pelajari cara aplikasi Android disusun untuk memisahkan resource aplikasi dari kode aplikasi, termasuk cara menyediakan resource alternatif untuk konfigurasi perangkat tertentu.

Yang juga menarik:

Ringkasan kompatibilitas perangkat
Pelajari cara kerja Android di berbagai jenis perangkat dan cara mengoptimalkan aplikasi untuk setiap perangkat atau membatasi ketersediaan aplikasi Anda untuk perangkat lain.
Izin di Android
Pelajari cara Android membatasi akses aplikasi ke API tertentu dengan sistem izin yang mengharuskan persetujuan pengguna agar aplikasi dapat menggunakan API tersebut.