API Android 4.0

API Level: 14

Android 4.0 (ICE_CREAM_SANDWICH) adalah rilis platform utama yang menambahkan berbagai fitur baru untuk pengguna dan aplikasi developer. Selain semua fitur dan API baru yang dibahas di bawah ini, Android 4.0 merupakan karena menghadirkan serangkaian 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 lainnya, saat menjalankan versi Android yang sama—Android 4.0 (API level 14) atau yang lebih tinggi.

Untuk developer, platform Android 4.0 tersedia sebagai komponen yang dapat didownload untuk Android SDK. Platform yang dapat didownload mencakup library dan image sistem Android, serta serangkaian skin emulator dan lainnya. Untuk memulai pengembangan atau pengujian di Android 4.0, menggunakan Android SDK Manager untuk mendownload platform ke SDK Anda.

Ringkasan API

Bagian di bawah ini memberikan 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 kontak individual ke jejaring sosial yang diinstal di perangkat seluler.

Profil Pengguna

Android kini menyertakan profil pribadi yang mewakili pemilik perangkat, seperti yang ditentukan oleh tabel ContactsContract.Profile. Aplikasi sosial yang menjaga 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 terdapat dalam tabel kontak mentah tradisional yang ditentukan oleh Uri ContactsContract.RawContacts; sebagai gantinya, Anda harus menambahkan kontak mentah profil di tabel di CONTENT_RAW_CONTACTS_URI. Kontak mentah dalam tabel ini kemudian digabungkan ke dalam satu profil yang terlihat oleh pengguna dan diberi label "Saya".

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

Intent Undangan

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

Agar aplikasi Anda terlihat seperti dalam daftar "Tambahkan koneksi", aplikasi Anda 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 yang harus dimulai sistem saat mengirim intent undangan. Aktivitas yang dimulai kemudian bisa mengambil URI kontak yang dimaksud dari intent data dan melakukan pekerjaan yang diperlukan untuk mengundang kontak tersebut ke jaringan atau menambahkan orang itu ke terhubung dengan pengguna.

Foto besar

Android kini mendukung foto resolusi tinggi untuk kontak. Sekarang, ketika Anda mendorong foto ke catatan kontak, sistem akan memprosesnya menjadi thumbnail berukuran 96x96 (seperti yang telah dilakukan sebelumnya) dan "tampilan foto" 256x256 yang disimpan di penyimpanan foto berbasis file baru (dimensi yang pilihan sistem dapat bervariasi di masa mendatang). Anda dapat menambahkan foto besar ke kontak dengan menempatkan foto di kolom PHOTO biasa dari sebuah baris data, yang kemudian akan diproses sistem menjadi thumbnail dan tampilan foto yang sesuai {i>record<i}.

Masukan Penggunaan Kontak

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

Penyedia Kalender

API kalender baru memungkinkan Anda untuk membaca, menambah, 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 mengubah acara kalender. Namun, beberapa kasus penggunaan yang paling menarik adalah adaptor sinkronisasi yang menyinkronkan kalender pengguna dari layanan kalender lain dengan Penyedia Kalender, untuk menawarkan lokasi terpadu bagi semua acara pengguna. Acara Google Kalender, misalnya, disinkronkan dengan Penyedia Kalender dengan Adaptor Sinkronisasi Google Kalender, yang memungkinkan acara ini dilihat dengan perangkat Aplikasi Kalender.

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 data khusus kalender tidak akurat atau tidak sesuai. 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 peristiwa, seperti judul peristiwa, lokasi, waktu mulai, waktu berakhir, dan sebagainya. Peristiwa bisa terjadi satu kali atau berulang beberapa kali. Peserta, pengingat, dan properti {i>extended<i} disimpan dalam tabel terpisah dan gunakan _ID acara untuk menautkannya dengan acara.
  • Tabel CalendarContract.Instances menyimpan waktu mulai dan waktu berakhir untuk kejadian. Setiap baris dalam tabel ini mewakili satu kemunculan. Untuk acara satu kali ada pemetaan one-to-one dari instance ke peristiwa. Untuk peristiwa berulang, beberapa baris akan dibuat secara otomatis yang sesuai dengan beberapa kejadian peristiwa tersebut.
  • Tabel CalendarContract.Attendees menyimpan tamu atau tamu acara tidak akurat atau tidak sesuai. Tiap baris mewakili satu tamu kejadian. Ini menentukan tipe tamu orang dan tanggapan orang tersebut untuk peristiwa.
  • Tabel CalendarContract.Reminders menyimpan data pemberitahuan/notifikasi. Tiap baris mewakili satu peringatan untuk sebuah kejadian. Sebuah kejadian bisa memiliki beberapa pengingat. Jumlah pengingat per peristiwa ditetapkan dalam MAX_REMINDERS, yang disetel oleh adaptor sinkronisasi yang yang memiliki kalender yang ditentukan. Pengingat ditentukan dalam jumlah menit sebelum peristiwa 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 mengambil tindakan apa pun dengan item dalam tabel ini kecuali untuk menghapusnya saat peristiwa terkait 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).

