Dasar-dasar aplikasi

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Aplikasi Android dapat ditulis menggunakan Kotlin, bahasa pemrograman Java, dan bahasa C++. Kompilasi Android SDK Tools kode Anda beserta file data dan resource ke dalam APK atau Android App Bundle.

Paket Android, yang merupakan file arsip dengan akhiran .apk, berisi konten aplikasi Android yang diperlukan pada runtime, dan itu adalah file yang didukung oleh Android yang digunakan perangkat untuk menginstal aplikasi.

Android App Bundle, yang merupakan file arsip dengan akhiran .aab, berisi isi project aplikasi Android, termasuk beberapa metadata tambahan yang tidak diperlukan di waktu beroperasi. AAB adalah format publikasi dan tidak dapat diinstal di perangkat Android. Ini menangguhkan pembuatan dan penandatanganan APK ke tahap berikutnya.

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

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

• Sistem operasi Android adalah sistem Linux multi-pengguna di mana 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 akses untuk semua file dalam aplikasi sehingga hanya ID pengguna yang ditetapkan untuk 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 ketika ada komponen aplikasi perlu dijalankan, dan kemudian mematikan proses saat tidak lagi diperlukan atau ketika sistem harus memulihkan memori untuk aplikasi lain.

Sistem Android menerapkan prinsip hak istimewa terendah. Yaitu, setiap aplikasi, secara {i>default<i}, hanya memiliki akses ke komponen yang diperlukannya untuk melakukan pekerjaannya dan tidak lagi. Hal ini menciptakan lingkungan yang sangat aman di mana aplikasi tidak dapat mengakses bagian dari sistem yang tidak diberi izin.

Namun, ada cara bagi aplikasi untuk berbagi dengan aplikasi lain dan untuk aplikasi Anda untuk mengakses layanan sistem:

• Dua aplikasi dapat diatur untuk menggunakan ID pengguna Linux yang sama, dalam hal ini mereka dapat saling mengakses file. Untuk menghemat sumber daya sistem, aplikasi dengan ID pengguna yang sama juga dapat diatur untuk dijalankan di proses Linux yang sama dan menggunakan VM yang sama. Tujuan aplikasi juga harus ditandatangani menggunakan sertifikat yang sama.
• Aplikasi dapat meminta izin untuk mengakses data perangkat seperti data lokasi, kamera, dan koneksi Bluetooth. Pengguna memiliki untuk memberikan izin ini secara eksplisit. Untuk 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 perangkat yang diperlukan untuk aplikasi Anda .
• Resource yang terpisah dari kode aplikasi dan memungkinkan aplikasi mengoptimalkan perilakunya dengan baik untuk berbagai konfigurasi perangkat.

Komponen aplikasi

Komponen aplikasi adalah elemen penyusun penting aplikasi Android. Masing-masing adalah titik masuk tempat sistem atau pengguna dapat memasuki aplikasi Anda. Agak besar komponennya bergantung pada yang lain.

Ada empat jenis komponen aplikasi:

• Aktivitas
• Layanan
• Penerima siaran
• Penyedia konten

Setiap jenis memiliki tujuan yang berbeda dan memiliki siklus proses berbeda yang menentukan bagaimana sebuah komponen dibuat dan dihancurkan. Bagian berikut menguraikan empat tipe komponen aplikasi.

Aktivitas

Aktivitas adalah titik entri untuk berinteraksi dengan pengguna. Objek ini mewakili satu layar dengan antarmuka pengguna. Misalnya, aplikasi email mungkin memiliki satu aktivitas yang menampilkan daftar email, aktivitas lain untuk menulis email, dan aktivitas lain untuk membaca email. Meskipun aktivitas bekerja sama untuk membentuk pengalaman pengguna yang kohesif dalam aplikasi email, masing-masing terpisah dari yang lain.

Aplikasi lain dapat memulai aktivitas lain jika aplikasi email mengizinkannya. Misalnya, aplikasi kamera mungkin memulai di aplikasi email untuk menulis email baru yang memungkinkan pengguna berbagi gambar.

Aktivitas mempermudah interaksi penting berikut di antara sistem dan aplikasi:

