API Android 4.0

Level API: 14

Android 4.0 (ICE_CREAM_SANDWICH) adalah rilis platform utama yang menambahkan berbagai fitur baru bagi pengguna dan developer aplikasi. Selain semua fitur dan API baru yang dibahas di bawah ini, Android 4.0 merupakan rilis platform yang penting karena menghadirkan sekumpulan API dan tema Holografik yang lengkap dari Android 3.x ke layar yang lebih kecil. Sebagai developer aplikasi, Anda kini memiliki satu platform dan framework API terpadu yang memungkinkan Anda mengembangkan dan memublikasikan aplikasi dengan satu APK yang memberikan pengalaman pengguna yang dioptimalkan untuk handset, tablet, dan perangkat lainnya, saat menjalankan versi Android yang sama—Android 4.0 (API level 14) atau yang lebih baru.

Untuk developer, platform Android 4.0 tersedia sebagai komponen yang dapat didownload untuk Android SDK. Platform yang dapat didownload mencakup library Android dan image sistem, serta sekumpulan skin emulator dan banyak lagi. Untuk mulai mengembangkan atau menguji Android 4.0, gunakan Android SDK Manager untuk mendownload platform ke SDK Anda.

Ringkasan API

Bagian di bawah ini menyediakan ringkasan teknis tentang API baru di Android 4.0.

API Sosial di Penyedia Kontak

API kontak yang ditentukan oleh penyedia ContactsContract telah diperluas untuk mendukung fitur berorientasi sosial baru seperti profil pribadi bagi pemilik perangkat dan kemampuan bagi pengguna untuk mengundang setiap kontak ke jaringan sosial yang diinstal di perangkat.

Profil Pengguna

Android kini menyertakan profil pribadi yang mewakili pemilik perangkat, seperti yang ditentukan oleh tabel ContactsContract.Profile. Aplikasi sosial yang mempertahankan identitas pengguna dapat berkontribusi pada data profil pengguna dengan membuat entri ContactsContract.RawContacts baru dalam ContactsContract.Profile. Artinya, kontak mentah yang mewakili pengguna perangkat tidak termasuk dalam tabel kontak mentah tradisional yang ditentukan oleh URI ContactsContract.RawContacts; sebagai gantinya, Anda harus menambahkan kontak mentah profil pada tabel di CONTENT_RAW_CONTACTS_URI. Kontak mentah dalam tabel ini kemudian digabungkan ke dalam satu profil yang terlihat oleh pengguna berlabel "Saya".

Menambahkan kontak mentah baru untuk profil memerlukan izin android.Manifest.permission#WRITE_PROFILE. Demikian pula, untuk membaca dari tabel profil, Anda harus meminta izin android.Manifest.permission#READ_PROFILE. Namun, sebagian besar aplikasi tidak perlu membaca profil pengguna, bahkan saat memberikan data ke profil. Membaca profil pengguna adalah izin yang sensitif dan Anda harus mengharapkan pengguna untuk skeptis terhadap aplikasi yang memintanya.

Undang Intent

Tindakan intent INVITE_CONTACT memungkinkan aplikasi memanggil tindakan yang menunjukkan bahwa pengguna ingin menambahkan kontak ke jaringan sosial. Aplikasi yang menerima aplikasi akan menggunakannya untuk mengundang kontak tertentu ke jaringan sosial tersebut. Sebagian besar aplikasi akan berada di pihak penerima operasi ini. Misalnya, aplikasi Orang bawaan akan memanggil intent undangan saat pengguna memilih "Tambahkan koneksi" untuk aplikasi sosial tertentu yang tercantum dalam detail kontak seseorang.

Agar aplikasi terlihat seperti dalam daftar "Tambahkan koneksi", aplikasi harus menyediakan adaptor sinkronisasi untuk menyinkronkan informasi kontak dari jaringan sosial Anda. Kemudian, Anda harus menunjukkan kepada sistem bahwa aplikasi Anda merespons intent INVITE_CONTACT dengan menambahkan atribut inviteContactActivity ke file konfigurasi sinkronisasi aplikasi, dengan nama aktivitas yang sepenuhnya memenuhi syarat dan harus dimulai oleh sistem saat mengirim intent undangan. Aktivitas yang dimulai kemudian dapat mengambil URI untuk kontak yang dimaksud dari data intent dan melakukan pekerjaan yang diperlukan untuk mengundang kontak tersebut ke jaringan atau menambahkan orang tersebut ke koneksi pengguna.

Foto besar

Android kini mendukung foto resolusi tinggi untuk kontak. Sekarang, saat Anda memasukkan foto ke catatan kontak, sistem akan memprosesnya menjadi thumbnail 96x96 (seperti sebelumnya) dan "foto tampilan" 256x256 yang disimpan di penyimpanan foto berbasis file baru (dimensi persis yang dipilih sistem dapat bervariasi di masa mendatang). Anda dapat menambahkan foto besar ke kontak dengan menempatkan foto besar di kolom PHOTO biasa pada baris data, yang kemudian akan diproses oleh sistem menjadi thumbnail dan rekaman foto tampilan yang sesuai.

Masukan Kontak terkait Penggunaan

ContactsContract.DataUsageFeedback API baru memungkinkan Anda melacak seberapa sering pengguna menggunakan metode tertentu untuk menghubungi orang, seperti seberapa sering pengguna menggunakan setiap nomor telepon atau alamat email. Informasi ini membantu meningkatkan peringkat untuk setiap metode kontak yang terkait dengan setiap orang dan memberikan saran yang lebih baik untuk menghubungi setiap orang.

Penyedia Kalender

API kalender baru memungkinkan Anda membaca, menambahkan, mengubah, dan menghapus kalender, acara, tamu, pengingat, dan pemberitahuan, yang disimpan di Penyedia Kalender.

Berbagai aplikasi dan widget dapat menggunakan API ini untuk membaca dan memodifikasi acara kalender. Namun, beberapa kasus penggunaan yang paling menarik adalah adaptor sinkronisasi yang menyinkronkan kalender pengguna dari layanan kalender lain dengan Penyedia Kalender, dengan tujuan menawarkan lokasi terpadu untuk semua acara pengguna. Acara Google Kalender, misalnya, disinkronkan dengan Penyedia Kalender oleh Adaptor Sinkronisasi Google Kalender, sehingga acara ini dapat dilihat dengan aplikasi Kalender bawaan Android.

Model data untuk kalender dan informasi terkait acara di Penyedia Kalender ditentukan oleh CalendarContract. Semua data kalender pengguna disimpan dalam sejumlah tabel yang ditentukan oleh berbagai subclass CalendarContract:

  • Tabel CalendarContract.Calendars menyimpan informasi khusus kalender. Setiap baris dalam tabel ini berisi detail untuk satu kalender, seperti nama, warna, informasi sinkronisasi, dan sebagainya.
  • Tabel CalendarContract.Events menyimpan informasi khusus peristiwa. Setiap baris dalam tabel ini berisi informasi untuk satu acara, seperti judul acara, lokasi, waktu mulai, waktu berakhir, dan sebagainya. Peristiwa ini dapat terjadi satu kali atau berulang beberapa kali. Peserta, pengingat, dan properti perluasan disimpan dalam tabel terpisah dan menggunakan _ID acara untuk menautkannya dengan acara.
  • Tabel CalendarContract.Instances menyimpan waktu mulai dan berakhir untuk kemunculan suatu peristiwa. Setiap baris dalam tabel ini mewakili satu kemunculan. Untuk peristiwa satu kali, ada pemetaan one-to-one antara instance dan peristiwa. Untuk peristiwa berulang, beberapa baris akan otomatis dibuat agar sesuai dengan beberapa kejadian tersebut.
  • Tabel CalendarContract.Attendees menyimpan informasi tamu atau tamu acara. Tiap baris mewakili satu tamu kejadian. Ini menentukan jenis tamu dan responsnya untuk acara tersebut.
  • Tabel CalendarContract.Reminders menyimpan data pemberitahuan/notifikasi. Tiap baris mewakili satu peringatan untuk sebuah kejadian. Sebuah kejadian bisa memiliki beberapa pengingat. Jumlah pengingat per acara ditentukan dalam MAX_REMINDERS, yang disetel oleh adaptor sinkronisasi yang memiliki kalender yang ditentukan. Pengingat ditentukan dalam jumlah menit sebelum acara dijadwalkan dan menentukan metode alarm seperti menggunakan pemberitahuan, email, atau SMS untuk mengingatkan pengguna.
  • Tabel CalendarContract.ExtendedProperties menyimpan kolom data buram yang digunakan oleh adaptor sinkronisasi. Penyedia tidak melakukan tindakan apa pun terhadap item dalam tabel ini, kecuali menghapusnya saat peristiwa terkaitnya dihapus.

Untuk mengakses data kalender pengguna dengan Penyedia Kalender, aplikasi Anda harus meminta izin READ_CALENDAR (untuk akses baca) dan WRITE_CALENDAR (untuk akses tulis).

Niat peristiwa

Jika yang ingin dilakukan hanyalah menambahkan acara ke kalender pengguna, Anda dapat menggunakan intent ACTION_INSERT dengan data yang ditentukan oleh Events.CONTENT_URI untuk memulai aktivitas di aplikasi Kalender yang membuat acara baru. Penggunaan intent ini tidak memerlukan izin dan Anda dapat menentukan detail peristiwa dengan tambahan berikut:

Penyedia Pesan Suara