Intent peristiwa

Jika yang ingin Anda lakukan 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 akses, dan Anda dapat menentukan detail acara 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. Contohnya, pengguna mungkin memiliki beberapa sumber pesan suara, seperti satu dari penyedia layanan ponsel dan lainnya dari VoIP atau suara alternatif lainnya layanan IT perusahaan mereka. Aplikasi ini dapat menggunakan Voicemail Provider API untuk menambahkan pesan suara ke perangkat. Aplikasi Ponsel bawaan kemudian menampilkan 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 satu-satunya aplikasi pihak ketiga yang seharusnya menggunakan API pesan suara adalah aplikasi yang memiliki untuk disampaikan kepada pengguna.

Class VoicemailContract menentukan penyedia konten untuk Penyedia Pesan Suara. Subclass VoicemailContract.Voicemails dan VoicemailContract.Status menyediakan tabel yang dapat digunakan aplikasi untuk menyisipkan data pesan suara untuk disimpan 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 ke hitam putih, menyesuaikan kecerahan, menyesuaikan saturasi, memutar gambar, menerapkan efek fisheye, dan banyak lagi. Sistem melakukan semua pemrosesan efek di 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 yang Anda gunakan dapat berasal dari bitmap, video, atau bahkan kamera. Namun, ada batasan tertentu yang tekstur harus memenuhi:

  1. Objek ini harus terikat dengan gambar tekstur GL_TEXTURE_2D
  2. File tersebut harus berisi minimal satu level mipmap

Objek Effect menentukan satu efek media yang dapat Anda terapkan ke bingkai 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(), dengan meneruskan 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 parameter value. Setiap jenis efek menerima parameter yang berbeda, yang didokumentasikan dengan nama efek. Misalnya, EFFECT_FISHEYE memiliki satu parameter untuk scale elemen distorsi.

Untuk menerapkan efek pada tekstur, panggil apply() pada Effect dan teruskan tekstur input, lebar dan tingginya, serta outputnya tekstur. Tekstur input harus terikat ke gambar tekstur GL_TEXTURE_2D (biasanya dilakukan dengan memanggil fungsi glTexImage2D()). Anda dapat memberikan beberapa level mipmap. Jika tekstur output tidak terikat ke elemen gambar tekstur, gambar ini akan otomatis terikat oleh efek sebagai GL_TEXTURE_2D dan dengan satu tingkat mipmap (0), yang akan memiliki ukuran sebagai 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 terlebih dahulu memeriksa apakah efek yang diinginkan dari library eksternal didukung dengan memanggil isEffectSupported().

Klien remote control

RemoteControlClient baru memungkinkan pemutar media mengaktifkan pemutaran {i>control <i}dari klien {i>remote control<i} seperti layar kunci perangkat. Pemutar media juga dapat menampilkan informasi tentang media yang sedang diputar untuk ditampilkan di remote control, seperti informasi lagu dan poster 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 mana yang dapat ditangani pemutar, Anda harus memanggil setTransportControlFlags() di 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 ACTION_MEDIA_BUTTON peristiwa saat tombol ditekan dari remote control. Intent yang Anda terima menyertakan KeyEvent untuk tombol media yang ditekan, yang dapat Anda ambil dari intent dengan getParcelableExtra(Intent.EXTRA_KEY_EVENT).

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

Untuk contoh implementasi, lihat Random Music Player, yang memberikan logika kompatibilitas sehingga mengaktifkan klien remote control di perangkat Android 4.0 sambil terus mendukung perangkat hingga 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 INTERNET izin ke manifes, jika tidak pemutaran media Anda tidak akan berfungsi mulai dari 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(). Anda kemudian dapat memulai permukaan kamera dan mulai mendeteksi wajah dengan memanggil startFaceDetection().

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

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

  • Rect yang menentukan batas wajah, relatif terhadap cakupan tampilan kamera saat ini
  • Bilangan bulat antara 1 dan 100 yang menunjukkan tingkat keyakinan sistem bahwa objek tersebut adalah wajah manusia
  • ID unik sehingga Anda dapat melacak beberapa wajah
  • Beberapa objek Point yang menunjukkan lokasi mata dan mulut ditemukan

Catatan: Deteksi wajah mungkin tidak didukung di beberapa perangkat, jadi 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, dan dalam hal ini, kolom tersebut dalam objek Camera.Face akan menjadi null.

Area fokus dan pengukuran

