API Level: 19
Android 4.4 (KITKAT
) adalah rilis baru untuk platform Android yang menawarkan berbagai fitur baru bagi pengguna dan developer aplikasi. Dokumen ini menyediakan pengantar untuk API baru yang paling penting.
Sebagai developer aplikasi, Anda harus mengunduh citra sistem Android 4.4 dan platform SDK dari SDK Manager secepatnya. Jika Anda tidak memiliki perangkat yang menjalankan Android 4.4 yang bisa digunakan untuk menguji aplikasi, gunakan citra sistem Android 4.4 untuk menguji aplikasi Anda pada Android Emulator. Kemudian bangun aplikasi Anda pada platform Android 4.4 untuk memulai penggunaan API terbaru.
Memperbarui target API level Anda
Untuk lebih mengoptimalkan aplikasi Anda pada perangkat yang menjalankan Android 4.4, Anda harus menyetel targetSdkVersion
ke "19"
, pasang aplikasi di citra sistem Android 4.4, lakukan pengujian, kemudian publikasikan pembaruan bersama perubahan ini.
Anda bisa menggunakan API di Android 4.4 sekaligus mendukung versi lama dengan menambahkan ketentuan ke kode yang akan memeriksa API level sistem sebelum mengeksekusi API yang tidak didukung oleh minSdkVersion
Anda. Untuk mengetahui selengkapnya tentang mempertahankan kompatibilitas mundur, baca Mendukung Versi Platform Berbeda.
Untuk informasi selengkapnya tentang cara kerja API level, baca Apa yang dimaksud dengan API Level?
Perubahan Perilaku yang Penting
Jika Anda sebelumnya telah mempublikasikan aplikasi untuk Android, ketahuilah bahwa aplikasi Anda mungkin akan terpengaruh oleh perubahan dalam Android 4.4.
Jika aplikasi Anda membaca dari storage eksternal...
Aplikasi Anda tidak bisa membaca file bersama pada storage eksternal saat dijalankan pada Android 4.4, kecuali jika aplikasi Anda memiliki izin READ_EXTERNAL_STORAGE
. Yakni, file dalam direktori yang dikembalikan oleh getExternalStoragePublicDirectory()
tidak lagi bisa diakses tanpa izin. Akan tetapi, jika Anda perlu mengakses direktori aplikasi tertentu saja, yang diberikan oleh getExternalFilesDir()
, maka Anda tidak perlu izin READ_EXTERNAL_STORAGE
.
Jika aplikasi Anda menggunakan WebView...
Perilaku aplikasi Anda mungkin berbeda saat dijalankan di Android 4.4, khususnya bila Anda memperbarui targetSdkVersion
aplikasi ke "19" atau yang lebih tinggi.
Kode yang mendasari kelas WebView
dan API terkait telah ditingkatkan versinya menjadi berdasarkan cuplikan modern dari kode sumber Chromium. Ini menghadirkan beragam peningkatan untuk kinerja, dukungan untuk fitur HTML5 baru, dan dukungan untuk debug dari jauh atas materi WebView
Anda. Dengan cakupan peningkatan versi ini berarti jika aplikasi Anda menggunakan WebView
, perilakunya mungkin akan terpengaruh dalam beberapa hal. Walaupun perubahan perilaku yang diketahui telah didokumentasikan dan umumnya memengaruhi aplikasi hanya bila Anda memperbarui targetSdkVersion
aplikasi ke "19" atau yang lebih tinggi—WebView
yang baru beroperasi dalam "mode quirks" untuk menyediakan beberapa fungsionalitas lawas dalam aplikasi yang menargetkan API level 18 dan yang lebih rendah—kemungkinan aplikasi Anda bergantung pada perilaku yang tidak dikenal dari WebView
versi sebelumnya.
Jadi jika aplikasi Anda menggunakan WebView
, Anda perlu segera mengujinya di Android 4.4 dan membaca Beralih ke WebView di Android 4.4 untuk informasi tentang bagaimana pengaruhnya pada aplikasi Anda bila memperbarui targetSdkVersion
ke "19" atau yang lebih tinggi.
Jika aplikasi Anda menggunakan AlarmManager...
Bila Anda menyetel targetSdkVersion
aplikasi ke "19" atau yang lebih tinggi, alarm yang Anda buat menggunakan set()
atau setRepeating()
akan menjadi tidak persis dengan yang semestinya.
Untuk meningkatkan efisiensi daya, Android kini menyatukan alarm dari semua aplikasi yang terjadi pada waktu-waktu yang sama sehingga sistem akan membangunkan perangkat sekali sebagai ganti beberapa kali untuk menangani setiap alarm.
Jika alarm Anda tidak dikaitkan dengan waktu jam secara persis, namun alarm Anda tetap perlu dinyalakan selama rentang waktu tertentu (misalnya antara pukul 14.00 dan 16.00), maka Anda bisa menggunakan metode setWindow()
, yang menerima waktu "paling awal" untuk alarm dan "jangka" waktu setelah waktu paling awal bagi sistem untuk menyalakan alarm.
Jika alarm Anda harus disematkan ke waktu jam secara persis (misalnya untuk pengingat acara di kalender), maka Anda bisa menggunakan metode setExact()
baru.
Perilaku batch yang tidak persis ini hanya berlaku pada aplikasi yang telah diperbarui. Jika Anda telah menyetel targetSdkVersion
ke "18" atau yang lebih rendah, alarm Anda akan terus berperilaku seperti pada versi sebelumnya saat dijalankan pada Android 4.4.
Jika aplikasi Anda menyinkronkan data menggunakan ContentResolver...
Bila Anda menyetel targetSdkVersion
aplikasi ke "19" atau yang lebih tinggi, sinkronisasi yang dibuat dengan addPeriodicSync()
akan melakukan operasi sinkronisasi dalam interval flex default sekitar 4% dari jangka waktu yang Anda tetapkan. Misalnya, jika frekuensi penjajakan adalah 24 jam, maka operasi sinkronisasi Anda mungkin akan terjadi dalam jangka waktu sekitar satu jam setiap hari, sebagai ganti waktu yang sama persis setiap hari.
Untuk menetapkan interval flex sendiri untuk operasi sinkronisasi, Anda harus memulai penggunaan metode requestSync()
baru. Untuk detail selengkapnya, lihat bagian di bawah ini tentang Adaptor Sinkronisasi.
Perilaku interval flex ini hanya berlaku pada aplikasi yang telah diperbarui. Jika Anda telah menyetel targetSdkVersion
ke "18" atau yang lebih rendah, permintaan sinkronisasi yang ada akan terus berperilaku seperti pada versi sebelumnya saat dijalankan pada Android 4.4.
Kerangka Kerja Pencetakan
Android kini menyertakan kerangka kerja lengkap yang memungkinkan pengguna untuk mencetak dokumen apa saja menggunakan printer yang terhubung melalui Wi-Fi, Bluetooth, atau layanan lainnya. Sistem akan menangani transaksi antara aplikasi yang ingin mencetak dokumen dan layanan yang akan menyerahkan tugas cetak tugas ke printer. Kerangka kerja android.print
menyediakan semua API yang diperlukan untuk menetapkan dokumen cetak dan menyerahkannya ke sistem untuk dicetak. API mana yang sebenarnya Anda perlukan untuk tugas cetak yang diberikan bergantung pada materinya.
Mencetak materi generik
Jika ingin mencetak materi dari UI sebagai dokumen, terlebih dahulu Anda perlu membuat subkelas PrintDocumentAdapter
. Dalam kelas ini, Anda harus mengimplementasikan beberapa metode callback, termasuk onLayout()
untuk menetapkan layout berdasarkan properti pencetakan yang diberikan, dan onWrite()
untuk menyerialkan materi yang bisa dicetak ke dalam ParcelFileDescriptor
.
Untuk menuliskan materi ke ParcelFileDescriptor
, Anda harus meneruskannya dalam bentuk PDF. API PdfDocument
baru menawarkan cara praktis untuk melakukannya dengan menyediakan Canvas
dari getCanvas()
, yang memungkinkan Anda bisa menggambar materi yang bisa dicetak. Kemudian tulis PdfDocument
ke ParcelFileDescriptor
dengan menggunakan metode writeTo()
.
Setelah mendefinisikan implementasi untuk PrintDocumentAdapter
, Anda bisa mengeksekusi tugas cetak atas permintaan pengguna dengan menggunakan metode PrintManager
, print()
, yang mengambil PrintDocumentAdapter
sebagai salah satu argumennya.
Mencetak gambar
Jika Anda ingin mencetak sebuah foto saja atau bitmap lainnya, maka API helper di pustaka dukungan akan melakukan semua pekerjaan itu untuk Anda. Tinggal buat sebuah instance baru PrintHelper
, setel mode skala dengan setScaleMode()
, kemudian teruskan Bitmap
ke printBitmap()
. Demikian saja. Pustaka ini menangani semua interaksi selebihnya dengan sistem untuk mengirim bitmap ke printer.
Membangun layanan cetak
Sebagai OEM printer, Anda bisa menggunakan kerangka kerja android.printservice
untuk menyediakan interoperabilitas dengan printer Anda dari perangkat Android. Anda bisa membangun dan mendistribusikan layanan cetak sebagai APK, yang bisa dipasang pengguna di perangkat mereka. Aplikasi layanan cetak terutama beroperasi sebagai layanan headless dengan mensubkelaskan kelas PrintService
, yang menerima tugas cetak dari sistem dan mengkomunikasikan tugas itu ke printernya dengan menggunakan protokol yang sesuai.
Untuk informasi selengkapnya tentang cara mencetak materi aplikasi Anda, baca Mencetak Materi.
Penyedia SMS
Penyedia materi Telephony
("Penyedia SMS") memungkinkan aplikasi membaca dan menulis pesan SMS dan MMS pada perangkat. Ini meliputi tabel untuk pesan SMS dan MMS yang diterima, dikonsep, dikirim, ditunda, dan sebagainya.
Mulai Android 4.4, setelan sistem memungkinkan pengguna untuk memilih "aplikasi SMS default". Setelah dipilih, hanya aplikasi SMS default yang dapat menulis ke Penyedia SMS dan hanya aplikasi SMS default yang menerima siaran SMS_DELIVER_ACTION
bila pengguna menerima SMS atau siaran WAP_PUSH_DELIVER_ACTION
bila pengguna menerima MMS. Aplikasi SMS default bertanggung jawab menuliskan detail ke Penyedia SMS bila menerima atau mengirim pesan baru.
Aplikasi lain yang tidak dipilih sebagai aplikasi SMS default hanya bisa membaca Penyedia SMS, namun mungkin juga diberi tahu bila ada SMS baru yang masuk dengan mendengarkan siaran SMS_RECEIVED_ACTION
, yang merupakan siaran yang tidak dapat dibatalkan dan mungkin telah dikirim ke beberapa aplikasi. Siaran ini dimaksudkan bagi aplikasi yang---bila tidak dipilih sebagai aplikasi SMS default---perlu membaca pesan masuk khusus misalnya untuk melakukan verifikasi nomor telepon.
Untuk informasi selengkapnya, baca entri blog, Mempersiapkan Aplikasi SMS Anda untuk KitKat.
Nirkabel dan Konektivitas
Emulasi kartu host
Aplikasi Android kini bisa mengemulasikan kartu NFC ISO14443-4 (ISO-DEP) yang menggunakan APDU untuk pertukaran data (seperti yang ditetapkan dalam ISO7816-4). Ini memungkinkan perangkat berkemampuan NFC yang menjalankan Android 4.4 untuk mengemulasikan beberapa kartu NFC sekaligus, dan memungkinkan terminal pembayaran NFC atau pembaca NFC lainnya menginisiasi transaksi dengan kartu NFC yang sesuai berdasarkan identifier aplikasi (AID).
Jika Anda ingin mengemulasikan kartu NFC yang menggunakan protokol ini di aplikasi Anda, buatlah komponen layanan berdasarkan kelas HostApduService
. Sedangkan jika aplikasi Anda malah menggunakan elemen aman untuk emulasi kartu, Anda perlu membuat layanan berdasarkan kelas OffHostApduService
, yang tidak secara langsung dilibatkan dalam transaksi namun perlu mendaftarkan AID yang harus ditangani oleh elemen aman.
Untuk informasi selengkapnya, baca panduan Emulasi Kartu NFC.
Mode pembaca NFC
Mode pembaca NFC yang baru memungkinkan sebuah aktivitas membatasi semua aktivitas NFC untuk membaca tipe tag yang diminati aktivitas saja saat di latar depan. Anda bisa mengaktifkan mode pembaca untuk aktivitas yang memiliki enableReaderMode()
, dengan memberikan implementasi NfcAdapter.ReaderCallback
yang menerima callback bila mendeteksi tag baru.
Kemampuan baru ini, bersama emulasi kartu host, memungkinkan Android dioperasikan pada kedua ujung antarmuka pembayaran mobile: Satu perangkat beroperasi sebagai terminal pembayaran (perangkat yang menjalankan aktivitas mode pembaca) dan perangkat yang lain beroperasi sebagai klien pembayaran (perangkat yang mengemulasikan kartu NFC).
Pemancar infra merah
Saat berjalan pada perangkat yang dilengkapi pemancar infra merah (IR), Anda kini bisa mengirimkan sinyal IR menggunakan ConsumerIrManager
API. Untuk mendapatkan instance ConsumerIrManager
, panggil getSystemService()
dengan CONSUMER_IR_SERVICE
sebagai argumen. Anda nanti bisa mengkueri frekuensi IR yang didukung perangkat dengan getCarrierFrequencies()
dan mengirimkan sinyal dengan meneruskan frekuensi dan pola sinyal yang diinginkan dengan transmit()
.
Anda harus memeriksa dahulu apakah perangkat dilengkapi pemancar IR dengan memanggil hasIrEmitter()
, namun jika aplikasi Anda hanya kompatibel dengan perangkat yang memilikinya, Anda harus menyertakan elemen <uses-feature>
dalam manifes untuk "android.hardware.consumerir"
(FEATURE_CONSUMER_IR
).
Multimedia
Pemutaran adaptif
Dukungan untuk pemutaran video adaptif kini tersedia dengan MediaCodec
API, yang memungkinkan perubahan mulus dalam resolusi selama pemutaran ke Surface
—Anda bisa mengumpan bingkai masukan dekoder resolusi baru dan resolusi buffer keluaran berubah tanpa kesenjangan yang signifikan.
Anda bisa mengaktifkan pemutaran adaptif dengan menambahkan dua kunci ke MediaFormat
yang menetapkan resolusi maksimum yang diperlukan aplikasi Anda dari codec: KEY_MAX_WIDTH
dan KEY_MAX_HEIGHT
. Dengan menambahkan ini ke MediaFormat
, teruskan MediaFormat
ke instance MediaCodec
dengan configure()
.
Codec akan bertransisi antar resolusi yang akan sama atau lebih kecil daripada nilai ini secara mulus. Codec juga mungkin mendukung resolusi yang lebih besar dari maksimum yang ditetapkan (asalkan berada dalam batas profil yang didukung), namun transisi ke resolusi lebih besar mungkin tidak akan mulus.
Untuk mengubah resolusi saat decoding video H.264, teruskan mengantre bingkai menggunakan MediaCodec.queueInputBuffer(), namun pastikan Anda memberikan nilai-nilai Sequence Parameter Set (SPS) dan Picture Parameter Set (PPS) baru bersama bingkai Instantaneous Decoder Refresh (IDR) dalam satu buffer.
Akan tetapi, sebelum mencoba mengonfigurasi codec untuk pemutaran adaptif, Anda harus memverifikasi bahwa perangkat mendukung pemutaran adaptif dengan memanggil isFeatureSupported(String)
dengan FEATURE_AdaptivePlayback
.
Catatan: Dukungan untuk pemutaran adaptif tergantung vendor. Beberapa codec mungkin memerlukan memori lebih banyak untuk petunjuk resolusi yang lebih besar. Karena itu, Anda harus menyetel maksimum resolusi berdasarkan material sumber yang sedang Anda decoding.
Stempel waktu audio sesuai kebutuhan
Untuk memfasilitasi sinkronisasi audio-video, kelas AudioTimestamp
yang baru menyediakan detail timeline tentang "bingkai" spesifik dalam aliran audio yang ditangani oleh AudioTrack
. Untuk mendapatkan stempel waktu yang terbaru, buat instance objek AudioTimestamp
dan teruskan ke getTimestamp()
. Jika permintaan stempel waktu berhasil, instance AudioTrack
akan terisi dengan posisi dalam satuan bingkai, bersama perkiraan waktu kapan bingkai itu disajikan atau diikat untuk disajikan.
Anda bisa menggunakan nilai nanoTime
di AudioTimestamp
(yang bersifat monotonik) untuk menemukan bingkai video terkait yang paling dekat dibandingkan dengan framePosition
sehingga Anda bisa memasok, menggandakan, atau menginterpolasikan bingkai video agar selaras dengan audio. Atau, Anda bisa menentukan waktu delta antara nilai nanoTime
dan perkiraan waktu bingkai video yang akan datang (dengan pertimbangan laju sampel) untuk memprediksi bingkai audio mana yang diperkirakan bertepatan waktunya dengan bingkai video.
Pembaca gambar permukaan
ImageReader
API baru memberi Anda akses langsung ke buffer gambar saat di-render ke dalam Surface
. Anda bisa memperoleh ImageReader
dengan metode statis newInstance()
. Kemudian panggil getSurface()
untuk membuat Surface
baru dan kirim data gambar Anda bersama produser, misalnya MediaPlayer
atau MediaCodec
. Agar diberi tahu kapan gambar baru tersedia dari permukaan, implementasikan antarmuka ImageReader.OnImageAvailableListener
dan daftarkan bersama setOnImageAvailableListener()
.
Kini saat Anda menggambar materi ke Surface
, ImageReader.OnImageAvailableListener
akan menerima panggilan ke onImageAvailable()
karena setiap bingkai gambar baru menjadi tersedia, sehingga memberi Anda ImageReader
yang bersangkutan. Anda bisa menggunakan ImageReader
untuk memperoleh data gambar bingkai sebagai objek Image
dengan memanggil acquireLatestImage()
atau acquireNextImage()
.
Objek Image
menyediakan akses langsung ke stempel waktu gambar, format, dimensi, dan data pikselnya dalam ByteBuffer
. Akan tetapi, agar kelas Image
dapat menafsirkan gambar Anda, kelas tersebut harus diformat sesuai dengan salah satu tipe yang didefinisikan oleh konstanta di ImageFormat
atau PixelFormat
.
Pengukuran RMS dan puncak
Anda kini bisa mengkueri puncak dan RMS aliran audio saat ini dari Visualizer
dengan membuat instance baru Visualizer.MeasurementPeakRms
dan meneruskannya ke getMeasurementPeakRms()
. Bila Anda memanggil metode ini, nilai puncak dan nilai RMS Visualizer.MeasurementPeakRms
yang diberikan akan disetel ke nilai yang terakhir diukur.
Penambah kenyaringan
LoudnessEnhancer
adalah subkelas baru AudioEffect
yang memungkinkan Anda menambah volume terdengar untuk MediaPlayer
atau AudioTrack
. Hal ini terutama berguna bersama metode baru getMeasurementPeakRms()
yang disebutkan di atas, agar dapat menambah volume track audio yang terdengar saat media lainnya diputar saat ini.
Pengontrol jarak jauh
Android 4.0 (API level 14) memperkenalkan RemoteControlClient
API yang memungkinkan aplikasi media mengonsumsi kejadian pengontrol media dari klien jauh seperti kontrol media di layar kunci. Kini, RemoteController
API baru memungkinkan Anda untuk membangun sendiri pengontrol jarak jauh, yang memungkinkan pembuatan aplikasi dan periferal baru serta inovatif yang bisa mengontrol pemutaran aplikasi media apa saja yang mengintegrasikan dengan RemoteControlClient
.
Untuk membangun pengontrol jarak jauh, Anda bisa mengimplementasikan antarmuka pengguna dengan cara apa saja yang diinginkan, namun untuk mengirim kejadian tombol media ke aplikasi media milik pengguna, Anda harus membuat sebuah layanan yang memperluas kelas NotificationListenerService
dan mengimplementasikan antarmuka RemoteController.OnClientUpdateListener
. Menggunakan NotificationListenerService
sebagai basis adalah penting karena menyediakan pembatasan privasi yang sesuai, yang mengharuskan pengguna untuk mengaktifkan aplikasi Anda sebagai listener notifikasi dalam setelan keamanan sistem.
Kelas NotificationListenerService
menyertakan sepasang metode abstrak yang harus Anda implementasikan, namun jika Anda hanya peduli dengan kejadian pengontrol media untuk menangani pemutaran media, Anda bisa mengosongkan implementasi untuk itu dan sebagai gantinya memfokuskan pada metode RemoteController.OnClientUpdateListener
.
Rating dari pengontrol jarak jauh
Android 4.4 membangun berdasarkan kemampuan yang ada untuk klien pengontrol jarak jauh (aplikasi yang menerima kejadian kontrol media bersama RemoteControlClient
) dengan menambahkan kemampuan bagi pengguna untuk menilai lagu saat ini dari pengontrol jarak jauh.
Kelas Rating
baru membungkus informasi tentang rating pengguna. Rating didefinisikan oleh gaya rating (RATING_HEART
, RATING_THUMB_UP_DOWN
, RATING_3_STARS
, RATING_4_STARS
, RATING_5_STARS
atau RATING_PERCENTAGE
) dan nilai rating yang cocok untuk gaya itu.
Untuk memungkinkan pengguna menilai lagu Anda dari pengontrol jarak jauh:
- Sinyal yang Anda inginkan untuk mengekspos UI rating ke pengguna (jika berlaku) dengan menambahkan flag
FLAG_KEY_MEDIA_RATING
disetTransportControlFlags()
. - Panggil
editMetadata()
untuk mengambilRemoteControlClient.MetadataEditor
dan teruskanRATING_KEY_BY_USER
keaddEditableKey()
. - Kemudian tetapkan gaya rating dengan memanggil
putObject()
dan meneruskanRATING_KEY_BY_USER
ke sana sebagai kunci serta salah satu gaya rating di atas sebagai nilai.
Untuk menerima callback bila pengguna mengubah rating dari pengontrol jarak jauh, implementasikan antarmuka baru RemoteControlClient.OnMetadataUpdateListener
dan teruskan instance ke setMetadataUpdateListener()
. Bila pengguna mengubah rating, RemoteControlClient.OnMetadataUpdateListener
akan menerima panggilan ke onMetadataUpdate()
, meneruskan RATING_KEY_BY_USER
sebagai kunci dan objek Rating
sebagai nilai.
Teks tertutup
VideoView
sekarang mendukung track subtitel WebVTT saat memutar video HTTP Live Stream (HLS), yang menampilkan track subjudul sesuai dengan preferensi teks tertutup yang didefinisikan pengguna dalam setelan sistem.
Anda juga bisa memberikan VideoView
bersama track subjudul WebVTT dengan menggunakan metode addSubtitleSource()
. Metode ini menerima InputStream
yang membawa data subtitel dan objek MediaFormat
yang menetapkan format untuk data subjudul, yang bisa Anda tetapkan menggunakan createSubtitleFormat()
. Subjudul ini juga muncul di atas video sesuai dengan preferensi pengguna.
Jika Anda tidak menggunakan VideoView
untuk menampilkan materi video, Anda harus menghamparkan subjudul cocok dengan preferensi teks tertutup pengguna setepat mungkin. CaptioningManager
API baru memungkinkan Anda membuat kueri atas preferensi teks tertutup pengguna, termasuk gaya yang didefinisikan oleh CaptioningManager.CaptionStyle
, misalnya bentuk huruf dan warna. Jika pengguna menyesuaikan beberapa preferensi setelah video dimulai, Anda harus mendengarkan perubahan preferensi dengan mendaftarkan instance CaptioningManager.CaptioningChangeListener
untuk menerima callback bila ada perubahan preferensi, kemudian bila perlu memperbarui subjudul.
Animasi & Grafik
Adegan dan transisi
Kerangka kerja android.transition
baru menyediakan API yang memfasilitasi animasi antar status antarmuka pengguna yang berbeda. Fitur utamanya adalah memberi Anda kemampuan untuk mendefinisikan status berbeda atas UI, yang dikenal dengan "adegan", dengan membuat layout tersendiri untuk masing-masing status. Bila Anda ingin menganimasikan dari satu adegan ke adegan lain, eksekusilah "transisi", yang akan menghitung animasi yang diperlukan untuk mengubah layout dari adegan saat ini ke adegan berikutnya.
Pada transisi antara dua adegan, biasanya Anda perlu melakukan yang berikut ini:
- Tetapkan
ViewGroup
berisi komponen UI yang ingin Anda ubah. - Tetapkan layout yang menyatakan hasil akhir perubahan tersebut (adegan berikutnya).
- Tetapkan tipe transisi yang harus menganimasikan perubahan layout.
- Eksekusilah transisi tersebut.
Anda bisa menggunakan objek Scene
untuk melakukan langkah 1 dan 2. Sebuah Scene
berisi metadata yang menjelaskan properti layout yang diperlukan untuk melakukan suatu transisi, termasuk tampilan induk adegan dan layout adegan. Anda bisa membuat Scene
menggunakan konstruktor kelas atau metode statis getSceneForLayout()
.
Kemudian Anda harus menggunakan TransitionManager
untuk melakukan langkah 3 dan 4. Salah satu cara adalah meneruskan Scene
Anda ke metode statis go()
. Ini akan menemukan tampilan induk dalam layout saat ini dan melakukan transisi pada tampilan anak agar dapat menghasilkan layout yang didefinisikan oleh Scene
.
Atau, Anda tidak perlu membuat objek Scene
sama sekali, namun sebagai gantinya bisa memanggil beginDelayedTransition()
, yang menetapkan ViewGroup
berisi tampilan yang ingin Anda ubah. Kemudian tambahkan, buang, atau konfigurasi ulang target tampilan. Setelah sistem menerapkan perubahan yang diperlukan, transisi akan mulai menganimasikan semua tampilan yang terpengaruh.
Untuk kontrol tambahan, Anda bisa mendefinisikan set transisi yang harus terjadi di antara adegan yang telah didefinisikan, dengan menggunakan file XML dalam direktori res/transition/
proyek Anda. Di dalam elemen <transitionManager>
, tetapkan satu atau beberapa tag <transition>
yang masing-masing menetapkan sebuah adegan (referensi ke file layout) dan transisi yang akan diterapkan saat memasuki dan/atau keluar dari adegan itu. Kemudian pompakan rangkaian transisi ini menggunakan inflateTransitionManager()
. Gunakan TransitionManager
yang dikembalikan untuk mengeksekusi setiap transisi dengan transitionTo()
, dengan meneruskan Scene
yang diwakili oleh salah satu tag <transition>
. Anda juga bisa mendefinisikan rangkaian transisi lewat program dengan TransitionManager
API.
Saat menetapkan transisi, Anda bisa menggunakan sejumlah tipe yang didefinisikan oleh subkelas Transition
, misalnya Fade
dan ChangeBounds
. Jika Anda tidak menetapkan tipe transisi, sistem akan menggunakan AutoTransition
secara default, yang secara otomatis akan memudarkan, menggerakkan, dan mengubah ukuran tampilan bila diperlukan. Selain itu, Anda bisa membuat transisi khusus dengan memanjangkan salah satu kelas ini untuk melakukan animasi yang diinginkan. Transisi khusus bisa melacak perubahan properti yang diinginkan, dan membuat animasi yang ingin dijadikan dasar perubahan itu. Misalnya, Anda bisa memberikan subkelas Transition
yang akan mendengarkan perubahan pada properti "rotation" dari suatu tampilan kemudian menganimasikan perubahannya.
Untuk informasi selengkapnya, lihat dokumentasi TransitionManager
.
Penghentian sementara animator
Animator
API kini memungkinkan Anda untuk menghentikan sementara dan melanjutkan animasi yang sedang berlangsung dengan metode pause()
dan resume()
.
Untuk melacak status animasi, Anda bisa mengimplementasikan antarmuka Animator.AnimatorPauseListener
, yang menyediakan callback saat animasi dihentikan sementara dan dilanjutkan: pause()
dan resume()
. Kemudian tambahkan listener ke objek Animator
dengan addPauseListener()
.
Atau, Anda bisa mensubkelaskan kelas abstrak AnimatorListenerAdapter
, yang kini menyertakan implementasi kosong untuk callback pause dan resume yang didefinisikan oleh Animator.AnimatorPauseListener
.
Bitmap yang bisa digunakan kembali
Anda kini bisa menggunakan kembali bitmap yang dapat berubah di BitmapFactory
untuk dekode bitmap lain—bahkan bila bitmap baru berbeda ukurannya---asalkan jumlah byte hasil dekode bitmap (tersedia dari getByteCount()
) kurang dari atau sama dengan jumlah byte yang dialokasikan untuk bitmap yang digunakan kembali (tersedia dari getAllocationByteCount()
. Untuk informasi selengkapnya, lihat inBitmap
.
API baru untuk Bitmap
memungkinkan konfigurasi ulang serupa untuk digunakan kembali di luar BitmapFactory
(untuk menghasilkan bitmap manual atau logika decoding khusus). Anda kini bisa menyetel dimensi bitmap dengan metode setHeight()
dan setWidth()
, dan menetapkan Bitmap.Config
baru dengan setConfig()
tanpa memengaruhi alokasi bitmap yang mendasarinya. Metode reconfigure()
juga menyediakan cara praktis untuk mengombinasikan semua perubahan ini dengan satu panggilan.
Akan tetapi, Anda tidak boleh mengonfigurasi ulang bitmap yang saat ini digunakan oleh sistem tampilan, karena buffer piksel yang mendasarinya tidak akan dipetakan kembali dalam cara yang dapat diprediksi.
Materi Pengguna
Storage Access Framework
Pada Android versi sebelumnya, jika Anda ingin aplikasi mengambil tipe file tertentu dari aplikasi lain, maka aplikasi itu harus meminta maksud dengan tindakan ACTION_GET_CONTENT
. Tindakan ini masih menjadi cara yang tepat untuk meminta file yang ingin Anda impor ke dalam aplikasi. Akan tetapi, Android 4.4 memperkenalkan tindakan ACTION_OPEN_DOCUMENT
, yang memungkinkan pengguna memilih file tipe tertentu dan memberikan akses baca jangka panjang pada aplikasi Anda ke file itu (mungkin dengan akses tulis) tanpa mengimpor file tersebut ke aplikasi Anda.
Jika Anda sedang mengembangkan aplikasi yang menyediakan layanan storage untuk file (misalnya layanan storage di awan), Anda bisa menyertakan UI seragam ini untuk memilih file dengan mengimplementasikan penyedia materi sebagai subkelas dari kelas baru DocumentsProvider
. Subkelas DocumentsProvider
Anda harus menyertakan filter maksud yang menerima tindakan PROVIDER_INTERFACE
("android.content.action.DOCUMENTS_PROVIDER"
). Kemudian Anda harus mengimplementasikan empat metode abstrak di DocumentsProvider
:
queryRoots()
- Ini harus mengembalikan
Cursor
yang menjelaskan semua direktori akar storage dokumen Anda, dengan menggunakan kolom yang didefinisikan dalamDocumentsContract.Root
. queryChildDocuments()
- Ini harus mengembalikan
Cursor
yang menjelaskan semua file dalam direktori yang ditetapkan, dengan menggunakan kolom yang didefinisikan dalamDocumentsContract.Document
. queryDocument()
- Ini harus mengembalikan
Cursor
yang menjelaskan file yang ditetapkan, dengan menggunakan kolom yang didefinisikan dalamDocumentsContract.Document
. openDocument()
- Ini harus mengembalikan
ParcelFileDescriptor
yang mewakili file yang ditetapkan. Sistem memanggil metode ini setelah pengguna memilih file dan aplikasi klien meminta akses ke file itu dengan memanggilopenFileDescriptor()
.
Untuk informasi selengkapnya, lihat panduan Storage Access Framework.
Akses storage eksternal
Anda kini bisa membaca dan menulis file spesifik aplikasi pada media storage eksternal sekunder, misalnya bila perangkat menyediakan storage emulasi maupun kartu SD. Metode baru getExternalFilesDirs()
sama fungsinya dengan metode getExternalFilesDir()
yang ada, hanya saja ia mengembalikan larik objek File
. Sebelum membaca atau menulis ke jalur yang dikembalikan oleh metode ini, teruskan objek File
ke metode baru getStorageState()
untuk memverifikasi storage yang tersedia saat ini.
Metode lainnya untuk mengakses direktori cache aplikasi spesifik dan direktori OBB kini juga memiliki versi yang menyediakan akses ke perangkat storage sekunder: getExternalCacheDirs()
dan getObbDirs()
.
Entri pertama dalam larik File
yang dikembalikan dianggap storage eksternal utama perangkat, yang sama dengan File
yang dikembalikan oleh metode yang ada, misalnya getExternalFilesDir()
.
Catatan: Mulai Android 4.4, platform tidak lagi mengharuskan aplikasi Anda memperoleh WRITE_EXTERNAL_STORAGE
atau READ_EXTERNAL_STORAGE
bila Anda hanya perlu mengakses region aplikasi spesifik pada storage eksternal dengan menggunakan metode di atas. Akan tetapi, izin diperlukan jika Anda ingin mengakses region yang dapat dibagikan pada storage eksternal, yang disediakan oleh getExternalStoragePublicDirectory()
.
Adaptor sinkronisasi
Metode baru requestSync()
dalam ContentResolver
menyederhanakan sebagian prosedur untuk mendefinisikan permintaan sinkronisasi bagi ContentProvider
dengan membungkus permintaan dalam objek baru SyncRequest
, yang bisa Anda buat dengan SyncRequest.Builder
. Properti dalam SyncRequest
menyediakan fungsionalitas yang sama dengan panggilan sinkronisasi ContentProvider
yang ada, namun menambahkan kemampuan untuk menetapkan bahwa sinkronisasi harus ditahan jika menggunakan jaringan berkuota, dengan mengaktifkan setDisallowMetered()
.
Masukan Pengguna
Tipe sensor baru
Sensor baru TYPE_GEOMAGNETIC_ROTATION_VECTOR
menyediakan data vektor rotasi berdasarkan magnetometer, yang menjadi alternatif berguna untuk sensor TYPE_ROTATION_VECTOR
bila giroskop tidak tersedia atau bila digunakan bersama kejadian sensor batch untuk merekam orientasi perangkat saat ponsel sedang tidur. Sensor ini memerlukan daya lebih sedikit daripada TYPE_ROTATION_VECTOR
, namun mungkin cenderung pada data kejadian yang berisik dan paling efektif saat pengguna berada di luar ruangan.
Android kini juga mendukung sensor langkah bawaan di perangkat keras:
TYPE_STEP_DETECTOR
- Sensor ini memicu kejadian setiap kali pengguna mengambil langkah. Pada setiap langkah pengguna, sensor ini akan menyampaikan kejadian bersama nilai 1.0 dan stempel waktu yang menunjukkan kapan langkah tersebut terjadi.
TYPE_STEP_COUNTER
- Sensor ini juga memicu kejadian pada setiap langkah yang terdeteksi, namun sebagai ganti menyampaikan jumlah total akumulasi langkah sejak sensor ini pertama didaftarkan oleh aplikasi.
Ketahuilah bahwa kedua sensor langkah ini tidak selalu mengirimkan hasil yang sama. Kejadian TYPE_STEP_COUNTER
terjadi bersama latensi yang lebih tinggi daripada yang berasal dari TYPE_STEP_DETECTOR
, namun itu karena algoritme TYPE_STEP_COUNTER
melakukan pemrosesan lebih banyak untuk menghilangkan alarm palsu. Jadi TYPE_STEP_COUNTER
mungkin menjadi lebih lambat mengirim kejadian, namun hasilnya seharusnya menjadi lebih akurat.
Kedua sensor langkah bergantung pada perangkat keras (Nexus 5 adalah perangkat yang mendukungnya), jadi Anda harus memeriksa ketersediaannya dengan hasSystemFeature()
, dengan menggunakan konstanta FEATURE_SENSOR_STEP_DETECTOR
dan FEATURE_SENSOR_STEP_COUNTER
.
Kejadian sensor batch
Agar lebih baik dalam mengelola daya perangkat, SensorManager
API kini memungkinkan Anda menetapkan frekuensi yang akan digunakan sistem untuk mengirim batch kejadian sensor ke aplikasi Anda. Hal ini tidak mengurangi jumlah kejadian sensor sesungguhnya yang tersedia untuk aplikasi Anda selama jangka waktu yang diberikan, namun sebagai gantinya akan mengurangi frekuensi yang digunakan sistem untuk memanggil SensorEventListener
bersama pembaruan sensor. Yakni, sebagai ganti mengirim setiap kejadian ke aplikasi Anda pada saat terjadi, sistem akan menyimpan semua kejadian yang terjadi dalam jangka waktu tertentu, kemudian menyampaikannya ke aplikasi Anda sekaligus.
Untuk menyediakan batching, kelas SensorManager
menambahkan dua versi baru metode registerListener()
yang memungkinkan Anda menetapkan "latensi laporan maksimum". Parameter baru ini menetapkan penundaan maksimum yang akan ditoleransi oleh SensorEventListener
untuk pengiriman kejadian sensor baru. Misalnya, jika Anda menetapkan latensi batch selama satu menit, sistem akan mengirim set kejadian batch terbaru pada interval tidak lebih dari satu menit dengan membuat panggilan berurutan ke metode onSensorChanged()
Anda—sekali untuk setiap kejadian yang dibundel. Kejadian sensor tidak akan pernah ditunda lebih lama dari nilai latensi laporan maksimum Anda, namun mungkin tiba lebih cepat jika aplikasi lain meminta latensi lebih singkat untuk sensor yang sama.
Akan tetapi, ketahuilah bahwa sensor akan mengirimi aplikasi Anda batch kejadian berdasarkan latensi laporan hanya setelah CPU bangun. Walaupun sensor perangkat keras yang mendukung batch akan terus mengumpulkan kejadian sensor saat CPU sedang tidur, ia tidak akan membangunkan CPU untuk mengirim batch kejadian ke aplikasi Anda. Bila sensor akhirnya kehabisan memorinya untuk kejadian, ia akan mulai menahan kejadian terlama agar dapat menyimpan kejadian terbaru. Anda bisa menghindari hilangnya kejadian dengan membangunkan perangkat sebelum sensor mengisi memorinya kemudian memanggil flush()
untuk merekam batch kejadian terbaru. Untuk memperkirakan kapan memori akan penuh dan harus dikosongkan, panggil getFifoMaxEventCount()
untuk mendapatkan jumlah maksimum kejadian sensor yang bisa disimpannya, dan bagi jumlah itu dengan kecepatan yang diinginkan aplikasi Anda untuk setiap kejadian. Gunakan perhitungan itu untuk menyetel alarm bangun dengan AlarmManager
yang akan memanggil Service
(yang mengimplementasikan SensorEventListener
) untuk mengosongkan sensor.
Catatan: Tidak semua perangkat mendukung kejadian sensor batch karena memerlukan dukungan dari sensor perangkat keras. Akan tetapi, mulai Android 4.4, Anda harus selalu menggunakan metode baru registerListener()
, karena jika perangkat tidak mendukung batch, maka sistem akan mengabaikan begitu saja argumen latensi batch dan menyampaikan kejadian sensor secara real-time.
Identitas pengontrol
Android kini mengidentifikasi pengontrol yang dihubungkan dengan integer unik yang bisa Anda kueri dengan getControllerNumber()
, sehingga memudahkan Anda mengaitkan setiap pengontrol ke pemain yang berbeda dalam game. Nomor untuk setiap pengontrol mungkin berubah karena pengontrol telah dilepas, dihubungkan, atau dikonfigurasi ulang oleh pengguna, jadi Anda harus melacak nomor pengontrol mana yang menyangkut setiap perangkat masukan dengan mendaftarkan sebuah instance InputManager.InputDeviceListener
. Kemudian panggil getControllerNumber()
untuk setiap InputDevice
bila terjadi perubahan.
Perangkat yang terhubung kini juga memberikan ID vendor dan produk yang tersedia dari getProductId()
dan getVendorId()
. Jika Anda perlu memodifikasi pemetaan kunci berdasarkan set kunci yang tersedia pada perangkat, Anda bisa melakukan kueri terhadap perangkat untuk memeriksa apakah kunci tertentu tersedia dengan hasKeys(int...)
.
Antarmuka Pengguna
Mode layar penuh yang mendalam
Untuk melengkapi aplikasi Anda dengan layout yang mengisi seluruh layar, flag baru SYSTEM_UI_FLAG_IMMERSIVE
untuk setSystemUiVisibility()
(bila dikombinasikan dengan SYSTEM_UI_FLAG_HIDE_NAVIGATION
) akan memungkinkan mode layar penuh baru yang mendalam. Saat mode layar penuh yang mendalam diaktifkan, aktivitas Anda akan terus menerima semua kejadian sentuh. Pengguna bisa mengetahui bilah sistem dengan menggesek ke arah dalam di sepanjang region yang biasanya menjadi tempat munculnya bilah sistem. Ini akan menghapus flag SYSTEM_UI_FLAG_HIDE_NAVIGATION
(dan flag SYSTEM_UI_FLAG_FULLSCREEN
, jika berlaku) jadi bilah sistem tetap terlihat. Akan tetapi, jika Anda ingin bilah sistem disembunyikan lagi setelah beberapa saat, sebagai gantinya Anda bisa menggunakan flag SYSTEM_UI_FLAG_IMMERSIVE_STICKY
.
Bilah sistem tembus pandang
Anda kini bisa membuat bilah sistem tembus pandang sebagian dengan tema-tema baru, Theme.Holo.NoActionBar.TranslucentDecor
dan Theme.Holo.Light.NoActionBar.TranslucentDecor
. Dengan mengaktifkan bilah sistem tembus pandang, layout Anda akan mengisi area di belakang bilah sistem, sehingga Anda juga harus mengaktifkan fitsSystemWindows
untuk bagian layout yang tidak boleh ditutupi oleh bilah sistem.
Jika Anda sedang membuat tema khusus, setel salah satu tema ini sebagai tema induk atau sertakan properti gaya windowTranslucentNavigation
dan windowTranslucentStatus
dalam tema.
Listener notifikasi yang disempurnakan
Android 4.3 telah menambahkan NotificationListenerService
API, yang memungkinkan aplikasi menerima informasi tentang notifikasi baru bila telah diposkan oleh sistem. Di Android 4.4, listener notifikasi bisa mengambil metadata tambahan untuk notifikasi dan detail lengkap tentang tindakan notifikasi:
Bidang Notification.extras
baru menyertakan sebuah Bundle
untuk mengirim metadata tambahan ke pembangun notifikasi, misalnya EXTRA_TITLE
dan EXTRA_PICTURE
. Kelas baru Notification.Action
mendefinisikan karakteristik tindakan yang dilampirkan ke notifikasi, yang bisa Anda ambil dari bidang actions
baru.
Pencerminan dapat digambar untuk layout RTL
Pada Android versi sebelumnya, jika aplikasi Anda menyertakan gambar yang harus dibalik orientasi horizontalnya untuk layout kanan ke kiri, Anda harus menyertakan gambar yang dicerminkan dalam direktori sumber daya drawables-ldrtl/
. Kini, sistem secara otomatis bisa mencerminkan gambar dengan mengaktifkan atribut autoMirrored
pada sumber daya dapat digambar atau dengan memanggil setAutoMirrored()
. Bila diaktifkan, Drawable
secara otomatis akan dicerminkan bila arah layout adalah kanan ke kiri.
Aksesibilitas
Kelas View
kini memungkinkan Anda mendeklarasikan "region yang selalu berubah" untuk bagian UI yang secara dinamis diperbarui dengan materi teks baru, dengan menambahkan atribut baru accessibilityLiveRegion
ke layout XML layout atau dengan memanggil setAccessibilityLiveRegion()
. Misalnya, layar masuk dengan bidang teks yang menampilkan notifikasi "sandi salah" harus ditandai sebagai region yang selalu berubah, sehingga pembaca layar akan membacakan pesan bila berubah.
Aplikasi yang menyediakan layanan aksesibilitas kini juga bisa menyempurnakan kemampuannya dengan API baru yang menyediakan informasi tentang kumpulan tampilan, misalnya tampilan berupa daftar atau petak dengan menggunakan AccessibilityNodeInfo.CollectionInfo
dan AccessibilityNodeInfo.CollectionItemInfo
.
Izin Aplikasi
Berikut ini adalah izin-izin baru yang harus diminta aplikasi Anda dengan tag <uses-permission>
untuk menggunakan API baru tertentu:
INSTALL_SHORTCUT
- Memungkinkan aplikasi memasang pintasan di Peluncur
UNINSTALL_SHORTCUT
- Memungkinkan aplikasi mencopot pemasangan pintasan di Peluncur
TRANSMIT_IR
- Memungkinkan aplikasi menggunakan pemancar IR di perangkat, jika tersedia
Catatan: Mulai Android 4.4, platform tidak lagi mengharuskan aplikasi Anda memperoleh WRITE_EXTERNAL_STORAGE
atau READ_EXTERNAL_STORAGE
bila Anda ingin mengakses region aplikasi spesifik pada storage eksternal dengan menggunakan metode seperti getExternalFilesDir()
. Akan tetapi, izin tetap diperlukan jika Anda ingin mengakses region yang dapat dibagikan pada storage eksternal, yang disediakan oleh getExternalStoragePublicDirectory()
.
Fitur Perangkat
Berikut ini adalah fitur baru perangkat yang bisa Anda deklarasikan dengan tag <uses-feature>
untuk mendeklarasikan persyaratan aplikasi Anda dan mengaktifkan pemfilteran pada Google Play atau pemeriksaan pada waktu proses:
FEATURE_CONSUMER_IR
- Perangkat mampu berkomunikasi dengan perangkat IR konsumen.
FEATURE_DEVICE_ADMIN
- Perangkat mendukung pemberlakuan kebijakan perangkat lewat administrator perangkat.
FEATURE_NFC_HOST_CARD_EMULATION
- Perangkat mendukung emulasi kartu NFC berbasis host.
FEATURE_SENSOR_STEP_COUNTER
- Perangkat menyertakan penghitung langkah perangkat keras.
FEATURE_SENSOR_STEP_DETECTOR
- Perangkat menyertakan detektor langkah perangkat keras.
Untuk melihat tampilan detail semua perubahan API di Android 4.4, lihat Laporan Perbedaan API.