Penyedia Pesan Suara baru memungkinkan aplikasi menambahkan pesan suara ke perangkat, untuk menampilkan semua pesan suara pengguna dalam satu presentasi visual. Misalnya, ada kemungkinan pengguna memiliki beberapa sumber pesan suara, seperti sumber dari penyedia layanan ponsel dan sumber lainnya dari VoIP atau layanan suara alternatif lainnya. Aplikasi ini dapat menggunakan API Penyedia Pesan Suara untuk menambahkan pesan suara ke perangkat. Selanjutnya, aplikasi Telepon bawaan akan menyajikan semua pesan suara kepada pengguna dalam presentasi terpadu. Meskipun aplikasi Telepon sistem adalah satu-satunya aplikasi yang dapat membaca semua pesan suara, setiap aplikasi yang menyediakan pesan suara dapat membaca pesan suara yang telah ditambahkan ke sistem (tetapi tidak dapat membaca pesan suara dari layanan lain).

Karena API saat ini tidak mengizinkan aplikasi pihak ketiga membaca semua pesan suara dari sistem, satu-satunya aplikasi pihak ketiga yang harus menggunakan API pesan suara adalah aplikasi yang memiliki pesan suara untuk dikirimkan kepada pengguna.

Class VoicemailContract menentukan penyedia konten untuk Penyedia Pesan Suara. Subclass VoicemailContract.Voicemails dan VoicemailContract.Status menyediakan tabel tempat aplikasi dapat menyisipkan data pesan suara untuk penyimpanan di perangkat. Untuk contoh aplikasi penyedia pesan suara, lihat Demo Penyedia Pesan Suara.

Multimedia

Android 4.0 menambahkan beberapa API baru untuk aplikasi yang berinteraksi dengan media seperti foto, video, dan musik.

Efek Media

Framework efek media baru memungkinkan Anda menerapkan berbagai efek visual ke gambar dan video. Misalnya, efek gambar memungkinkan Anda memperbaiki mata merah dengan mudah, mengonversi gambar menjadi hitam putih, menyesuaikan kecerahan, menyesuaikan saturasi, memutar gambar, menerapkan efek mata ikan, dan banyak lagi. Sistem melakukan semua pemrosesan efek pada GPU untuk mendapatkan performa maksimum.

Untuk performa maksimum, efek diterapkan langsung ke tekstur OpenGL, sehingga aplikasi Anda harus memiliki konteks OpenGL yang valid sebelum dapat menggunakan API efek. Tekstur tempat Anda menerapkan efek dapat berasal dari bitmap, video, atau bahkan kamera. Namun, ada batasan tertentu yang harus dipenuhi oleh tekstur:

  1. Gambar harus terikat dengan gambar tekstur GL_TEXTURE_2D
  2. Peta lokasi harus berisi setidaknya satu level mipmap

Objek Effect menentukan satu efek media yang dapat Anda terapkan ke frame gambar. Alur kerja dasar untuk membuat Effect adalah:

  1. Panggil EffectContext.createWithCurrentGlContext() dari konteks OpenGL ES 2.0 Anda.
  2. Gunakan EffectContext yang ditampilkan untuk memanggil EffectContext.getFactory(), yang menampilkan instance EffectFactory.
  3. Panggil createEffect(), lalu teruskan nama efek dari @link android.media.effect.EffectFactory}, seperti EFFECT_FISHEYE atau EFFECT_VIGNETTE.

Anda dapat menyesuaikan parameter efek dengan memanggil setParameter() dan meneruskan nama parameter dan nilai parameter. Setiap jenis efek menerima parameter yang berbeda, yang didokumentasikan dengan nama efek. Misalnya, EFFECT_FISHEYE memiliki satu parameter untuk scale distorsi.

Untuk menerapkan efek pada tekstur, panggil apply() pada Effect dan teruskan tekstur input, lebar dan tingginya, serta tekstur output. Tekstur input harus terikat dengan gambar tekstur GL_TEXTURE_2D (biasanya dilakukan dengan memanggil fungsi glTexImage2D()). Anda dapat memberikan beberapa level mipmap. Jika tekstur output belum terikat dengan gambar tekstur, tekstur tersebut akan otomatis terikat oleh efek sebagai GL_TEXTURE_2D dan dengan satu level mipmap (0), yang akan memiliki ukuran yang sama dengan input.

Semua efek yang tercantum dalam EffectFactory dijamin akan didukung. Namun, beberapa efek tambahan yang tersedia dari library eksternal tidak didukung oleh semua perangkat, sehingga Anda harus memeriksa terlebih dahulu apakah efek yang diinginkan dari library eksternal didukung dengan memanggil isEffectSupported().

Klien remote control

RemoteControlClient baru memungkinkan pemutar media mengaktifkan kontrol pemutaran dari klien remote control seperti layar kunci perangkat. Pemutar media juga dapat menampilkan informasi tentang media yang sedang diputar untuk ditampilkan pada remote control, seperti informasi trek dan gambar album.

Guna mengaktifkan klien remote control untuk pemutar media, buat instance RemoteControlClient dengan konstruktornya, dengan meneruskan PendingIntent yang menyiarkan ACTION_MEDIA_BUTTON. Intent juga harus mendeklarasikan komponen BroadcastReceiver eksplisit di aplikasi Anda yang menangani peristiwa ACTION_MEDIA_BUTTON.

Untuk mendeklarasikan input kontrol media yang dapat ditangani pemutar, Anda harus memanggil setTransportControlFlags() pada RemoteControlClient, yang meneruskan kumpulan tanda FLAG_KEY_MEDIA_*, seperti FLAG_KEY_MEDIA_PREVIOUS dan FLAG_KEY_MEDIA_NEXT.

Kemudian, Anda harus mendaftarkan RemoteControlClient dengan meneruskannya ke MediaManager.registerRemoteControlClient(). Setelah terdaftar, penerima siaran yang Anda deklarasikan saat membuat instance RemoteControlClient akan menerima peristiwa ACTION_MEDIA_BUTTON saat tombol ditekan dari remote control. Intent yang Anda terima akan menyertakan KeyEvent untuk tombol media yang ditekan, yang dapat Anda ambil dari intent dengan getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Untuk menampilkan informasi tentang media yang diputar pada remote control, panggil editMetaData() dan tambahkan metadata ke RemoteControlClient.MetadataEditor yang ditampilkan. Anda dapat menyediakan bitmap untuk karya seni media, informasi numerik seperti waktu berlalu, dan informasi teks seperti judul trek. Untuk informasi tentang kunci yang tersedia, lihat tanda METADATA_KEY_* di MediaMetadataRetriever.

Untuk contoh implementasi, lihat Random Music Player, yang menyediakan logika kompatibilitas sehingga memungkinkan klien remote control di perangkat Android 4.0 sambil terus mendukung perangkat yang kembali ke Android 2.1.

Pemutar media

  • Streaming media online dari MediaPlayer kini memerlukan izin INTERNET. Jika Anda menggunakan MediaPlayer untuk memutar konten dari Internet, pastikan untuk menambahkan izin INTERNET ke manifes Anda. Jika tidak, pemutaran media Anda tidak akan berfungsi mulai dengan Android 4.0.
  • setSurface() memungkinkan Anda menentukan Surface agar berperilaku sebagai sink video.
  • setDataSource() memungkinkan Anda mengirim header HTTP tambahan dengan permintaan, yang dapat berguna untuk live streaming HTTP(S)
  • Live streaming HTTP(S) kini mematuhi cookie HTTP di seluruh permintaan

Jenis media

Android 4.0 menambahkan dukungan untuk:

  • Protokol live streaming HTTP/HTTPS versi 3
  • Encoding audio AAC mentah ADTS
  • Gambar WEBP
  • Video Matroska

Untuk mengetahui info selengkapnya, lihat Format Media yang Didukung.

Kamera

Class Camera kini menyertakan API untuk mendeteksi wajah dan mengontrol area fokus dan pengukuran.

Deteksi wajah

Aplikasi kamera kini dapat meningkatkan kemampuannya dengan API deteksi wajah Android, yang tidak hanya mendeteksi wajah subjek, tetapi juga fitur wajah tertentu, seperti mata dan mulut.

Untuk mendeteksi wajah di aplikasi kamera, Anda harus mendaftarkan Camera.FaceDetectionListener dengan memanggil setFaceDetectionListener(). Kemudian, Anda dapat memulai platform kamera dan mulai mendeteksi wajah dengan memanggil startFaceDetection().

Saat mendeteksi satu atau beberapa wajah dalam suasana kamera, sistem akan memanggil callback onFaceDetection() dalam implementasi Camera.FaceDetectionListener Anda, termasuk array objek Camera.Face.

Instance class Camera.Face menyediakan berbagai informasi tentang wajah yang terdeteksi, termasuk:

  • Rect yang menentukan batas wajah, relatif terhadap ruang pandang kamera saat ini
  • Bilangan bulat antara 1 dan 100 yang menunjukkan seberapa yakin sistem bahwa objek adalah wajah manusia
  • ID unik sehingga Anda dapat melacak beberapa wajah
  • Beberapa objek Point yang menunjukkan lokasi mata dan mulut

Catatan: Deteksi wajah mungkin tidak didukung di beberapa perangkat, sehingga Anda harus memeriksanya dengan memanggil getMaxNumDetectedFaces() dan memastikan nilai yang ditampilkan lebih besar dari nol. Selain itu, beberapa perangkat mungkin tidak mendukung identifikasi mata dan mulut, dalam hal ini, kolom dalam objek Camera.Face akan bernilai null.

Area fokus dan pengukuran

Aplikasi kamera kini dapat mengontrol area yang digunakan kamera untuk fokus serta untuk mengukur white balance dan eksposur otomatis. Kedua fitur menggunakan class Camera.Area baru untuk menentukan area tampilan kamera saat ini yang harus difokuskan atau diukur. Instance class Camera.Area menentukan batas area dengan Rect dan bobot area—yang mewakili tingkat kepentingan area tersebut, relatif terhadap area lain yang dipertimbangkan—dengan bilangan bulat.