Aplikasi kamera kini dapat mengontrol area yang digunakan kamera untuk fokus dan untuk pengukuran warna putih keseimbangan dan eksposur otomatis. Kedua fitur tersebut menggunakan class Camera.Area baru untuk menentukan wilayah 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, maka perangkat itu tidak mendukung fitur tersebut.

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 akan dipertimbangkan untuk fokus atau pengukuran. Misalnya, Anda dapat menerapkan fitur yang memungkinkan pengguna menetapkan area fokus dengan menyentuh area pratinjau, yang kemudian Anda terjemahkan ke objek Camera.Area dan meminta kamera untuk berfokus pada area tampilan 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 Anda akan 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 mengambil gambar video, menggunakan FOCUS_MODE_CONTINUOUS_VIDEO, yang ditambahkan di 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 panggil isVideoSnapshotSupported() untuk memastikan hardware mendukungnya.
  • Anda kini dapat mengunci eksposur otomatis dan white balance dengan setAutoExposureLock() dan setAutoWhiteBalanceLock() untuk mencegah perubahan properti ini.
  • Sekarang Anda dapat memanggil setDisplayOrientation() saat pratinjau kamera berjalan. Sebelumnya, Anda dapat memanggilnya hanya sebelum memulai pratinjau, tetapi Anda kini dapat mengubah orientasinya kapan saja.