• Melacak apa yang saat ini diminati pengguna—apa yang ada di layar—sehingga sistem tetap menjalankan proses yang menjadi {i>host<i} aktivitas.
• Mengetahui proses mana yang sebelumnya digunakan berisi aktivitas yang mungkin kembali dilakukan pengguna dan memprioritaskan proses tersebut agar dapat terus berjalan.
• Membantu aplikasi menangani proses yang dihentikan sehingga pengguna dapat kembali ke aktivitas dengan status sebelumnya yang dipulihkan.
• Menyediakan cara bagi aplikasi untuk mengimplementasikan alur pengguna di antara satu sama lain, dan bagi sistem untuk mengkoordinasikan alur-alur ini. Contoh utamanya adalah berbagi.

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

Layanan

Layanan adalah titik entri tujuan umum untuk menjaga aplikasi tetap berjalan di latar belakang untuk berbagai alasan. Ini adalah komponen yang berjalan di latar belakang untuk melakukan operasi atau melakukan pekerjaan untuk proses jarak jauh. Layanan tidak menyediakan antarmuka pengguna.

Sebagai layanan mungkin memutar musik di latar belakang saat pengguna berada dalam aplikasi lain, atau perangkat itu mungkin mengambil data melalui jaringan tanpa memblokir interaksi pengguna dengan suatu aktivitas. Lainnya dasar, seperti aktivitas, bisa memulai layanan dan membiarkannya berjalan atau mengikatnya ke berinteraksi dengannya.

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

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

• Pemutaran musik adalah sesuatu yang secara langsung diketahui pengguna, dan aplikasi menyampaikan hal ini kepada sistem dengan menunjukkan bahwa sistem ingin berada di latar depan, dengan notifikasi untuk memberi tahu pengguna yang menjalankannya. Dalam hal ini, sistem memprioritaskan menjaga agar akses pengguna proses sedang berjalan, karena pengguna memiliki pengalaman buruk jika proses itu pergi.
• Layanan latar belakang reguler bukanlah sesuatu yang langsung disadari pengguna, jadi sistem memiliki lebih banyak kebebasan dalam mengelola prosesnya. Mungkin membiarkannya terbunuh, memulai ulang layanan nanti, jika layanan membutuhkan RAM untuk hal-hal yang lebih kekhawatiran langsung kepada pengguna.

Layanan terikat berjalan karena beberapa aplikasi lain (atau sistem) telah mengatakan bahwa aplikasi tersebut ingin menggunakan layanan. Layanan terikat menyediakan API untuk proses lain, sedangkan sistem mengetahui ada ketergantungan antara proses-proses ini. Jadi jika proses A terikat ke layanan di proses B, sistem tahu bahwa ia perlu menjaga proses B dan layanannya tetap berjalan untuk A. Lebih lanjut, jika proses A adalah sesuatu yang penting bagi pengguna, kemudian ia tahu untuk memperlakukan proses B sebagai sesuatu menjadi perhatian pengguna.

Karena fleksibilitasnya, layanan berguna fondasi untuk semua jenis konsep sistem di level yang lebih tinggi. Wallpaper animasi, notifikasi pemroses, screensaver, metode input, layanan aksesibilitas, dan banyak fitur sistem inti lainnya semuanya dibangun sebagai layanan yang diterapkan aplikasi dan terikat sistem saat dijalankan.

Layanan diterapkan sebagai subclass dari Service. Untuk informasi lebih lanjut tentang class Service, lihat class 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 memanfaatkan penghematan baterai dengan menjadwalkan tugas secara optimal untuk mengurangi konsumsi daya dan menggunakan Doze API. Untuk informasi selengkapnya tentang penggunaan class ini, lihat JobScheduler dokumentasi referensi.

Penerima siaran

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

Jadi, misalnya, sebuah aplikasi bisa menjadwalkan alarm untuk memposting notifikasi guna memberi tahu pengguna tentang acara yang akan datang. Karena alarm dikirimkan ke BroadcastReceiver di aplikasi, aplikasi tidak perlu tetap berjalan hingga alarm berbunyi.

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

Meskipun disiarkan penerima tidak menampilkan antarmuka pengguna, mereka dapat membuat notifikasi status bar untuk memberi tahu pengguna ketika ada peristiwa siaran. Namun, penerima siaran umumnya hanya sebagai gateway untuk komponen lain dan dimaksudkan untuk melakukan pekerjaan dalam jumlah yang sangat minimal.

Misalnya, penerima siaran dapat menjadwalkan JobService untuk melakukan beberapa pekerjaan berbasis pada peristiwa menggunakan JobScheduler. Penerima siaran sering kali melibatkan aplikasi yang berinteraksi satu sama lain, jadi penting untuk implikasi keamanan saat menyiapkannya.

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

Penyedia konten

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