Sebelum menetapkan area fokus atau area pengukuran, Anda harus terlebih dahulu memanggil getMaxNumFocusAreas() atau getMaxNumMeteringAreas(). Jika hasilnya nol, berarti perangkat tidak mendukung fitur yang sesuai.

Untuk menentukan area fokus atau pengukuran yang akan digunakan, cukup panggil setFocusAreas() atau setMeteringAreas(). Masing-masing mengambil List dari objek Camera.Area yang menunjukkan area yang perlu dipertimbangkan untuk fokus atau pengukuran. Misalnya, Anda dapat mengimplementasikan fitur yang memungkinkan pengguna menetapkan area fokus dengan menyentuh area pratinjau, yang kemudian diterjemahkan menjadi objek Camera.Area dan meminta kamera berfokus pada area adegan tersebut. Fokus atau eksposur di area tersebut akan terus diperbarui seiring perubahan pemandangan di area tersebut.

Fokus otomatis berkelanjutan untuk foto

Anda kini dapat mengaktifkan fokus otomatis berkelanjutan (CAF) saat mengambil foto. Untuk mengaktifkan CAF di aplikasi kamera, teruskan FOCUS_MODE_CONTINUOUS_PICTURE ke setFocusMode(). Jika sudah siap mengambil foto, panggil autoFocus(). Camera.AutoFocusCallback segera menerima callback untuk menunjukkan apakah fokus tercapai. Untuk melanjutkan CAF setelah menerima callback, Anda harus memanggil cancelAutoFocus().

Catatan: Fokus otomatis berkelanjutan juga didukung saat merekam video, menggunakan FOCUS_MODE_CONTINUOUS_VIDEO, yang ditambahkan dalam API level 9.

Fitur kamera lainnya

  • Saat merekam video, Anda kini dapat memanggil takePicture() untuk menyimpan foto tanpa mengganggu sesi video. Sebelum melakukannya, Anda harus memanggil isVideoSnapshotSupported() untuk memastikan hardware mendukungnya.
  • Anda kini dapat mengunci eksposur otomatis dan white balance dengan setAutoExposureLock() dan setAutoWhiteBalanceLock() untuk mencegah properti ini berubah.
  • Anda kini dapat memanggil setDisplayOrientation() saat pratinjau kamera sedang berjalan. Sebelumnya, Anda hanya dapat memanggilnya sebelum memulai pratinjau, tetapi sekarang Anda dapat mengubah orientasi kapan saja.

Intent siaran kamera

  • Camera.ACTION_NEW_PICTURE: Hal ini menunjukkan bahwa pengguna telah mengambil foto baru. Aplikasi Kamera bawaan memanggil siaran ini setelah foto diambil dan aplikasi kamera pihak ketiga juga harus menyiarkan intent ini setelah mengambil foto.
  • Camera.ACTION_NEW_VIDEO: Hal ini menunjukkan bahwa pengguna telah merekam video baru. Aplikasi Kamera bawaan memanggil siaran ini setelah video direkam dan aplikasi kamera pihak ketiga juga harus menyiarkan intent ini setelah merekam video.

Android Beam (Push NDEF dengan NFC)

Android Beam adalah fitur NFC baru yang memungkinkan Anda mengirim pesan NDEF dari satu perangkat ke perangkat lain (proses yang juga dikenal sebagai “NDEF Push”). Transfer data dimulai saat dua perangkat Android yang mendukung Android Beam berada dalam jarak yang berdekatan (sekitar 4 cm), biasanya dengan bagian belakang bersentuhan. Data di dalam pesan NDEF dapat berisi data apa pun yang ingin Anda bagikan antar-perangkat. Misalnya, aplikasi Orang berbagi kontak, YouTube berbagi video, dan Browser berbagi URL menggunakan Android Beam.

Untuk mentransmisikan data antar-perangkat menggunakan Android Beam, Anda perlu membuat NdefMessage yang berisi informasi yang ingin dibagikan saat aktivitas berada di latar depan. Kemudian, Anda harus meneruskan NdefMessage ke sistem dengan salah satu dari dua cara:

Jika ingin menjalankan beberapa kode tertentu setelah sistem berhasil mengirimkan pesan NDEF ke perangkat lain, Anda dapat mengimplementasikan NfcAdapter.OnNdefPushCompleteCallback dan menyetelnya dengan setNdefPushCompleteCallback(). Selanjutnya, sistem akan memanggil onNdefPushComplete() saat pesan dikirim.

Di perangkat penerima, sistem akan mengirim pesan Push NDEF dengan cara yang sama seperti tag NFC reguler. Sistem memanggil intent dengan tindakan ACTION_NDEF_DISCOVERED untuk memulai aktivitas, baik dengan URL atau jenis MIME yang ditetapkan menurut NdefRecord pertama dalam NdefMessage. Untuk aktivitas yang ingin direspons, Anda dapat mendeklarasikan filter intent untuk URL atau jenis MIME yang penting bagi aplikasi Anda. Untuk mengetahui informasi selengkapnya tentang Pengiriman Tag, lihat panduan developer NFC.

Jika ingin NdefMessage membawa URI, Anda kini dapat menggunakan metode createUri praktis untuk membuat NdefRecord baru berdasarkan string atau objek Uri. Jika URI adalah format khusus yang juga ingin diterima aplikasi selama peristiwa Android Beam, Anda harus membuat filter intent untuk aktivitas Anda menggunakan skema URI yang sama untuk menerima pesan NDEF yang masuk.

Anda juga harus meneruskan "data aplikasi Android" dengan NdefMessage untuk menjamin bahwa aplikasi Anda menangani pesan NDEF yang masuk, meskipun aplikasi lain memfilter tindakan intent yang sama. Anda dapat membuat data aplikasi Android dengan memanggil createApplicationRecord(), yang meneruskan nama paket aplikasi Anda. Saat perangkat lain menerima pesan NDEF dengan data aplikasi dan beberapa aplikasi berisi aktivitas yang menangani intent yang ditentukan, sistem akan selalu mengirimkan pesan ke aktivitas dalam aplikasi Anda (berdasarkan catatan aplikasi yang cocok). Jika aplikasi Anda belum diinstal di perangkat target, sistem akan menggunakan data aplikasi Android untuk meluncurkan Google Play dan mengarahkan pengguna ke aplikasi tersebut untuk menginstalnya.

Jika aplikasi Anda tidak menggunakan API NFC untuk melakukan pengiriman pesan NDEF Push, Android akan menyediakan perilaku default: Saat aplikasi berada di latar depan pada satu perangkat dan Android Beam dipanggil dengan perangkat Android lainnya, perangkat lain akan menerima pesan NDEF berisi data aplikasi Android yang mengidentifikasi aplikasi Anda. Jika aplikasi sudah diinstal di perangkat penerima, sistem akan meluncurkannya. Jika tidak diinstal, Google Play akan terbuka dan mengarahkan pengguna ke aplikasi Anda untuk menginstalnya.

Anda dapat membaca selengkapnya tentang Android Beam dan fitur NFC lainnya di panduan developer Dasar-Dasar NFC. Untuk beberapa contoh kode yang menggunakan Android Beam, lihat Demo Android Beam.

Wi-Fi P2P

Android kini mendukung koneksi Wi-Fi peer-to-peer (P2P) antara perangkat Android dan jenis perangkat lainnya (sesuai dengan program sertifikasi Wi-Fi DirectTM Wi-Fi Alliance) tanpa hotspot atau koneksi Internet. Framework Android menyediakan serangkaian Wi-Fi P2P API yang memungkinkan Anda menemukan dan terhubung ke perangkat lain jika setiap perangkat mendukung Wi-Fi P2P, lalu berkomunikasi melalui koneksi cepat melintasi jarak yang jauh lebih lama daripada koneksi Bluetooth.

Paket baru, android.net.wifi.p2p, berisi semua API untuk melakukan koneksi peer-to-peer dengan Wi-Fi. Class utama yang perlu Anda gunakan adalah WifiP2pManager, yang dapat Anda peroleh dengan memanggil getSystemService(WIFI_P2P_SERVICE). WifiP2pManager menyertakan API yang memungkinkan Anda:

  • Lakukan inisialisasi aplikasi untuk koneksi P2P dengan memanggil initialize()
  • Temukan perangkat di sekitar dengan menelepon discoverPeers()
  • Mulai koneksi P2P dengan memanggil connect()
  • Dan lainnya

Beberapa antarmuka dan class lain juga diperlukan, seperti:

  • Antarmuka WifiP2pManager.ActionListener memungkinkan Anda menerima callback saat operasi seperti menemukan peer atau terhubung ke callback berhasil atau gagal.
  • Antarmuka WifiP2pManager.PeerListListener memungkinkan Anda menerima informasi tentang pembanding yang ditemukan. Callback menyediakan WifiP2pDeviceList, tempat Anda dapat mengambil objek WifiP2pDevice untuk setiap perangkat dalam jangkauan dan mendapatkan informasi seperti nama perangkat, alamat, jenis perangkat, konfigurasi WPS yang didukung perangkat, dan banyak lagi.
  • Antarmuka WifiP2pManager.GroupInfoListener memungkinkan Anda menerima informasi tentang grup P2P. Callback memberikan objek WifiP2pGroup yang memberikan informasi grup seperti pemilik, nama jaringan, dan frasa sandi.
  • Antarmuka WifiP2pManager.ConnectionInfoListener memungkinkan Anda menerima informasi tentang koneksi saat ini. Callback memberikan objek WifiP2pInfo yang memiliki informasi seperti apakah grup telah dibentuk dan siapa pemilik grup tersebut.

Untuk menggunakan Wi-Fi P2P API, aplikasi Anda harus meminta izin pengguna berikut:

Sistem Android juga menyiarkan beberapa tindakan yang berbeda selama peristiwa Wi-Fi P2P tertentu:

Lihat dokumentasi WifiP2pManager untuk informasi selengkapnya. Lihat juga aplikasi contoh Demo Wi-Fi P2P.

Perangkat Kesehatan Bluetooth

Android kini mendukung perangkat Profil Kesehatan Bluetooth, sehingga Anda dapat membuat aplikasi yang menggunakan Bluetooth untuk berkomunikasi dengan perangkat kesehatan yang mendukung Bluetooth, seperti pemantau detak jantung, pengukur darah, termometer, dan timbangan.

Serupa dengan headset biasa dan perangkat profil A2DP, Anda harus memanggil getProfileProxy() dengan BluetoothProfile.ServiceListener dan jenis profil HEALTH untuk terhubung dengan objek proxy profil.

Setelah Anda mendapatkan proxy Profil Kesehatan (objek BluetoothHealth), menghubungkan dan berkomunikasi dengan perangkat kesehatan yang disambungkan melibatkan class Bluetooth baru berikut:

  • BluetoothHealthCallback: Anda harus memperluas class ini dan menerapkan metode callback untuk menerima update tentang perubahan status pendaftaran aplikasi dan status saluran Bluetooth.
  • BluetoothHealthAppConfiguration: Selama callback ke BluetoothHealthCallback, Anda akan menerima instance objek ini, yang menyediakan informasi konfigurasi tentang perangkat kesehatan Bluetooth yang tersedia, yang harus Anda gunakan untuk menjalankan berbagai operasi seperti memulai dan mengakhiri koneksi dengan API BluetoothHealth.

Untuk informasi selengkapnya tentang menggunakan Profil Kesehatan Bluetooth, lihat dokumentasi untuk BluetoothHealth.

Aksesibilitas

Android 4.0 meningkatkan aksesibilitas bagi pengguna yang memiliki gangguan penglihatan dengan mode sentuh baru dan API yang diperluas yang memungkinkan Anda memberikan informasi selengkapnya tentang konten tampilan atau mengembangkan layanan aksesibilitas lanjutan.

Mode Sentuh untuk Pelajari

Pengguna yang kehilangan penglihatan kini dapat menjelajahi layar dengan menyentuh dan menarik jari di layar untuk mendengar deskripsi suara pada konten. Karena berfungsi seperti kursor virtual, mode ini memungkinkan pembaca layar mengidentifikasi teks deskriptif dengan cara yang sama seperti yang dilakukan pembaca layar saat pengguna menavigasi dengan d-pad atau trackball—dengan membaca informasi yang diberikan oleh android:contentDescription dan setContentDescription() pada simulasi peristiwa "arahkan kursor". Jadi, anggap ini adalah pengingat bahwa Anda harus memberikan teks deskriptif untuk tampilan dalam aplikasi Anda, terutama untuk ImageButton, EditText, ImageView, dan widget lain yang mungkin tidak secara alami berisi teks deskriptif.

Aksesibilitas untuk tampilan

Guna meningkatkan informasi yang tersedia untuk layanan aksesibilitas seperti pembaca layar, Anda dapat mengimplementasikan metode callback baru untuk peristiwa aksesibilitas dalam komponen View kustom.

Penting untuk diperhatikan terlebih dahulu bahwa perilaku metode sendAccessibilityEvent() telah berubah di Android 4.0. Seperti pada versi Android sebelumnya, saat pengguna mengaktifkan layanan aksesibilitas pada perangkat dan peristiwa input seperti klik atau pengarahan kursor terjadi, tampilan masing-masing akan diberi tahu dengan panggilan ke sendAccessibilityEvent(). Sebelumnya, implementasi sendAccessibilityEvent() akan melakukan inisialisasi AccessibilityEvent dan mengirimkannya ke AccessibilityManager. Perilaku baru ini melibatkan beberapa metode callback tambahan yang memungkinkan tampilan dan induknya menambahkan lebih banyak informasi kontekstual ke peristiwa:

  1. Saat dipanggil, metode sendAccessibilityEvent() dan sendAccessibilityEventUnchecked() akan beralih ke onInitializeAccessibilityEvent().

    Implementasi kustom View mungkin ingin mengimplementasikan onInitializeAccessibilityEvent() untuk melampirkan informasi aksesibilitas tambahan ke AccessibilityEvent, tetapi juga harus memanggil implementasi super untuk memberikan informasi default seperti deskripsi konten standar, indeks item, dan lainnya. Namun, Anda tidak boleh menambahkan konten teks tambahan dalam callback ini—yang akan terjadi berikutnya.

  2. Setelah diinisialisasi, jika peristiwa adalah salah satu dari beberapa jenis yang harus diisi dengan informasi teks, tampilan akan menerima panggilan ke dispatchPopulateAccessibilityEvent(), yang akan ditangguhkan ke callback onPopulateAccessibilityEvent().

    Implementasi kustom View biasanya harus mengimplementasikan onPopulateAccessibilityEvent() untuk menambahkan konten teks tambahan ke AccessibilityEvent jika teks android:contentDescription tidak ada atau tidak memadai. Untuk menambahkan lebih banyak deskripsi teks ke AccessibilityEvent, panggil getText().add().

  3. Pada tahap ini, View meneruskan peristiwa ke atas hierarki tampilan dengan memanggil requestSendAccessibilityEvent() pada tampilan induk. Setiap tampilan induk kemudian memiliki kesempatan untuk meningkatkan informasi aksesibilitas dengan menambahkan AccessibilityRecord, hingga akhirnya mencapai tampilan root, yang mengirimkan peristiwa ke AccessibilityManager dengan sendAccessibilityEvent().

Selain metode baru di atas, yang berguna saat memperluas class View, Anda juga dapat menangkap callback peristiwa ini pada View mana pun dengan memperluas AccessibilityDelegate dan menyetelnya pada tampilan dengan setAccessibilityDelegate(). Jika Anda melakukannya, setiap metode aksesibilitas dalam tampilan akan menangguhkan panggilan ke metode terkait dalam delegasi. Misalnya, saat menerima panggilan ke onPopulateAccessibilityEvent(), tampilan akan meneruskannya ke metode yang sama di View.AccessibilityDelegate. Metode apa pun yang tidak ditangani oleh delegasi akan dikembalikan langsung ke tampilan untuk perilaku default. Hal ini memungkinkan Anda mengganti hanya metode yang diperlukan untuk tampilan tertentu tanpa memperluas class View.

Jika Anda ingin mempertahankan kompatibilitas dengan versi Android sebelum 4.0, sekaligus mendukung API aksesibilitas yang baru, Anda dapat melakukannya dengan library dukungan v4 versi terbaru (di Compatibility Package, r4) menggunakan kumpulan class utilitas yang menyediakan API aksesibilitas baru dalam desain yang kompatibel dengan versi lama.

Layanan aksesibilitas

Jika Anda mengembangkan layanan aksesibilitas, informasi tentang berbagai peristiwa aksesibilitas telah diperluas secara signifikan untuk memungkinkan masukan aksesibilitas yang lebih canggih bagi pengguna. Secara khusus, peristiwa dibuat berdasarkan komposisi tampilan, yang memberikan informasi konteks yang lebih baik dan memungkinkan layanan aksesibilitas menjelajahi hierarki tampilan untuk mendapatkan informasi tampilan tambahan dan menangani kasus khusus.

Jika mengembangkan layanan aksesibilitas (seperti pembaca layar), Anda dapat mengakses informasi konten tambahan dan menjelajahi hierarki tampilan dengan prosedur berikut:

  1. Setelah menerima AccessibilityEvent dari aplikasi, panggil AccessibilityEvent.getRecord() untuk mengambil AccessibilityRecord tertentu (mungkin ada beberapa catatan yang dilampirkan ke peristiwa tersebut).
  2. Dari AccessibilityEvent atau AccessibilityRecord individual, Anda dapat memanggil getSource() untuk mengambil objek AccessibilityNodeInfo.

    AccessibilityNodeInfo mewakili satu node konten jendela dalam format yang memungkinkan Anda membuat kueri informasi aksesibilitas tentang node tersebut. Objek AccessibilityNodeInfo yang ditampilkan dari AccessibilityEvent menjelaskan sumber peristiwa, sedangkan sumber dari AccessibilityRecord menjelaskan pendahulu sumber peristiwa.

  3. Dengan AccessibilityNodeInfo, Anda dapat membuat kueri informasi tentangnya, memanggil getParent() atau getChild() untuk menjelajahi hierarki tampilan, dan bahkan menambahkan tampilan turunan ke node.

Agar dapat memublikasikan dirinya sendiri ke sistem sebagai layanan aksesibilitas, aplikasi harus mendeklarasikan file konfigurasi XML yang sesuai dengan AccessibilityServiceInfo. Untuk informasi selengkapnya tentang membuat layanan aksesibilitas, lihat AccessibilityService dan SERVICE_META_DATA untuk mengetahui informasi tentang konfigurasi XML.

API aksesibilitas lainnya

Jika Anda tertarik dengan status aksesibilitas perangkat, AccessibilityManager memiliki beberapa API baru seperti:

Layanan Pemeriksa Ejaan

Framework pemeriksa ejaan baru memungkinkan aplikasi membuat pemeriksa ejaan dengan cara yang mirip dengan framework metode input (untuk IME). Untuk membuat pemeriksa ejaan baru, Anda harus mengimplementasikan layanan yang memperluas SpellCheckerService dan memperluas class SpellCheckerService.Session untuk memberikan saran ejaan berdasarkan teks yang disediakan oleh metode callback antarmuka. Dalam metode callback SpellCheckerService.Session, Anda harus menampilkan saran ejaan sebagai objek SuggestionsInfo.