Intent siaran kamera

  • Camera.ACTION_NEW_PICTURE: Ini menunjukkan bahwa pengguna telah mengambil foto baru. Aplikasi Kamera bawaan memanggil setelah foto diambil dan aplikasi kamera pihak ketiga juga harus menyiarkan intent ini setelah mengambil foto.
  • Camera.ACTION_NEW_VIDEO: 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 (NDEF Push 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 ketika dua Perangkat berbasis Android yang mendukung Android Beam berada di jarak yang dekat (sekitar 4 cm), biasanya dengan punggung mereka bersentuhan. Data di dalam pesan NDEF dapat berisi data apa pun yang ingin Anda bagikan antar perangkat. Misalnya, aplikasi Orang membagikan kontak, YouTube membagikan video, dan Browser membagikan URL menggunakan Android Beam.

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

Jika Anda ingin menjalankan beberapa kode tertentu setelah sistem berhasil mengirimkan NDEF ke perangkat lain, Anda dapat menerapkan NfcAdapter.OnNdefPushCompleteCallback dan menyetelnya dengan setNdefPushCompleteCallback(). Sistem akan lalu panggil onNdefPushComplete() saat pesan disampaikan.

Di perangkat penerima, sistem mengirim pesan NDEF Push dengan cara yang sama seperti NFC biasa {i>tag<i}. Sistem memanggil intent dengan tindakan ACTION_NDEF_DISCOVERED untuk memulai aktivitas, dengan URL atau jenis MIME yang ditetapkan sesuai dengan NdefRecord pertama di NdefMessage. Untuk aktivitas yang ingin direspons, Anda dapat mendeklarasikan filter intent untuk URL atau jenis MIME yang penting bagi aplikasi Anda. Untuk informasi selengkapnya tentang Pengiriman Tag, lihat panduan developer NFC.

Jika ingin NdefMessage membawa URI, Anda kini dapat menggunakan metode createUri yang praktis untuk membuat NdefRecord baru berdasarkan string atau objek Uri. Jika URI format khusus yang Anda inginkan agar juga 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 "catatan aplikasi Android" dengan NdefMessage Anda di untuk menjamin bahwa aplikasi Anda menangani pesan NDEF yang masuk, meskipun aplikasi untuk tindakan intent yang sama. Anda dapat membuat data aplikasi Android dengan memanggil createApplicationRecord(), meneruskannya nama paket aplikasi Anda. Ketika perangkat lain menerima pesan NDEF dengan dan beberapa aplikasi berisi aktivitas yang menangani intent yang ditentukan, sistem akan selalu mengirimkan pesan ke aktivitas di aplikasi Anda (berdasarkan pencocokan aplikasi). Jika perangkat target saat ini belum menginstal aplikasi Anda, menggunakan catatan aplikasi Android untuk meluncurkan Google Play dan membawa pengguna ke aplikasi untuk menginstalnya.

Jika aplikasi Anda tidak menggunakan NFC API untuk melakukan pesan Push NDEF, Android akan menyediakan perilaku default: Saat aplikasi Anda berada di latar depan di satu perangkat dan Android Beam dipanggil dengan perangkat lain yang didukung Android, perangkat lain akan menerima pesan NDEF dengan data aplikasi Android yang mengidentifikasi aplikasi Anda. Jika perangkat penerima memiliki aplikasi diinstal, sistem akan meluncurkannya; jika tidak diinstal, Google Play akan terbuka dan mengambil 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 lain (sesuai dengan Wi-Fi DirectTM Wi-Fi Alliance ) tanpa koneksi internet atau hotspot. Framework Android menyediakan 1 set API Wi-Fi P2P yang memungkinkan Anda menemukan dan terhubung ke perangkat lain saat mendukung Wi-Fi P2P, kemudian berkomunikasi melalui koneksi cepat melintasi jarak yang lebih lama dari 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:

  • Melakukan inisialisasi aplikasi untuk koneksi P2P dengan memanggil initialize()
  • Temukan perangkat di sekitar dengan memanggil 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 peer berhasil atau gagal.
  • Antarmuka WifiP2pManager.PeerListListener memungkinkan Anda menerima informasi tentang peer 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 untuk menerima informasi tentang grup P2P. Callback menyediakan 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 menyediakan objek WifiP2pInfo, yang memiliki informasi seperti apakah grup telah dibentuk dan siapa pemilik grup.

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. Selain itu, lihat Demo P2P Wi-Fi contoh aplikasi.

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 monitor detak jantung, pengukur darah, termometer, dan timbangan.

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

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

  • BluetoothHealthCallback: Anda harus memperluas class ini dan menerapkan metode metode callback untuk menerima pembaruan 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 melakukan berbagai operasi seperti memulai dan mengakhiri koneksi dengan BluetoothHealth API.

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

Aksesibilitas

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

Mode Jelajahi dengan Sentuhan

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

Aksesibilitas untuk tampilan

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

Penting untuk diperhatikan terlebih dahulu bahwa perilaku metode sendAccessibilityEvent() telah berubah di Android 4.0. Seperti Android versi sebelumnya, saat pengguna mengaktifkan layanan aksesibilitas di 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 callback tambahan yang memungkinkan tampilan dan induknya untuk menambahkan lebih banyak informasi kontekstual ke peristiwa:

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

    Implementasi kustom View mungkin ingin menerapkan onInitializeAccessibilityEvent() untuk melampirkan informasi aksesibilitas tambahan ke AccessibilityEvent, tetapi juga harus memanggil implementasi super untuk menyediakan informasi default seperti deskripsi konten standar, indeks item, dan banyak lagi. 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 kemudian akan menerima panggilan ke dispatchPopulateAccessibilityEvent(), yang menunda callback onPopulateAccessibilityEvent().

    Implementasi kustom View biasanya harus menerapkan 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 akan meneruskan peristiwa ke atas hierarki tampilan dengan memanggil requestSendAccessibilityEvent() pada dan tampilan orang tua. Setiap tampilan induk memiliki kesempatan untuk menambah informasi aksesibilitas dengan menambahkan AccessibilityRecord, sampai 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 di View dengan memperluas AccessibilityDelegate dan menyetelnya pada tampilan menggunakan setAccessibilityDelegate(). Bila Anda melakukannya, setiap metode aksesibilitas dalam tampilan akan menunda panggilan ke metode terkait delegasi tersebut. Misalnya, saat menerima panggilan ke onPopulateAccessibilityEvent(), tampilan akan meneruskannya ke metode yang sama dalam View.AccessibilityDelegate. Setiap metode yang tidak ditangani oleh delegasi dikembalikan ke tampilan untuk melihat perilaku {i>default<i}. Ini memungkinkan Anda untuk mengganti metode yang diperlukan untuk tampilan tertentu tanpa memperluas class View.

Jika ingin mempertahankan kompatibilitas dengan versi Android sebelum 4.0, sekaligus mendukung API aksesibilitas baru, Anda dapat melakukannya dengan library dukungan v4 versi terbaru (di Paket Kompatibilitas, r4) menggunakan serangkaian 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. Di beberapa khususnya, peristiwa dihasilkan berdasarkan komposisi tampilan, sehingga memberikan informasi konteks dan memungkinkan layanan aksesibilitas untuk melintasi hierarki tampilan untuk mendapatkan informasi tampilan tambahan dan menangani kasus khusus.

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

  1. Setelah menerima AccessibilityEvent dari aplikasi, panggil AccessibilityEvent.getRecord() untuk mengambil AccessibilityRecord tertentu (mungkin ada beberapa data yang dilampirkan ke peristiwa).
  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 mengkueri 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 mengkueri informasi tentang peristiwa tersebut, panggil getParent() atau getChild() untuk melintasi tampilan hierarki, dan bahkan menambahkan tampilan turunan ke node.

Agar aplikasi Anda mempublikasikan dirinya ke sistem sebagai layanan aksesibilitas, harus mendeklarasikan file konfigurasi XML yang sesuai dengan AccessibilityServiceInfo. Untuk informasi selengkapnya tentang cara 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

Kerangka kerja 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 mendeklarasikan izin BIND_TEXT_SERVICE seperti yang diperlukan 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 aplikasi contoh Layanan Pemeriksa Ejaan dan aplikasi contoh Klien Pemeriksa Ejaan untuk mengetahui contoh kode.

Mesin Text-to-speech

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

Menggunakan mesin text-to-speech

Di Android versi sebelumnya, Anda dapat menggunakan class TextToSpeech untuk melakukan operasi text-to-speech (TTS) menggunakan mesin TTS yang disediakan oleh sistem atau menyetel mesin kustom menggunakan setEngineByPackageName(). Di Android 4.0, metode setEngineByPackageName() telah 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 menampilkan daftar objek TextToSpeech.EngineInfo, yang mencakup metadata seperti ikon, label, dan nama paket mesin.

Membuat mesin text-to-speech

Sebelumnya, mesin kustom mewajibkan mesin dibuat menggunakan header native yang tidak terdokumentasi . Di Android 4.0, ada serangkaian lengkap API framework untuk mem-build mesin TTS.

Penyiapan dasar memerlukan implementasi TextToSpeechService yang akan 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: Ini berisi berbagai data termasuk teks yang akan dibuat sintesanya, lokalitas, kecepatan ucapan, dan nada suara.
  • SynthesisCallback: Ini adalah antarmuka yang digunakan mesin TTS Anda untuk mengirimkan data ucapan yang dihasilkan sebagai audio streaming. Pertama, mesin harus memanggil start() untuk menunjukkan bahwa mesin siap dikirim audio, lalu panggil audioAvailable(), meneruskan data audio dalam buffer byte. Setelah mesin Anda meneruskan semua audio melalui buffer, panggil done().

Setelah framework mendukung API sejati 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 akurat 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 setiap aplikasi. Agar pengguna tidak menonaktifkan akses aplikasi ke data dari latar belakang, Anda harus mengembangkan strategi untuk menggunakan koneksi data secara efisien dan menyesuaikan penggunaan Anda bergantung pada jenis koneksi yang tersedia.

Jika aplikasi Anda melakukan banyak transaksi jaringan, Anda harus menyediakan pengaturan pengguna yang memungkinkan pengguna mengontrol kebiasaan data aplikasi Anda, seperti seberapa sering aplikasi menyinkronkan data, apakah melakukan unggahan/download hanya saat terhubung ke Wi-Fi, apakah akan menggunakan data saat roaming, dll. Dengan yang tersedia bagi mereka, kemungkinan besar pengguna menonaktifkan akses aplikasi Anda ke data ketika aplikasi Anda mendekati batasnya, karena justru dapat mengontrol dengan tepat berapa banyak data yang digunakan aplikasi Anda. Jika Anda menyediakan aktivitas preferensi dengan setelan ini, Anda harus menyertakan dalam manifesnya mendeklarasikan filter intent untuk ACTION_MANAGE_NETWORK_USAGE tindakan. 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 kepada sistem bahwa ini adalah aktivitas yang mengontrol penggunaan data aplikasi Anda. Jadi, saat pengguna memeriksa seberapa banyak data yang digunakan aplikasi Anda dari Aplikasi setelan, “Melihat setelan aplikasi" tersedia yang meluncurkan preferensi Anda sehingga pengguna dapat menyaring berapa banyak data yang digunakan aplikasi Anda.

Selain itu, berhati-hatilah karena getBackgroundDataSetting() sekarang tidak digunakan lagi dan selalu menampilkan true—gunakan getActiveNetworkInfo() sebagai gantinya. Sebelum Anda mencoba jaringan apa pun transaksi, Anda harus selalu memanggil getActiveNetworkInfo() untuk mendapatkan NetworkInfo yang mewakili jaringan saat ini dan mengkueri isConnected() untuk memeriksa apakah perangkat memiliki koneksi jarak jauh. Kemudian, Anda dapat memeriksa properti koneksi lainnya, seperti apakah perangkat roaming atau terhubung ke Wi-Fi.

Enterprise

Android 4.0 memperluas kemampuan aplikasi perusahaan dengan fitur berikut.

Layanan VPN

VpnService baru memungkinkan aplikasi mem-build VPN-nya sendiri (Virtual Jaringan Pribadi), berjalan sebagai Service. Layanan VPN membuat antarmuka untuk jaringan virtual dengan alamat dan aturan perutean sendiri serta melakukan semua operasi baca dan tulis dengan deskripsi file.

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

Karena layanan VPN dapat mencegat paket, terdapat implikasi keamanan. Dengan demikian, jika Anda menerapkan VpnService, layanan Anda harus mewajibkan BIND_VPN_SERVICE untuk memastikan bahwa hanya sistem yang dapat mengikat ke layanan tersebut (hanya sistem yang diberi izin ini—aplikasi tidak dapat memintanya). Untuk menggunakan layanan VPN Anda, 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 /> di file konfigurasi kebijakan).