Misalnya, sistem Android menyediakan konten yang mengelola informasi kontak pengguna. Aplikasi apa pun dengan dapat mengkueri penyedia materi, seperti menggunakan ContactsContract.Data, untuk membaca dan menulis informasi tentang orang tertentu.

Anda tergoda untuk menganggap penyedia konten sebagai abstraksi pada database, karena ada banyak API dan dukungan bawaan untuk mereka untuk kasus umum itu. Namun, keduanya memiliki tujuan inti 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 bisa memutuskan bagaimana ia ingin memetakan data di dalamnya ke Namespace URI, yang membagikan URI tersebut ke entity lain yang dapat menggunakannya untuk mengakses layanan otomatis dan data skalabel. Ada beberapa hal tertentu yang memungkinkan sistem lakukan dalam mengelola aplikasi:

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

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

Penyedia konten diterapkan sebagai subclass dari ContentProvider dan harus mengimplementasikan satu set API standar yang memungkinkan aplikasi lain melakukan transaksi. Untuk informasi selengkapnya, lihat developer Penyedia konten kami.

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

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

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

Aktifkan 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 bisa menganggap mereka sebagai pengirim yang meminta tindakan dari komponen lain, apakah komponen tersebut ke aplikasi Anda atau lainnya.

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

Untuk aktivitas dan layanan, intent mendefinisikan tindakan yang akan dilakukan, seperti view atau mengirim sesuatu, dan mungkin menentukan URI data yang akan ditindaklanjuti, antara lain yang mungkin perlu diketahui.

Misalnya, intent mungkin menyampaikan permintaan untuk aktivitas untuk menampilkan gambar atau membuka halaman web. Dalam beberapa kasus, Anda dapat memulai untuk menerima hasil, dalam hal ini aktivitas juga akan kembali hasilnya dalam Intent. Anda juga bisa mengeluarkan {i>intent<i} untuk memungkinkan pengguna memilih kontak pribadi dan memintanya mengembalikannya kepada Anda. Intent yang ditampilkan menyertakan URI yang mengarah ke kontak yang dipilih.

Untuk penerima siaran, intent mendefinisikan pengumuman siaran. Misalnya, siaran untuk menunjukkan bahwa baterai perangkat lemah hanya menyertakan string tindakan yang diketahui yang menunjukkan baterai lemah.

Tidak seperti aktivitas, layanan, dan penerima siaran, penyedia konten diaktifkan saat ditargetkan oleh permintaan dari ContentResolver. Konten resolver menangani semua transaksi langsung dengan penyedia konten, dan komponen melakukan transaksi dengan metode panggilan penyedia itu 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 aktivitas atau memberikan sesuatu yang baru untuk dilakukan dengan meneruskan Intent ke startActivity() atau, bila Anda ingin aktivitas mengembalikan hasil, startActivityForResult().
• Pada Android 5.0 (API level 21) dan yang lebih tinggi, Anda dapat menggunakan class JobScheduler untuk menjadwalkan tindakan. Untuk versi Android sebelumnya, Anda dapat mulai layanan atau memberikan instruksi baru ke layanan berkelanjutan 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 bisa melakukan kueri ke penyedia konten dengan memanggil query() di ContentResolver.

Untuk informasi selengkapnya tentang penggunaan intent, lihat Intent dan Dokumen 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 dibuat 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 nilai minimum Level API yang diperlukan aplikasi, berdasarkan API yang digunakan aplikasi.
• Mendeklarasikan fitur hardware dan software yang digunakan atau diperlukan aplikasi, seperti kamera, Layanan Bluetooth, atau layar multisentuh.
• Mendeklarasikan library API yang harus ditautkan ke aplikasi (selain framework Android API), seperti library Google Maps.

Mendeklarasikan komponen

Tugas utama manifes adalah menginformasikan sistem tentang komponen aplikasi. Sebagai 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>

Di <application> , atribut android:icon menunjuk ke resource untuk ikon yang mengidentifikasi .

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

Anda harus mendeklarasikan semua komponen aplikasi menggunakan elemen berikut:

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

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

Untuk mengetahui informasi selengkapnya tentang cara menyusun file manifes untuk aplikasi Anda, lihat Ringkasan manifes aplikasi.

Mendeklarasikan kemampuan komponen

Seperti yang dibahas di bagian Aktifkan komponen, Anda dapat menggunakan Intent untuk memulai aktivitas, layanan, dan penerima siaran. Anda yang harus melakukannya dengan menamai komponen target secara eksplisit, menggunakan nama class komponen, dalam intent. Anda juga bisa menggunakan intent implisit, yang menjelaskan jenis tindakan yang akan dilakukan dan, secara opsional, data yang ingin untuk melakukan tindakan tersebut. 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 , pengguna memilih mana yang akan digunakan.