Aplikasi dengan layanan pemeriksa ejaan harus menyatakan izin BIND_TEXT_SERVICE sebagaimana diwajibkan oleh layanan. Layanan juga harus mendeklarasikan filter intent dengan <action android:name="android.service.textservice.SpellCheckerService" /> sebagai tindakan intent dan harus menyertakan elemen <meta-data> yang mendeklarasikan informasi konfigurasi untuk pemeriksa ejaan.

Lihat contoh aplikasi Layanan Pemeriksa Ejaan dan contoh aplikasi Klien Pemeriksa Ejaan untuk mengetahui kode contoh.

Mesin Text-to-speech

API text-to-speech (TTS) Android telah diperluas secara signifikan untuk memungkinkan aplikasi mengimplementasikan mesin TTS kustom dengan lebih mudah, sementara aplikasi yang ingin menggunakan mesin TTS memiliki beberapa API baru untuk memilih mesin.

Menggunakan mesin text-to-speech

Pada versi Android sebelumnya, Anda dapat menggunakan class TextToSpeech untuk menjalankan operasi text-to-speech (TTS) menggunakan mesin TTS yang disediakan oleh sistem atau menyetel mesin kustom menggunakan setEngineByPackageName(). Di Android 4.0, metode setEngineByPackageName() tidak digunakan lagi dan kini Anda dapat menentukan mesin yang akan digunakan dengan konstruktor TextToSpeech baru yang menerima nama paket mesin TTS.

Anda juga dapat mengkueri mesin TTS yang tersedia dengan getEngines(). Metode ini akan menampilkan daftar objek TextToSpeech.EngineInfo, yang menyertakan metadata seperti ikon, label, dan nama paket mesin.

Membangun mesin text-to-speech

Sebelumnya, mesin kustom mengharuskan mesin dibuat menggunakan file header native yang tidak terdokumentasi. Di Android 4.0, terdapat satu set lengkap API framework untuk membangun mesin TTS.

Penyiapan dasar memerlukan implementasi TextToSpeechService yang merespons intent INTENT_ACTION_TTS_SERVICE. Pekerjaan utama untuk mesin TTS terjadi selama callback onSynthesizeText() dalam layanan yang memperluas TextToSpeechService. Sistem mengirimkan dua objek ke metode ini:

  • SynthesisRequest: Data ini berisi berbagai data, termasuk teks yang akan disintesis, lokalitas, kecepatan ucapan, dan nada suara.
  • SynthesisCallback: Ini adalah antarmuka yang digunakan mesin TTS untuk mengirimkan data ucapan yang dihasilkan sebagai audio streaming. Pertama-tama, mesin harus memanggil start() untuk menunjukkan bahwa mesin siap mengirimkan audio, lalu memanggil audioAvailable(), dengan meneruskan data audio dalam buffer byte. Setelah mesin meneruskan semua audio melalui buffer, panggil done().

Setelah framework mendukung API sebenarnya untuk membuat mesin TTS, dukungan untuk implementasi kode native telah dihapus. Cari postingan blog tentang lapisan kompatibilitas yang dapat Anda gunakan untuk mengonversi mesin TTS lama ke framework baru.

Untuk contoh mesin TTS yang menggunakan API baru, lihat aplikasi contoh Text To Speech Engine.

Penggunaan Jaringan

Android 4.0 memberi pengguna visibilitas yang tepat tentang jumlah data jaringan yang digunakan aplikasi mereka. Aplikasi Setelan menyediakan kontrol yang memungkinkan pengguna mengelola batas yang ditetapkan untuk penggunaan data jaringan dan bahkan menonaktifkan penggunaan data latar belakang untuk masing-masing aplikasi. Agar pengguna tidak menonaktifkan akses aplikasi Anda ke data dari latar belakang, Anda harus mengembangkan strategi untuk menggunakan koneksi data secara efisien dan menyesuaikan penggunaan bergantung pada jenis koneksi yang tersedia.

Jika aplikasi melakukan banyak transaksi jaringan, Anda harus memberikan setelan pengguna yang memungkinkan pengguna mengontrol kebiasaan data aplikasi Anda, seperti seberapa sering aplikasi Anda menyinkronkan data, apakah akan melakukan upload/download hanya saat terhubung ke Wi-Fi, apakah menggunakan data saat roaming, dll. Dengan kontrol ini, pengguna kemungkinan besar tidak menonaktifkan akses aplikasi Anda ke data saat mendekati batas mereka, karena mereka dapat mengontrol dengan akurat berapa banyak data yang digunakan. Jika Anda menyediakan aktivitas preferensi dengan setelan ini, Anda harus menyertakan filter intent untuk tindakan ACTION_MANAGE_NETWORK_USAGE dalam deklarasi manifesnya. Contoh:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Filter intent ini menunjukkan pada sistem bahwa ini adalah aktivitas yang mengontrol penggunaan data aplikasi Anda. Oleh karena itu, saat pengguna memeriksa jumlah data yang digunakan aplikasi dari aplikasi Setelan, tombol "Lihat setelan aplikasi" akan tersedia untuk meluncurkan aktivitas preferensi Anda sehingga pengguna dapat menyaring jumlah data yang digunakan aplikasi Anda.

Perhatikan juga bahwa getBackgroundDataSetting() kini tidak digunakan lagi dan selalu menampilkan benar (true)—sebagai gantinya, gunakan getActiveNetworkInfo(). Sebelum mencoba transaksi jaringan apa pun, Anda harus selalu memanggil getActiveNetworkInfo() untuk mendapatkan NetworkInfo yang mewakili jaringan saat ini dan mengkueri isConnected() untuk memeriksa apakah perangkat memiliki koneksi. Kemudian, Anda dapat memeriksa properti koneksi lainnya, seperti apakah perangkat melakukan roaming atau terhubung ke Wi-Fi.

Enterprise

Android 4.0 memperluas kemampuan untuk aplikasi perusahaan dengan fitur berikut ini.

Layanan VPN

VpnService baru memungkinkan aplikasi mem-build VPN (Virtual Private Network)-nya sendiri yang berjalan sebagai Service. Layanan VPN membuat antarmuka untuk jaringan virtual dengan alamat dan aturan peruteannya sendiri, serta melakukan semua pembacaan dan penulisan dengan deskripsi file.

Untuk membuat layanan VPN, gunakan VpnService.Builder, yang memungkinkan Anda menentukan alamat jaringan, server DNS, rute jaringan, dan lainnya. Setelah selesai, Anda dapat membuat antarmuka dengan memanggil establish(), yang akan menampilkan ParcelFileDescriptor.

Karena layanan VPN dapat mencegat paket, ada implikasi keamanan. Dengan demikian, jika Anda mengimplementasikan VpnService, layanan Anda harus mewajibkan BIND_VPN_SERVICE untuk memastikan bahwa hanya sistem yang dapat mengikatnya (hanya sistem yang diberi izin ini—aplikasi tidak dapat memintanya). Untuk menggunakan layanan VPN, pengguna harus mengaktifkannya secara manual di setelan sistem.

Kebijakan perangkat

Aplikasi yang mengelola batasan perangkat kini dapat menonaktifkan kamera menggunakan setCameraDisabled() dan properti USES_POLICY_DISABLE_CAMERA (diterapkan dengan elemen <disable-camera /> dalam file konfigurasi kebijakan).

Pengelolaan sertifikat

Class KeyChain baru menyediakan API yang memungkinkan Anda mengimpor dan mengakses sertifikat di penyimpanan kunci sistem. Sertifikat menyederhanakan penginstalan sertifikat klien (untuk memvalidasi identitas pengguna) dan sertifikat certificate authority (untuk memverifikasi identitas server). Aplikasi seperti browser web atau program email dapat mengakses sertifikat yang diinstal untuk mengautentikasi pengguna ke server. Lihat dokumentasi KeyChain untuk informasi selengkapnya.

Sensor Perangkat

Dua jenis sensor baru telah ditambahkan di Android 4.0:

Jika perangkat memiliki sensor TYPE_AMBIENT_TEMPERATURE dan TYPE_RELATIVE_HUMIDITY, Anda dapat menggunakannya untuk menghitung titik embun dan kelembapan absolut.

Sensor suhu sebelumnya, TYPE_TEMPERATURE, sudah tidak digunakan lagi. Sebagai gantinya, Anda harus menggunakan sensor TYPE_AMBIENT_TEMPERATURE.

Selain itu, tiga sensor sintetis Android telah ditingkatkan secara signifikan sehingga kini memiliki latensi yang lebih rendah dan output yang lebih halus. Sensor ini mencakup sensor gravitasi (TYPE_GRAVITY), sensor vektor rotasi (TYPE_ROTATION_VECTOR), dan sensor akselerasi linear (TYPE_LINEAR_ACCELERATION). Sensor yang ditingkatkan ini mengandalkan sensor giroskop untuk meningkatkan outputnya, sehingga sensor hanya muncul di perangkat yang memiliki giroskop.

Panel Tindakan

ActionBar telah diupdate untuk mendukung beberapa perilaku baru. Yang paling penting, sistem mengelola ukuran dan konfigurasi panel tindakan dengan baik saat berjalan di layar yang lebih kecil untuk memberikan pengalaman pengguna yang optimal di semua ukuran layar. Misalnya, saat layarnya sempit (seperti saat handset dalam orientasi potret), tab navigasi panel tindakan akan muncul dalam "bilah bertumpuk", yang muncul tepat di bawah panel tindakan utama. Anda juga dapat menggunakan "panel tindakan terpisah", yang menempatkan semua item tindakan dalam panel terpisah di bagian bawah layar saat layarnya sempit.

Panel tindakan terpisah