Pengelolaan sertifikat

Class KeyChain yang 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 klien 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 mutlak.

Sensor suhu sebelumnya, TYPE_TEMPERATURE, telah tidak digunakan lagi. Sebaiknya gunakan sensor TYPE_AMBIENT_TEMPERATURE sebagai gantinya.

Selain itu, tiga sensor sintetis Android telah ditingkatkan secara signifikan sehingga kini memiliki latensinya & 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 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. Paling sering yang penting, sistem mengelola ukuran dan konfigurasi bilah tindakan dengan baik saat berjalan di layar yang lebih kecil untuk memberikan pengalaman pengguna yang optimal di semua ukuran layar. Misalnya, ketika layar sempit (misalnya ketika handset dalam orientasi potret), bilah tindakan tab navigasi muncul dalam “{i>stacked bar<i}”, yang muncul tepat di bawah bilah tindakan utama. Anda juga dapat memilih untuk menggunakan “panel tindakan terpisah”, yang menempatkan semua item tindakan di panel terpisah di bagian bawah layar saat layar sempit.

Memisahkan panel tindakan

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

Jika Anda ingin menggunakan tab navigasi yang disediakan oleh ActionBar.Tab API, tetapi tidak memerlukan panel tindakan utama di bagian atas (Anda hanya ingin tab 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 bilah tindakan utama, menghilang—yang tersisa hanyalah tab navigasi di bagian atas dan item tindakan di di bagian bawah layar.

Gaya panel tindakan

Jika ingin menerapkan gaya 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 {i>style<i} ini di 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. Saat 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 menyajikan tampilan tindakan dengan daftar drop-down aplikasi yang menangani intent ACTION_SEND. Saat pengguna memilih aplikasi yang akan digunakan untuk tindakan tersebut, ShareActionProvider akan mengingat pilihan itu dan memberikannya di tampilan tindakan untuk akses lebih cepat ke berbagi dengan aplikasi tersebut.

Guna mendeklarasikan penyedia tindakan untuk item tindakan, sertakan android:actionProviderClass di elemen <item> untuk menu opsi aktivitas Anda, dengan nama class tindakan provider sebagai nilai. Contoh:

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

Dalam metode callback onCreateOptionsMenu() aktivitas, 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 ViewGroupShareActionProviderActivity di 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 sekarang Anda dapat menambahkan tampilan tindakan untuk item tindakan apa pun dan beralih antara status yang diluaskan (tampilan tindakan terlihat) dan status yang diciutkan (item tindakan terlihat).

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

Untuk menerima callback saat tampilan tindakan beralih antara diperluas 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() di MenuItem masing-masing.

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

API lainnya untuk panel tindakan

  • setHomeButtonEnabled() memungkinkan Anda menentukan apakah ikon/logo berperilaku sebagai tombol untuk membuka layar utama 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 disembunyikan.
  • FragmentManager.invalidateOptionsMenu() memungkinkan Anda membatalkan validasi menu opsi aktivitas selama berbagai status siklus proses fragmen yang menggunakan metode yang setara dari Activity mungkin tidak tersedia.

Antarmuka Pengguna dan Tampilan

Android 4.0 memperkenalkan berbagai tampilan baru dan komponen UI lainnya.

GridLayout

GridLayout adalah grup tampilan baru yang menempatkan tampilan turunan dalam petak persegi panjang. Tidak seperti TableLayout, GridLayout bergantung pada hierarki dan tidak menggunakan tampilan tengah seperti baris tabel untuk menyediakan struktur. Sebagai gantinya, turunan menentukan baris dan kolom 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 menggunakan {i>default<i} yang ditata secara horizontal atau vertikal. Spasi antar-turunan dapat ditentukan dengan menggunakan instance tampilan Space baru atau dengan menetapkan parameter margin yang relevan terhadap anak-anak.

Lihat ApiDemos untuk contoh menggunakan GridLayout.

TextureView

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

Perlu diketahui bahwa TextureView hanya berfungsi dalam jendela dengan akselerasi hardware.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi TextureView.

Widget tombol alih

Widget Switch baru adalah tombol dua status yang dapat ditarik pengguna ke satu sisi atau sisi lainnya (atau cukup ketuk) untuk mengalihkan 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 {i>switch<i}.

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

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

Preferensi

Class abstrak TwoStatePreference baru berfungsi sebagai dasar untuk preferensi yang menyediakan opsi pemilihan dua negara. SwitchPreference baru adalah ekstensi dari TwoStatePreference yang menyediakan widget Switch di 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) kini menjadi tema "default perangkat": Theme.DeviceDefault. Mungkin ini adalah tema Holo gelap atau tema gelap berbeda yang ditentukan oleh perangkat tertentu.