Perhatian: Jika Anda menggunakan intent untuk memulai Service, pastikan aplikasi Anda aman dengan menggunakan eksplisit intent. Menggunakan maksud implisit untuk memulai layanan adalah bahaya keamanan, karena Anda tidak bisa memastikan layanan apa yang merespons intent tersebut 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 ke filter intent yang disediakan dalam file manifes aplikasi lain di perangkat.

Bila mendeklarasikan aktivitas dalam manifes aplikasi, Anda bisa menyertakan secara opsional filter intent yang mendeklarasikan kemampuan aktivitas sehingga dapat merespons intent dari aplikasi lain. Anda melakukan ini dengan menambahkan elemen <intent-filter> sebagai turunan dari elemen deklarasi komponen.

Misalnya, jika Anda membuat aplikasi email dengan aktivitas untuk menulis email baru, Anda dapat mendeklarasikan filter intent untuk merespons "send" untuk mengirim email baru, seperti yang ditunjukkan dalam 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 memulai aktivitas Anda sehingga pengguna dapat membuat draf dan mengirimkan email Anda.

Untuk informasi selengkapnya tentang cara 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 kekurangan fitur yang dibutuhkan oleh aplikasi Anda, penting bagi Anda untuk mendefinisikan profil dengan jelas jenis perangkat yang didukung aplikasi Anda dengan mendeklarasikan persyaratan perangkat dan software di manifes.

Sebagian besar deklarasi ini hanya bersifat informasi. Sistem tidak membaca tetapi layanan eksternal seperti Google Play membacanya untuk memberikan pemfilteran bagi pengguna saat 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 akan ditimpa oleh Gradle selama proses build. Untuk 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, setel required ke false, periksa saat runtime apakah perangkat memiliki kamera, dan menonaktifkan fitur kamera sesuai kebutuhan.

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

Resource aplikasi

Aplikasi Android tersusun lebih dari sekadar kode. Sistem ini membutuhkan sumber daya yang terpisah dari kode sumber, seperti gambar, file audio, dan apa pun yang berkaitan dengan presentasi aplikasi. Misalnya, Anda dapat mendefinisikan animasi, menu, gaya, warna, dan tata letak antarmuka pengguna aktivitas dengan file XML.

Menggunakan resource aplikasi akan memudahkan untuk mengupdate berbagai karakteristik aplikasi tanpa memodifikasi kode. Menyediakan yang dapat Anda gunakan untuk mengoptimalkan aplikasi untuk berbagai konfigurasi perangkat Anda, seperti berbagai bahasa dan ukuran layar.

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

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

Misalnya, dengan mendefinisikan string UI dalam XML, Anda bisa menerjemahkan {i>string<i} ke dalam bahasa dan menyimpan {i>string<i} tersebut dalam file terpisah. Kemudian Android menerapkan string bahasa yang sesuai ke UI berdasarkan penentu bahasa yang Anda tambahkan ke nama direktori resource, seperti res/values-fr/ untuk string bahasa Prancis nilai, dan setelan bahasa pengguna.

Android mendukung banyak penentu untuk resource alternatif Anda. Tujuan adalah string pendek yang Anda sertakan dalam nama direktori sumber daya untuk menetapkan konfigurasi perangkat yang menggunakan sumber daya tersebut.

Sebagai misalnya, Anda dapat membuat tata letak yang berbeda untuk aktivitas bergantung pada orientasi layar dan ukuran perangkat. Saat layar perangkat dalam mode potret (tinggi) orientasi, Anda mungkin ingin tata letak dengan tombol yang disusun secara vertikal, tetapi saat layar berada orientasi lanskap (lebar), Anda mungkin ingin tombol disejajarkan secara horizontal. Untuk mengubah tata letak tergantung pada orientasinya, Anda bisa mendefinisikan dua tata letak dan menerapkan untuk setiap nama direktori tata letak. Kemudian, sistem secara otomatis menerapkan tata letak yang berbeda tergantung pada orientasi perangkat saat ini.

Untuk informasi selengkapnya tentang berbagai jenis sumber daya yang dapat Anda sertakan dalam aplikasi dan cara Membuat resource alternatif untuk berbagai konfigurasi perangkat, baca Ringkasan resource aplikasi. Kepada 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 Mengembangkan Aplikasi Android dengan Kotlin Kaggle.