Jika panel tindakan Anda menyertakan beberapa item tindakan, tidak semuanya akan pas dengan panel tindakan pada layar yang sempit, sehingga sistem akan menempatkan lebih banyak item tindakan di menu tambahan. Namun, Android 4.0 memungkinkan Anda mengaktifkan "panel tindakan terpisah" sehingga lebih banyak item tindakan dapat muncul di layar dalam panel terpisah di bagian bawah layar. Untuk mengaktifkan panel tindakan terpisah, tambahkan android:uiOptions dengan "splitActionBarWhenNarrow" ke tag <application> atau tag <activity> individual di file manifes Anda. Jika diaktifkan, sistem akan menambahkan panel tambahan di bagian bawah layar untuk semua item tindakan jika layarnya sempit (tidak ada item tindakan yang akan muncul di panel tindakan utama).

Jika Anda ingin menggunakan tab navigasi yang disediakan oleh API ActionBar.Tab, tetapi tidak memerlukan panel tindakan utama di bagian atas (Anda hanya ingin tab yang muncul di bagian atas), aktifkan panel tindakan terpisah seperti yang dijelaskan di atas dan juga panggil setDisplayShowHomeEnabled(false) untuk menonaktifkan ikon aplikasi di panel tindakan. Dengan tidak ada yang tersisa di panel tindakan utama, panel akan hilang—satu-satunya yang tersisa adalah tab navigasi di bagian atas dan item tindakan di bagian bawah layar.

Gaya panel tindakan

Jika ingin menerapkan gaya visual kustom ke panel tindakan, Anda dapat menggunakan properti gaya baru backgroundStacked dan backgroundSplit untuk menerapkan drawable latar belakang atau warna ke panel bertumpuk dan panel terpisah. Anda juga dapat menetapkan gaya ini saat runtime dengan setStackedBackgroundDrawable() dan setSplitBackgroundDrawable().

Penyedia tindakan

Class ActionProvider baru memungkinkan Anda membuat pengendali khusus untuk item tindakan. Penyedia tindakan dapat menentukan tampilan tindakan, perilaku tindakan default, dan submenu untuk setiap item tindakan yang terkait. Jika Anda ingin membuat item tindakan yang memiliki perilaku dinamis (seperti tampilan tindakan variabel, tindakan default, atau submenu), memperluas ActionProvider adalah solusi yang baik untuk membuat komponen yang dapat digunakan kembali, daripada menangani berbagai transformasi item tindakan dalam fragmen atau aktivitas Anda.

Misalnya, ShareActionProvider adalah ekstensi dari ActionProvider yang memfasilitasi tindakan "bagikan" dari panel tindakan. Daripada menggunakan item tindakan tradisional yang memanggil intent ACTION_SEND, Anda dapat menggunakan penyedia tindakan ini untuk menampilkan tampilan tindakan dengan menu drop-down aplikasi yang menangani intent ACTION_SEND. Saat pengguna memilih aplikasi yang akan digunakan untuk tindakan, ShareActionProvider akan mengingat pilihan tersebut dan menyediakannya dalam tampilan tindakan untuk akses yang lebih cepat untuk berbagi dengan aplikasi tersebut.

Untuk mendeklarasikan penyedia tindakan untuk item tindakan, sertakan atribut android:actionProviderClass dalam elemen <item> untuk menu opsi aktivitas Anda, dengan nama class penyedia tindakan sebagai nilainya. Contoh:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

Dalam metode callback onCreateOptionsMenu() aktivitas Anda, ambil instance penyedia tindakan dari item menu dan tetapkan intent:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

Untuk contoh penggunaan ShareActionProvider, lihat ActionBarShareActionProviderActivity dalam ApiDemos.

Tampilan tindakan yang dapat diciutkan

Item tindakan yang menyediakan tampilan tindakan kini dapat beralih antara status tampilan tindakan dan status item tindakan tradisional. Sebelumnya hanya SearchView yang mendukung penyingkatan saat digunakan sebagai tampilan tindakan, tetapi kini Anda dapat menambahkan tampilan tindakan untuk item tindakan apa pun dan beralih antara status diluaskan (tampilan tindakan terlihat) dan status diciutkan (item tindakan terlihat).

Untuk mendeklarasikan bahwa item tindakan yang berisi tampilan tindakan dapat diciutkan, sertakan tanda “collapseActionView" dalam atribut android:showAsAction untuk elemen <item> di file XML menu.

Untuk menerima callback saat tampilan tindakan beralih antara diluaskan dan diciutkan, daftarkan instance MenuItem.OnActionExpandListener dengan MenuItem masing-masing dengan memanggil setOnActionExpandListener(). Biasanya, Anda harus melakukannya selama callback onCreateOptionsMenu().

Untuk mengontrol tampilan tindakan yang dapat diciutkan, Anda dapat memanggil collapseActionView() dan expandActionView() pada masing-masing MenuItem.

Saat membuat tampilan tindakan kustom, Anda juga dapat menerapkan antarmuka CollapsibleActionView baru untuk menerima callback saat tampilan diperluas dan diciutkan.

API lain untuk panel tindakan

  • setHomeButtonEnabled() memungkinkan Anda menentukan apakah ikon/logo berperilaku sebagai tombol untuk menavigasi beranda atau "atas" (teruskan "true" agar berperilaku sebagai tombol).
  • setIcon() dan setLogo() memungkinkan Anda menentukan ikon atau logo panel tindakan saat runtime.
  • Fragment.setMenuVisibility() memungkinkan Anda mengaktifkan atau menonaktifkan visibilitas item menu opsi yang dideklarasikan oleh fragmen. Hal ini berguna jika fragmen telah ditambahkan ke aktivitas, tetapi tidak terlihat, sehingga item menu harus tersembunyi.
  • FragmentManager.invalidateOptionsMenu() memungkinkan Anda membatalkan menu opsi aktivitas selama berbagai status siklus proses fragmen di mana penggunaan metode yang setara dari Activity mungkin tidak tersedia.

Antarmuka Pengguna dan Tampilan

Android 4.0 memperkenalkan beragam tampilan baru dan komponen UI lainnya.

GridLayout

GridLayout adalah kelompok tampilan baru yang menempatkan tampilan turunan dalam petak persegi panjang. Tidak seperti TableLayout, GridLayout bergantung pada hierarki datar dan tidak menggunakan tampilan perantara seperti baris tabel untuk menyediakan struktur. Sebagai gantinya, turunan menentukan baris dan kolom mana yang harus ditempati (sel dapat mencakup beberapa baris dan/atau kolom), dan secara default disusun secara berurutan di seluruh baris dan kolom petak. Orientasi GridLayout menentukan apakah turunan berurutan secara default disusun secara horizontal atau vertikal. Ruang antar-turunan dapat ditentukan menggunakan instance tampilan Space baru, atau dengan menyetel parameter margin yang relevan pada turunan.

Lihat ApiDemos untuk mengetahui contoh yang menggunakan GridLayout.

Tampilan Tekstur

TextureView adalah tampilan baru yang memungkinkan Anda menampilkan streaming konten, seperti video atau scene OpenGL. Meskipun mirip dengan SurfaceView, TextureView bersifat unik karena berperilaku seperti tampilan biasa, bukan membuat jendela terpisah, sehingga Anda dapat memperlakukannya seperti objek View lainnya. Misalnya, Anda dapat menerapkan transformasi, menganimasikannya menggunakan ViewPropertyAnimator, atau menyesuaikan opasitasnya dengan setAlpha().

Perhatikan bahwa TextureView hanya berfungsi dalam jendela dengan akselerasi hardware.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi TextureView.

Beralih widget

Widget Switch baru adalah tombol dua status yang dapat ditarik pengguna ke satu sisi atau sisi lainnya (atau cukup mengetuk) untuk mengganti opsi di antara dua status.

Anda dapat menggunakan atribut android:textOn dan android:textOff untuk menentukan teks yang akan muncul di tombol saat dalam setelan aktif dan nonaktif. Atribut android:text juga memungkinkan Anda menempatkan label di samping tombol.

Untuk contoh penggunaan tombol, lihat file tata letak switches.xml dan aktivitas Tombol masing-masing.

Android 3.0 memperkenalkan PopupMenu untuk membuat menu kontekstual pendek yang muncul pada titik link yang Anda tentukan (biasanya di titik item yang dipilih). Android 4.0 memperluas PopupMenu dengan beberapa fitur yang berguna:

Preferensi

Class abstrak TwoStatePreference baru berfungsi sebagai dasar untuk preferensi yang menyediakan opsi pemilihan dua status. SwitchPreference baru adalah ekstensi TwoStatePreference yang menyediakan widget Switch dalam tampilan preferensi untuk memungkinkan pengguna mengaktifkan atau menonaktifkan setelan tanpa perlu membuka layar atau dialog preferensi tambahan. Misalnya, aplikasi Setelan menggunakan SwitchPreference untuk setelan Wi-Fi dan Bluetooth.

Tema sistem