Kelompok tema Theme.Holo dijamin tidak akan berubah dari satu perangkat ke perangkat lain 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 di perangkat yang berbeda dalam versi platform yang sama.

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

Tombol menu opsi

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

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

Kontrol untuk visibilitas UI sistem

Sejak awal Android, sistem telah mengelola komponen UI yang dikenal sebagai status bar, yang berada di bagian atas perangkat handset untuk menyampaikan informasi seperti sinyal operator, waktu, notifikasi, dan sebagainya. Android 3.0 menambahkan panel sistem untuk perangkat tablet, yang berada di bagian bawah layar untuk memberikan kontrol navigasi sistem (Beranda, Kembali, dan sebagainya) serta antarmuka untuk elemen yang biasanya disediakan oleh status bar. Di beberapa Android 4.0, sistem menyediakan jenis UI sistem baru yang disebut menu navigasi. Anda mungkin menganggap bilah navigasi sebagai versi bilah sistem yang dirancang ulang untuk handset—menyediakan kontrol navigasi untuk perangkat yang tidak memiliki perangkat keras untuk menavigasi sistem, tetapi tidak menggunakan UI notifikasi dan kontrol setelan kolom sistem. Dengan demikian, perangkat yang menyediakan navigasi juga memiliki bilah status di bagian atas.

Hingga hari ini, Anda dapat menyembunyikan status bar pada handset menggunakan tanda FLAG_FULLSCREEN. Di Android 4.0, API yang mengontrol visibilitas bilah sistem telah diperbarui untuk lebih mencerminkan perilaku bilah sistem dan bilah navigasi:

  • Flag SYSTEM_UI_FLAG_LOW_PROFILE menggantikan flag STATUS_BAR_HIDDEN. Jika disetel, tanda ini akan mengaktifkan “profil rendah" untuk bilah sistem atau di bilah navigasi sebelah atas. Tombol navigasi meredup dan elemen lain di panel sistem juga disembunyikan. Mengaktifkan hal ini berguna untuk membuat game yang lebih imersif tanpa gangguan untuk tombol navigasi sistem.
  • Flag SYSTEM_UI_FLAG_VISIBLE menggantikan flag STATUS_BAR_VISIBLE untuk meminta bilah sistem atau menu navigasi terlihat.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION adalah flag baru yang meminta menu navigasi disembunyikan sepenuhnya. Perlu diketahui bahwa setelan ini hanya berfungsi untuk menu navigasi digunakan oleh beberapa handset (tidak menyembunyikan kolom sistem pada tablet). Navigasi 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 masing-masing tanda ini untuk kolom sistem dan menu navigasi dengan memanggil setSystemUiVisibility() di tampilan mana pun dalam aktivitas Anda. Tujuan pengelola jendela menggabungkan (OR-bersama-sama) semua tanda dari semua tampilan di jendela Anda dan menerapkannya ke UI sistem selama jendela memiliki fokus input. Saat jendela kehilangan input fokus (pengguna keluar dari aplikasi Anda, atau dialog muncul), flag Anda tidak lagi berfungsi. Demikian pula, jika Anda menghapus tampilan tersebut dari hierarki tampilan, flag-nya tidak lagi berlaku.

Untuk menyinkronkan kejadian lain dalam aktivitas Anda dengan perubahan visibilitas pada UI sistem (untuk menyembunyikan bilah tindakan atau kontrol UI lain saat UI sistem disembunyikan), Anda harus mendaftarkan View.OnSystemUiVisibilityChangeListener untuk diberi tahu saat visibilitas dari perubahan bilah sistem atau {i>navigation bar<i}.

Lihat OverscanActivity untuk demonstrasi berbagai opsi UI sistem.

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 "mengarahkan 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 mendaftarkannya ke setOnHoverListener(). Saat mengarahkan kursor terjadi pada tampilan, pemroses akan menerima panggilan ke onHover(), menyediakan View yang menerima peristiwa dan MotionEvent yang menjelaskan jenis peristiwa pengarahan kursor yang terjadi. Peristiwa pengarahan kursor dapat berupa salah satu dari hal berikut:

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

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

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

Peristiwa tombol mouse dan stilus

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

Input stilus beroperasi dengan cara yang serupa dengan input sentuh atau mouse. Saat stilus bersentuhan dengan digitizer, aplikasi menerima peristiwa sentuh sama seperti ketika jari digunakan untuk sentuh layar. Saat stilus ditaruh di atas digitizer, aplikasi akan menerima pengarahan kursor peristiwa seperti ketika kursor mouse dipindahkan melintasi layar ketika tidak ada tombol ditekan.

Aplikasi Anda dapat membedakan antara input jari, mouse, stilus, dan penghapus dengan mengkueri "jenis alat" yang terkait dengan setiap pointer di MotionEvent menggunakan getToolType(). Jenis alat yang saat ini ditetapkan 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 dari input jari atau mouse.

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

Selain mengukur posisi dan tekanan kontak secara akurat, beberapa 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 di ApiDemos.

Properti

Class Property baru menyediakan cara yang cepat, efisien, dan mudah untuk menentukan properti pada objek apa pun yang memungkinkan pemanggil menetapkan/mendapatkan nilai secara umum pada objek target. Anda juga memungkinkan fungsi meneruskan referensi kolom/metode dan memungkinkan kode untuk menetapkan/mendapatkan nilai properti tanpa mengetahui detail tentang {i>field<i}/metodenya.

Misalnya, jika Anda ingin menetapkan nilai kolom bar pada objek foo, Anda perlu lakukan hal ini sebelumnya:

Kotlin

foo.bar = value

Java

foo.bar = value;

Jika ingin memanggil penyetel untuk kolom pribadi pokok bar, Anda sebelumnya akan lakukan ini:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

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

Dengan menggunakan class Property, Anda dapat mendeklarasikan objek Property BAR di class Foo sehingga Anda dapat menetapkan kolom pada instance foo dari 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 Property sehingga Anda dapat membuat ObjectAnimator dengan Property, yang lebih cepat, lebih efisien, dan lebih aman dari jenisnya daripada berbasis string pendekatan.

Akselerasi Perangkat Keras

Mulai Android 4.0, akselerasi hardware untuk semua jendela diaktifkan secara default jika aplikasi Anda telah menetapkan targetSdkVersion atau minSdkVersion ke “14" atau yang lebih tinggi. Akselerasi hardware umumnya menghasilkan animasi yang lebih halus, scroll yang lebih mulus, serta performa dan 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 masing-masing 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 bukan merupakan handle tidak langsung; Android menggunakan pointer langsung. Ini bukan masalah selama pembersih sampah memori tidak memindahkan objek, tapi itu tampaknya berfungsi karena memungkinkan untuk menulis kode yang berisi bug. Di Android 4.0, sistem sekarang menggunakan referensi tidak langsung untuk mendeteksi {i>bug<i} ini.

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