Tema default untuk semua aplikasi yang menargetkan Android 4.0 (dengan menetapkan targetSdkVersion atau minSdkVersion ke “14" atau yang lebih tinggi) sekarang menjadi tema "default perangkat": Theme.DeviceDefault. Ini dapat berupa tema Holo gelap atau tema gelap lain yang ditentukan oleh perangkat tertentu.

Kelompok tema Theme.Holo dijamin tidak akan berubah dari satu perangkat ke perangkat lainnya saat menjalankan versi Android yang sama. Jika Anda secara eksplisit menerapkan salah satu tema Theme.Holo ke aktivitas, Anda dapat yakin bahwa tema ini tidak akan mengubah karakter pada perangkat yang berbeda dalam versi platform yang sama.

Jika Anda ingin aplikasi menyatu dengan tema perangkat secara keseluruhan (seperti saat OEM yang berbeda menyediakan tema default yang berbeda untuk sistem), Anda harus menerapkan tema secara eksplisit dari kelompok Theme.DeviceDefault.

Tombol menu opsi

Mulai Android 4.0, Anda akan melihat bahwa handset tidak lagi memerlukan tombol perangkat keras Menu. Namun, Anda tidak perlu khawatir tentang hal ini jika aplikasi yang sudah ada menyediakan menu opsi dan mengharapkan ada tombol Menu. Untuk memastikan aplikasi yang ada terus berfungsi seperti yang diharapkan, sistem menyediakan tombol Menu di layar untuk aplikasi yang dirancang untuk versi Android yang lebih lama.

Untuk pengalaman pengguna terbaik, aplikasi baru dan yang diupdate sebaiknya menggunakan ActionBar untuk menyediakan akses ke item menu dan menetapkan targetSdkVersion ke "14" untuk memanfaatkan perilaku default framework terbaru.

Kontrol untuk visibilitas UI sistem

Sejak awal Android, sistem telah mengelola komponen UI yang disebut status bar, yang berada di bagian atas perangkat handset untuk mengirimkan informasi seperti sinyal operator, waktu, notifikasi, dan sebagainya. Android 3.0 menambahkan kolom sistem untuk perangkat tablet yang berada di bagian bawah layar untuk menyediakan kontrol navigasi sistem (Beranda, Kembali, dan sebagainya) serta antarmuka bagi elemen yang biasanya disediakan oleh status bar. Di Android 4.0, sistem menyediakan jenis UI sistem baru yang disebut menu navigasi. Anda mungkin menganggap menu navigasi sebagai versi kolom sistem yang telah disesuaikan dan dirancang untuk handset—menu navigasi memberikan kontrol navigasi untuk perangkat yang tidak memiliki hardware sejenis untuk menavigasi sistem, tetapi tidak menyertakan UI notifikasi dan kontrol setelan panel sistem. Oleh karena itu, perangkat yang menyediakan menu navigasi juga memiliki status bar di bagian atas.

Sampai hari ini, Anda dapat menyembunyikan status bar pada handset menggunakan tanda FLAG_FULLSCREEN. Di Android 4.0, API yang mengontrol visibilitas kolom sistem telah diupdate agar lebih mencerminkan perilaku kolom sistem dan menu navigasi:

  • Flag SYSTEM_UI_FLAG_LOW_PROFILE menggantikan flag STATUS_BAR_HIDDEN. Jika disetel, tanda ini akan mengaktifkan mode "profil rendah" untuk kolom sistem atau menu navigasi. Tombol navigasi redup dan elemen lain di bilah sistem juga akan disembunyikan. Mengaktifkan hal ini berguna untuk membuat game yang lebih imersif tanpa gangguan bagi tombol navigasi sistem.
  • Flag SYSTEM_UI_FLAG_VISIBLE menggantikan flag STATUS_BAR_VISIBLE untuk meminta menu sistem atau menu navigasi terlihat.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION adalah flag baru yang meminta menu navigasi disembunyikan sepenuhnya. Perlu diketahui bahwa cara ini hanya berfungsi untuk menu navigasi yang digunakan oleh beberapa handset (ini tidak menyembunyikan kolom sistem pada tablet). Menu navigasi akan kembali ke tampilan segera setelah sistem menerima input pengguna. Dengan demikian, mode ini berguna terutama untuk pemutaran video atau kasus lain yang memerlukan seluruh layar, tetapi input pengguna tidak diperlukan.

Anda dapat menetapkan setiap tanda ini untuk kolom sistem dan menu navigasi dengan memanggil setSystemUiVisibility() pada tampilan mana pun dalam aktivitas Anda. Pengelola jendela menggabungkan (ATAU bersama-sama) semua tanda dari semua tampilan di jendela dan menerapkannya ke UI sistem selama jendela Anda memiliki fokus input. Jika jendela kehilangan fokus input (pengguna keluar dari aplikasi, atau dialog muncul), flag Anda tidak akan berfungsi lagi. Demikian pula, jika Anda menghapus tampilan tersebut dari hierarki tampilan, tandanya tidak lagi berlaku.

Untuk menyinkronkan peristiwa lain dalam aktivitas Anda dengan perubahan visibilitas ke UI sistem (misalnya, sembunyikan panel tindakan atau kontrol UI lain saat UI sistem disembunyikan), Anda harus mendaftarkan View.OnSystemUiVisibilityChangeListener agar diberi tahu saat visibilitas menu sistem atau menu navigasi berubah.

Lihat kelas OverscanActivity untuk melihat demonstrasi opsi UI sistem yang berbeda.

Framework Input

Android 4.0 menambahkan dukungan untuk peristiwa pengarahan kursor kursor serta peristiwa tombol mouse dan stilus baru.

Peristiwa pengarahan kursor

Class View kini mendukung peristiwa "arahkan kursor" untuk memungkinkan interaksi yang lebih kaya melalui penggunaan perangkat pointer (seperti mouse atau perangkat lain yang menggerakkan kursor di layar).

Untuk menerima peristiwa pengarahan kursor pada tampilan, terapkan View.OnHoverListener dan daftarkan dengan setOnHoverListener(). Saat peristiwa pengarahan kursor terjadi pada tampilan, pemroses akan menerima panggilan ke onHover(), yang menyediakan View yang menerima peristiwa tersebut dan MotionEvent yang menjelaskan jenis peristiwa pengarahan kursor yang terjadi. Peristiwa pengarahan kursor dapat berupa salah satu dari hal berikut:

View.OnHoverListener akan menampilkan true dari onHover() jika menangani peristiwa pengarahan kursor. Jika pemroses Anda menampilkan nilai salah (false), peristiwa pengarahan kursor akan dikirim ke tampilan induk seperti biasa.

Jika aplikasi menggunakan tombol atau widget lain yang mengubah tampilannya berdasarkan status saat ini, Anda kini dapat menggunakan atribut android:state_hovered dalam drawable daftar status untuk menyediakan drawable latar belakang yang berbeda saat kursor diarahkan ke tampilan.

Untuk demonstrasi peristiwa pengarahan kursor yang baru, lihat class Hover di ApiDemos.

Peristiwa tombol mouse dan stilus

Android kini menyediakan API untuk menerima input dari perangkat input stilus seperti periferal tablet digitizer atau layar sentuh yang mendukung stilus.

Input stilus beroperasi dengan cara yang serupa dengan input sentuh atau mouse. Saat stilus bersentuhan dengan digitizer, aplikasi akan menerima peristiwa sentuh seperti yang terjadi saat jari digunakan untuk menyentuh layar. Saat stilus diarahkan ke atas digitizer, aplikasi akan menerima peristiwa pengarahan kursor seperti saat pointer mouse digerakkan di layar saat tidak ada tombol yang ditekan.

Aplikasi Anda dapat membedakan antara input jari, mouse, stilus, dan penghapus dengan membuat kueri "jenis alat" yang terkait dengan setiap pointer dalam MotionEvent menggunakan getToolType(). Jenis alat yang saat ini ditentukan adalah: TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS, dan TOOL_TYPE_ERASER. Dengan membuat kueri jenis alat, aplikasi Anda dapat memilih untuk menangani input stilus dengan berbagai cara, mulai dari input jari atau mouse.

Aplikasi juga dapat mengkueri tombol mouse atau stilus mana yang ditekan dengan membuat kueri “status tombol" MotionEvent menggunakan getButtonState(). Status tombol yang saat ini ditetapkan adalah: BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK, dan BUTTON_FORWARD. Untuk memudahkan, tombol mouse maju dan maju otomatis dipetakan ke tombol KEYCODE_BACK dan KEYCODE_FORWARD. Aplikasi Anda dapat menangani tombol ini untuk mendukung tombol mouse berdasarkan navigasi mundur dan maju.

Selain mengukur posisi dan tekanan kontak secara akurat, beberapa perangkat input stilus juga melaporkan jarak antara ujung stilus dan digitizer, sudut kemiringan stilus, dan sudut orientasi stilus. Aplikasi Anda dapat mengkueri informasi ini menggunakan getAxisValue() dengan kode sumbu AXIS_DISTANCE, AXIS_TILT, dan AXIS_ORIENTATION.

Untuk demonstrasi jenis alat, status tombol, dan kode sumbu baru, lihat class TouchPaint dalam ApiDemos.

Properti

Class Property yang baru menyediakan cara yang cepat, efisien, dan mudah untuk menentukan properti pada objek apa pun yang memungkinkan pemanggil untuk menetapkan/mendapatkan nilai secara umum pada objek target. Fungsi ini juga memungkinkan fungsi meneruskan referensi kolom/metode dan memungkinkan kode menetapkan/mendapatkan nilai properti tanpa mengetahui detail kolom/metode tersebut.

Misalnya, jika Anda ingin menetapkan nilai kolom bar pada objek foo, Anda perlu melakukan tindakan ini terlebih dahulu:

Kotlin

foo.bar = value

Java

foo.bar = value;

Jika ingin memanggil penyetel untuk kolom pribadi yang mendasarinya bar, Anda harus terlebih dahulu melakukan hal berikut:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Namun, jika Anda ingin meneruskan instance foo dan meminta kode lain menetapkan nilai bar, tidak ada cara untuk melakukannya sebelum Android 4.0.

Dengan menggunakan class Property, Anda dapat mendeklarasikan objek Property BAR pada class Foo sehingga Anda dapat menetapkan kolom pada instance foo class Foo seperti ini:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

Class View kini memanfaatkan class Property untuk memungkinkan Anda menetapkan berbagai kolom, seperti properti transformasi yang ditambahkan di Android 3.0 (ROTATION, ROTATION_X, TRANSLATION_X, dll.).

Class ObjectAnimator juga menggunakan class Property, sehingga Anda dapat membuat ObjectAnimator dengan Property, yang lebih cepat, lebih efisien, dan lebih aman jenisnya daripada pendekatan berbasis string.

Akselerasi Perangkat Keras

Mulai Android 4.0, akselerasi hardware untuk semua jendela diaktifkan secara default jika aplikasi Anda telah menyetel targetSdkVersion atau minSdkVersion ke “14" atau yang lebih tinggi. Akselerasi hardware umumnya menghasilkan animasi yang lebih halus, scroll yang lebih halus, dan performa serta respons yang lebih baik secara keseluruhan terhadap interaksi pengguna.

Jika perlu, Anda dapat menonaktifkan akselerasi hardware secara manual dengan atribut hardwareAccelerated untuk setiap elemen <activity> atau elemen <application>. Anda juga dapat menonaktifkan akselerasi hardware untuk setiap tampilan dengan memanggil setLayerType(LAYER_TYPE_SOFTWARE).

Untuk informasi selengkapnya tentang akselerasi hardware, termasuk daftar operasi gambar yang tidak didukung, lihat dokumen Akselerasi Hardware.

Perubahan JNI

Pada versi Android sebelumnya, referensi lokal JNI bukanlah handle tidak langsung; Android menggunakan pointer langsung. Ini bukan masalah selama pembersih sampah memori tidak memindahkan objek, tetapi tampaknya berhasil karena pembersih sampah memori dapat menulis kode yang berisi bug. Di Android 4.0, sistem kini menggunakan referensi tidak langsung untuk mendeteksi bug tersebut.

Seluk-beluk referensi lokal JNI dijelaskan dalam "Referensi Lokal dan Global" di Tips JNI. Di Android 4.0, CheckJNI telah ditingkatkan untuk mendeteksi error ini. Tonton Blog Developer Android untuk postingan mendatang tentang error umum dengan referensi JNI dan cara memperbaikinya.

Perubahan pada implementasi JNI ini hanya memengaruhi aplikasi yang menargetkan Android 4.0 dengan menetapkan targetSdkVersion atau minSdkVersion ke “14" atau yang lebih tinggi. Jika Anda telah menetapkan atribut ini ke nilai yang lebih rendah, referensi lokal JNI akan berperilaku sama seperti di versi sebelumnya.

WebKit

  • WebKit diupdate ke versi 534.30
  • Dukungan untuk font India (Devanagari, Bengali, dan Tamil, termasuk dukungan karakter kompleks yang diperlukan untuk menggabungkan glyph) di WebView dan Browser bawaan
  • Dukungan untuk font Etiopia, Georgia, dan Armenia di WebView dan Browser bawaan
  • Dukungan untuk WebDriver memudahkan Anda menguji aplikasi yang menggunakan WebView

Browser Android

Aplikasi Browser menambahkan fitur berikut untuk mendukung aplikasi web:

Izin

Berikut adalah izin baru:

Fitur Perangkat

Berikut adalah fitur perangkat baru:

  • FEATURE_WIFI_DIRECT: Mendeklarasikan bahwa aplikasi menggunakan Wi-Fi untuk komunikasi peer-to-peer.

Untuk melihat tampilan mendetail semua perubahan API di Android 4.0 (API Level 14), lihat Laporan Perbedaan API.

API sebelumnya

Selain semua hal di atas, Android 4.0 secara alami mendukung semua API dari rilis sebelumnya. Karena platform Android 3.x hanya tersedia untuk perangkat layar besar, jika Anda mengembangkan aplikasi terutama untuk handset, Anda mungkin tidak mengetahui semua API yang ditambahkan ke Android dalam rilis terbaru ini.

Berikut ini beberapa API paling penting yang mungkin Anda lewatkan dan kini juga tersedia di handset:

Android 3.0
  • Fragment: Komponen framework yang memungkinkan Anda memisahkan elemen aktivitas yang berbeda ke dalam modul mandiri yang menentukan UI dan siklus prosesnya sendiri. Lihat panduan developer Fragmen.
  • ActionBar: Penggantian untuk panel judul tradisional di bagian atas jendela aktivitas. Desain ini menyertakan logo aplikasi di sudut kiri dan memberikan antarmuka baru untuk item menu. Lihat panduan developer Panel Tindakan.
  • Loader: Komponen framework yang memfasilitasi pemuatan data secara asinkron yang dikombinasikan dengan komponen UI untuk memuat data secara dinamis tanpa memblokir thread utama. Lihat panduan developer Loader.
  • Clipboard sistem: Aplikasi dapat menyalin dan menempelkan data (lebih dari sekadar teks) ke dan dari papan klip seluruh sistem. Data yang diklip dapat berupa teks biasa, URI, atau intent. Lihat panduan developer Salin dan Tempel.
  • Tarik lalu lepas: Kumpulan API yang di-build ke dalam framework tampilan yang memfasilitasi operasi tarik lalu lepas. Lihat panduan developer Tarik lalu Lepas.
  • Framework animasi fleksibel yang baru memungkinkan Anda menganimasikan properti arbitrer dari objek apa pun (Tampilan, Drawable, Fragmen, Objek, atau lainnya) dan menentukan aspek animasi seperti durasi, interpolasi, pengulangan, dan lainnya. Framework baru ini membuat Animasi di Android menjadi lebih sederhana dari sebelumnya. Lihat panduan developer Animasi Properti.
  • Mesin komputasi dan grafis RenderScript: RenderScript menawarkan rendering grafis 3D dan API komputasi berperforma tinggi pada level native, yang Anda tulis dalam C (standar C99), yang memberikan jenis performa yang Anda harapkan dari lingkungan native, sekaligus tetap portabel di berbagai CPU dan GPU. Lihat panduan developer RenderScript.
  • Grafis 2D dengan akselerasi hardware: Kini Anda dapat mengaktifkan perender OpenGL untuk aplikasi dengan menyetel {android:hardwareAccelerated="true"} dalam elemen <application> elemen manifes atau untuk setiap elemen <activity>. Menghasilkan animasi yang lebih halus, scroll yang lebih mulus, dan performa serta respons yang lebih baik secara keseluruhan terhadap interaksi pengguna.

    Catatan: Jika Anda menyetel minSdkVersion atau targetSdkVersion aplikasi ke "14" atau yang lebih tinggi, akselerasi hardware akan diaktifkan secara default.

  • Dan masih banyak lagi. Lihat catatan Platform Android 3.0 untuk informasi selengkapnya.
Android 3.1
  • API USB: API baru yang canggih untuk mengintegrasikan periferal yang terhubung dengan aplikasi Android. API ini didasarkan pada tumpukan USB dan layanan yang di-build ke dalam platform, termasuk dukungan untuk interaksi perangkat dan host USB. Lihat panduan developer Host dan Aksesori USB.
  • MTP/PTP API: Aplikasi dapat berinteraksi langsung dengan kamera yang terhubung dan perangkat PTP lainnya untuk menerima notifikasi saat perangkat terpasang dan dihapus, mengelola file dan penyimpanan di perangkat tersebut, serta mentransfer file dan metadata ke dan dari perangkat tersebut. MTP API menerapkan subset PTP (Picture Transfer Protocol) dari spesifikasi MTP (Media Transfer Protocol). Lihat dokumentasi android.mtp.
  • RTP API: Android mengekspos API ke stack RTP (Real-time Transport Protocol) bawaannya, yang dapat digunakan aplikasi untuk mengelola streaming data interaktif atau on-demand. Secara khusus, aplikasi yang menyediakan VOIP, push-to-talk, konferensi, dan streaming audio dapat menggunakan API untuk memulai sesi dan mengirimkan atau menerima aliran data melalui jaringan yang tersedia. Lihat dokumentasi android.net.rtp.
  • Dukungan untuk joystick dan input gerakan umum lainnya.
  • Lihat catatan Platform Android 3.1 untuk API baru lainnya.
Android 3.2
  • Layar baru mendukung API yang memberi Anda lebih banyak kontrol atas cara aplikasi ditampilkan di berbagai ukuran layar. API memperluas model dukungan layar yang ada dengan kemampuan untuk menargetkan rentang ukuran layar tertentu secara tepat berdasarkan dimensi, yang diukur dalam unit piksel kepadatan mandiri (seperti lebar 600 dp atau 720 dp), bukan berdasarkan ukuran layar umum (seperti besar atau ekstra besar). Misalnya, hal ini penting untuk membantu Anda membedakan antara perangkat 5" dan perangkat 7", yang secara tradisional akan dikelompokkan sebagai layar "besar". Lihat postingan blog, Alat Baru untuk Mengelola Ukuran Layar.
  • Konstanta baru untuk <uses-feature> guna mendeklarasikan persyaratan orientasi layar lanskap atau potret.
  • Konfigurasi "ukuran layar" perangkat kini berubah selama perubahan orientasi layar. Jika aplikasi menargetkan API level 13 atau yang lebih tinggi, Anda harus menangani perubahan konfigurasi "screenSize" jika ingin menangani perubahan konfigurasi "orientation". Lihat android:configChanges untuk mengetahui informasi selengkapnya.
  • Lihat catatan Platform Android 3.2 untuk API baru lainnya.

API Level

Android 4.0 API diberi ID bilangan bulat—14—yang disimpan dalam sistem itu sendiri. ID ini, yang disebut "level API", memungkinkan sistem menentukan dengan benar apakah aplikasi kompatibel dengan sistem, sebelum menginstal aplikasi.

Untuk menggunakan API yang diperkenalkan di Android 4.0 di aplikasi, Anda perlu mengompilasi aplikasi pada platform Android yang mendukung level API 14 atau yang lebih tinggi. Bergantung pada kebutuhan, Anda mungkin juga perlu menambahkan atribut android:minSdkVersion="14" ke elemen <uses-sdk>.

Untuk mengetahui informasi selengkapnya, baca Apa itu API Level?