Perubahan dalam penerapan 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 berperilaku sama seperti dalam 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 tampilan mendetail dari 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, dikembangkan terutama untuk handset, maka Anda mungkin tidak mengetahui semua API yang ditambahkan ke Android dalam rilis terbaru ini.

Berikut adalah beberapa API terpenting yang mungkin Anda lewatkan dan kini tersedia pada handset:

Android 3.0
  • Fragment: Komponen framework yang memungkinkan Anda memisahkan perbedaan elemen aktivitas menjadi modul mandiri yang menentukan UI dan siklus prosesnya sendiri. Lihat panduan developer Fragment.
  • ActionBar: Penggantian untuk panel judul tradisional di bagian atas jendela Aktivitas. Ikon ini menyertakan logo aplikasi di sudut kiri dan memberikan untuk item menu. Lihat panduan developer Panel Tindakan.
  • Loader: Komponen framework yang memfasilitasi pemuatan data asinkron bersama dengan komponen UI untuk memuat data secara dinamis tanpa memblokir thread utama. Lihat Panduan developer Loader.
  • Papan klip sistem: Aplikasi dapat menyalin dan menempelkan data (tidak hanya teks) ke dan dari papan klip seluruh sistem. Data yang terpotong bisa berupa teks biasa, URI, atau intent. Lihat Panduan developer Salin dan Tempel.
  • Tarik lalu lepas: Serangkaian API yang disertakan dalam framework tampilan yang memfasilitasi tarik lalu lepas operasional bisnis. Lihat Panduan developer Tarik lalu Lepas.
  • Framework animasi baru yang fleksibel memungkinkan Anda menganimasikan properti arbitrer (Tampilan, Drawable, Fragmen, Objek, atau apa pun) dan menentukan aspek animasi seperti durasi, interpolasi, pengulangan, dan banyak lagi. Framework baru ini membuat Animasi di Android menjadi lebih sederhana. Lihat Developer Animasi Properti kami.
  • Grafis RenderScript dan mesin komputasi: RenderScript menawarkan 3D berperforma tinggi rendering grafis, dan komputasi API pada level native, yang Anda tulis dalam C (standar C99), memberikan jenis performa yang Anda harapkan dari lingkungan native sekaligus tetap portabel di berbagai CPU dan GPU. Lihat panduan developer RenderScript.
  • Grafik 2D yang dipercepat hardware: Anda kini dapat mengaktifkan perender OpenGL untuk aplikasi dengan menetapkan {android:hardwareAccelerated="true"} di elemen <application> elemen manifes atau untuk setiap elemen <activity>. Hal ini menghasilkan dalam animasi yang lebih halus, scroll yang lebih mulus, serta performa dan respons yang lebih baik secara keseluruhan interaksi.

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

  • Dan masih banyak lagi. Lihat Platform Android 3.0 catatan untuk informasi selengkapnya.
Android 3.1
  • API USB: API baru yang canggih untuk mengintegrasikan periferal yang terhubung dengan aplikasi Android. API didasarkan pada stack USB dan layanan yang yang terintegrasi ke dalam platform, termasuk dukungan untuk interaksi perangkat dan {i>host<i} 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 disambungkan dan dilepas, 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, aplikasi mana yang dapat digunakan untuk mengelola {i> on-demand<i} atau streaming data interaktif. Secara khusus, aplikasi yang menyediakan VOIP, push-to-talk, konferensi, dan streaming audio dapat menggunakan API untuk memulai sesi dan mengirim 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 mengetahui lebih banyak API baru.
Android 3.2
  • Layar baru mendukung API yang memberi Anda lebih banyak kontrol atas cara aplikasi Anda yang ditampilkan di berbagai ukuran layar. API ini memperluas model dukungan layar yang ada dengan kemampuan untuk menargetkan dengan tepat rentang ukuran layar tertentu berdasarkan dimensi, yang diukur dalam satuan piksel kepadatan mandiri (seperti lebar 600 dp atau 720 dp), bukan menurut ukuran layar (seperti besar atau ekstra besar). Misalnya, hal ini penting untuk membantu Anda membedakan antara angka 5" dan layar 7" khusus, yang secara tradisional akan dikelompokkan sebagai "besar" layar. Lihat postingan blog, Alat Baru untuk Mengelola Ukuran Layar.
  • Konstanta baru untuk <uses-feature> untuk 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 juga 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 di 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 dalam aplikasi, Anda perlu mengompilasi aplikasi terhadap platform Android yang mendukung API level 14 atau yang lebih tinggi. Bergantung pada kebutuhan, Anda mungkin juga perlu menambahkan android:minSdkVersion="14" ke atribut <uses-sdk> .

Untuk informasi selengkapnya, baca Apa yang dimaksud dengan API Tingkat?