Level API: 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 mendownload image sistem dan platform SDK Android 4.4 dari SDK Manager sesegera mungkin. Jika Anda tidak memiliki perangkat yang menjalankan Android 4.4 untuk menguji aplikasi, gunakan image sistem Android 4.4 untuk menguji aplikasi di Android emulator. Kemudian, bangun aplikasi Anda pada platform Android 4.4 untuk mulai menggunakan API terbaru.
Memperbarui target API level Anda
Untuk lebih mengoptimalkan aplikasi pada perangkat yang menjalankan Android 4.4,
Anda harus menyetel targetSdkVersion
ke
"19"
, menginstalnya di image sistem Android 4.4,
mengujinya, lalu memublikasikan update dengan perubahan ini.
Anda dapat menggunakan API di Android 4.4 sekaligus mendukung versi lama dengan menambahkan
kondisi ke kode yang akan memeriksa level API sistem sebelum mengeksekusi
API yang tidak didukung oleh minSdkVersion
Anda.
Untuk mempelajari lebih lanjut cara mempertahankan kompatibilitas mundur, baca Mendukung Versi
Platform yang Berbeda.
Untuk mengetahui informasi selengkapnya tentang cara kerja API level, baca Apa itu API Level?
Perubahan Perilaku yang Penting
Jika sebelumnya Anda telah memublikasikan aplikasi untuk Android, perlu diketahui bahwa aplikasi Anda mungkin terpengaruh oleh perubahan dalam Android 4.4.
Jika aplikasi Anda membaca dari penyimpanan eksternal...
Aplikasi Anda tidak dapat membaca file bersama di penyimpanan eksternal saat dijalankan di Android 4.4, kecuali jika aplikasi memiliki izin READ_EXTERNAL_STORAGE
. Artinya, file dalam direktori yang ditampilkan oleh getExternalStoragePublicDirectory()
tidak dapat diakses lagi tanpa izin. Namun, jika perlu mengakses direktori khusus aplikasi saja, yang disediakan oleh getExternalFilesDir()
, Anda tidak memerlukan izin READ_EXTERNAL_STORAGE
.
Jika aplikasi Anda menggunakan WebView...
Perilaku aplikasi Anda mungkin berbeda saat menjalankan Android 4.4, terutama saat Anda mengupdate targetSdkVersion
aplikasi ke "19" atau yang lebih baru.
Kode yang mendasari class WebView
dan API terkait telah diupgrade agar didasarkan pada snapshot modern kode sumber Chromium. Ini menghadirkan berbagai peningkatan untuk performa, dukungan untuk fitur HTML5 baru, dan dukungan untuk proses debug jarak jauh terhadap konten WebView
Anda. Cakupan upgrade ini berarti jika aplikasi Anda menggunakan WebView
, perilakunya mungkin akan terpengaruh dalam beberapa kasus. Meskipun perubahan perilaku yang diketahui didokumentasikan dan sebagian besar memengaruhi aplikasi Anda hanya saat Anda mengupdate targetSdkVersion
aplikasi ke "19" atau yang lebih tinggi—WebView
yang baru beroperasi dalam "mode quirks" untuk menyediakan beberapa fungsi lama di aplikasi yang menargetkan API level 18 dan yang lebih rendah—mungkin saja aplikasi Anda bergantung pada perilaku yang tidak diketahui dari WebView
versi sebelumnya.
Jadi, jika aplikasi Anda yang sudah ada menggunakan WebView
, Anda harus melakukan pengujian di Android 4.4 sesegera mungkin dan membaca Bermigrasi ke WebView di Android 4.4 untuk mengetahui informasi tentang kemungkinan pengaruhnya terhadap aplikasi Anda saat mengupdate targetSdkVersion
ke "19" atau yang lebih baru.
Jika aplikasi Anda menggunakan AlarmManager...
Jika Anda menyetel targetSdkVersion
aplikasi ke "19" atau yang lebih tinggi, alarm yang Anda buat menggunakan set()
atau setRepeating()
tidak akan tepat.
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 tidak terkait dengan waktu jam yang tepat, tetapi alarm tetap harus dipanggil selama rentang waktu tertentu (seperti antara pukul 14.00 dan 16.00), Anda dapat menggunakan metode setWindow()
baru, yang menerima waktu "terawal" untuk alarm dan "jendela" waktu setelah waktu paling awal saat sistem harus memanggil alarm.
Jika alarm harus disematkan ke waktu jam yang tepat (misalnya untuk pengingat acara kalender), Anda dapat 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 akan terus berperilaku seperti di versi sebelumnya saat dijalankan di Android 4.4.
Jika aplikasi Anda menyinkronkan data menggunakan ContentResolver...
Saat Anda menyetel targetSdkVersion
aplikasi ke "19" atau lebih tinggi, membuat sinkronisasi dengan addPeriodicSync()
akan melakukan operasi sinkronisasi dalam interval fleksibel default sekitar 4% dari periode yang Anda tentukan. 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 menentukan interval fleksibel Anda sendiri untuk operasi sinkronisasi, Anda harus mulai menggunakan metode requestSync()
yang baru. Untuk detail selengkapnya, lihat bagian di bawah 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 di 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. Framework android.print
menyediakan semua API yang diperlukan untuk menentukan dokumen cetak dan mengirimkannya ke sistem untuk dicetak. API mana yang sebenarnya Anda perlukan untuk tugas cetak yang diberikan bergantung pada materinya.
Mencetak materi generik
Jika ingin mencetak konten dari UI sebagai dokumen, Anda harus membuat subclass PrintDocumentAdapter
terlebih dahulu. Dalam class ini, Anda harus mengimplementasikan beberapa metode callback, termasuk onLayout()
untuk membuat tata letak berdasarkan properti pencetakan yang disediakan, dan onWrite()
untuk membuat serialisasi konten yang dapat dicetak menjadi ParcelFileDescriptor
.
Untuk menulis konten ke ParcelFileDescriptor
, Anda harus meneruskannya dalam bentuk PDF. PdfDocument
API yang baru menawarkan cara yang mudah untuk melakukannya dengan menyediakan Canvas
dari getCanvas()
, yang dapat Anda gunakan untuk menggambar konten yang dapat dicetak. Kemudian, tulis PdfDocument
ke ParcelFileDescriptor
menggunakan metode writeTo()
.
Setelah menentukan implementasi untuk PrintDocumentAdapter
, Anda dapat menjalankan tugas pencetakan atas permintaan pengguna menggunakan metode PrintManager
, print()
, yang menggunakan 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. Cukup buat instance PrintHelper
baru, setel mode skala dengan setScaleMode()
, lalu teruskan Bitmap
ke printBitmap()
. Selesai. Pustaka ini menangani semua interaksi selebihnya dengan sistem untuk mengirim bitmap ke printer.
Membangun layanan cetak
Sebagai OEM printer, Anda dapat menggunakan framework android.printservice
untuk menyediakan interoperabilitas dengan printer dari perangkat Android. Anda bisa membangun dan mendistribusikan layanan cetak sebagai APK, yang bisa dipasang pengguna di perangkat mereka. Aplikasi layanan cetak beroperasi terutama sebagai layanan headless dengan membuat subclass dari class PrintService
, yang menerima tugas cetak dari sistem dan mengomunikasikan tugas tersebut ke printernya menggunakan protokol yang sesuai.
Untuk mengetahui informasi selengkapnya tentang cara mencetak konten aplikasi Anda, baca Mencetak Konten.
Penyedia SMS
Penyedia konten Telephony
("Penyedia SMS") memungkinkan aplikasi membaca dan menulis pesan SMS dan MMS di perangkat. Ini meliputi tabel untuk pesan SMS dan MMS yang diterima, dikonsep, dikirim, ditunda, dan sebagainya.
Mulai Android 4.4, setelan sistem memungkinkan pengguna 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
saat pengguna menerima SMS atau siaran WAP_PUSH_DELIVER_ACTION
saat 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 dapat membaca Penyedia SMS, tetapi mungkin juga diberi tahu saat SMS baru masuk dengan mendengarkan siaran SMS_RECEIVED_ACTION
, yang merupakan siaran yang tidak dapat dibatalkan yang mungkin dikirimkan 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 postingan blog, Menyiapkan Aplikasi SMS 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 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 mengemulasi kartu NFC yang menggunakan protokol ini di aplikasi Anda, buat komponen layanan berdasarkan class HostApduService
. Sementara itu, jika aplikasi Anda menggunakan elemen pengaman untuk emulasi kartu, Anda perlu membuat layanan berdasarkan class OffHostApduService
, yang tidak akan terlibat langsung dalam transaksi tetapi diperlukan untuk mendaftarkan AID yang harus ditangani oleh elemen pengaman.
Untuk mengetahui 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 dapat mengaktifkan mode pembaca untuk aktivitas dengan enableReaderMode()
, yang menyediakan implementasi NfcAdapter.ReaderCallback
yang menerima callback saat tag baru terdeteksi.
Kemampuan baru ini, bersama dengan emulasi kartu host, memungkinkan Android beroperasi di kedua ujung antarmuka pembayaran seluler: Satu perangkat beroperasi sebagai terminal pembayaran (perangkat yang menjalankan aktivitas mode pembaca) dan perangkat lainnya beroperasi sebagai klien pembayaran (perangkat yang mengemulasi kartu NFC).
Pemancar inframerah
Saat berjalan di perangkat yang menyertakan pemancar inframerah (IR), Anda kini dapat mengirimkan sinyal IR menggunakan ConsumerIrManager
API. Untuk mendapatkan instance ConsumerIrManager
, panggil getSystemService()
dengan CONSUMER_IR_SERVICE
sebagai argumen. Kemudian, Anda dapat mengkueri frekuensi IR yang didukung perangkat dengan getCarrierFrequencies()
dan mengirimkan sinyal dengan meneruskan frekuensi dan pola sinyal yang diinginkan menggunakan transmit()
.
Anda harus selalu memeriksa terlebih dahulu apakah perangkat menyertakan pemancar IR dengan memanggil hasIrEmitter()
, tetapi 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 resolusi yang lancar selama pemutaran ke Surface
—Anda dapat memberikan feed frame input decoder dengan resolusi baru dan resolusi buffer output berubah tanpa kesenjangan yang signifikan.
Anda dapat mengaktifkan pemutaran adaptif dengan menambahkan dua kunci ke MediaFormat
yang menentukan resolusi maksimum yang diperlukan aplikasi Anda dari codec: KEY_MAX_WIDTH
dan KEY_MAX_HEIGHT
. Setelah ditambahkan 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.
Namun, 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 bergantung pada 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, class AudioTimestamp
yang baru memberikan detail linimasa tentang "frame" tertentu dalam streaming audio yang ditangani oleh AudioTrack
. Untuk mendapatkan stempel waktu terbaru yang tersedia, buat instance objek AudioTimestamp
dan teruskan ke getTimestamp()
. Jika permintaan stempel waktu berhasil, instance AudioTrack
akan diisi dengan posisi dalam unit frame, bersama dengan perkiraan waktu saat frame tersebut ditampilkan atau di-commit untuk ditampilkan.
Anda dapat menggunakan nilai nanoTime
di AudioTimestamp
(yang monoton) untuk menemukan frame video terkait yang paling dekat dibandingkan dengan framePosition
, sehingga Anda dapat menghapus, menduplikasi, atau menginterpolasi frame video agar sesuai dengan audio. Atau, Anda dapat menentukan waktu delta antara nilai nanoTime
dan perkiraan waktu frame video mendatang (dengan mempertimbangkan frekuensi sampel) untuk memprediksi frame audio mana yang diharapkan pada saat yang sama dengan frame video.
Pembaca gambar permukaan
ImageReader
API baru memberi Anda akses langsung ke buffer gambar saat dirender menjadi Surface
. Anda dapat memperoleh ImageReader
dengan metode statis newInstance()
. Lalu, panggil getSurface()
untuk membuat Surface
baru dan kirimkan data gambar dengan produser seperti MediaPlayer
atau MediaCodec
. Agar diberi tahu saat gambar baru tersedia dari platform, implementasikan antarmuka ImageReader.OnImageAvailableListener
dan daftarkan ke setOnImageAvailableListener()
.
Sekarang saat Anda menggambar konten ke Surface
, ImageReader.OnImageAvailableListener
akan menerima panggilan ke onImageAvailable()
saat setiap bingkai gambar baru tersedia, yang memberi Anda ImageReader
yang sesuai. Anda dapat menggunakan ImageReader
untuk memperoleh data gambar frame sebagai objek Image
dengan memanggil acquireLatestImage()
atau acquireNextImage()
.
Objek Image
memberikan akses langsung ke stempel waktu, format, dimensi, dan data piksel gambar dalam ByteBuffer
. Namun, agar class Image
dapat menafsirkan gambar Anda, class harus diformat sesuai dengan salah satu jenis yang ditentukan oleh konstanta di ImageFormat
atau PixelFormat
.
Pengukuran RMS dan puncak
Sekarang Anda dapat melakukan kueri puncak dan RMS streaming audio saat ini dari Visualizer
dengan membuat instance baru Visualizer.MeasurementPeakRms
dan meneruskannya ke getMeasurementPeakRms()
. Saat Anda memanggil metode ini, nilai puncak dan RMS dari Visualizer.MeasurementPeakRms
yang diberikan akan disetel ke nilai yang terakhir diukur.
Penambah kenyaringan
LoudnessEnhancer
adalah subclass baru dari AudioEffect
yang memungkinkan Anda meningkatkan volume terdengar dari MediaPlayer
atau AudioTrack
. Hal ini dapat sangat berguna bersamaan dengan metode getMeasurementPeakRms()
baru yang disebutkan di atas, untuk meningkatkan volume trek audio yang diucapkan saat media lain sedang diputar.
Pengontrol jarak jauh
Android 4.0 (API level 14) memperkenalkan RemoteControlClient
API yang memungkinkan aplikasi media menggunakan peristiwa pengontrol media dari klien jarak jauh seperti kontrol media di layar kunci. Sekarang, RemoteController
API baru memungkinkan Anda membuat remote control Anda sendiri, yang memungkinkan pembuatan aplikasi dan periferal baru yang inovatif dan dapat mengontrol pemutaran aplikasi media apa pun yang terintegrasi dengan RemoteControlClient
.
Untuk membuat pengontrol jarak jauh, Anda dapat mengimplementasikan antarmuka pengguna dengan cara apa pun yang diinginkan, tetapi untuk mengirimkan peristiwa tombol media ke aplikasi media pengguna, Anda harus membuat layanan yang memperluas class NotificationListenerService
dan mengimplementasikan antarmuka RemoteController.OnClientUpdateListener
. Penggunaan NotificationListenerService
sebagai dasar penting karena menyediakan batasan privasi yang sesuai, yang mengharuskan pengguna mengaktifkan aplikasi Anda sebagai pemroses notifikasi dalam setelan keamanan sistem.
Class NotificationListenerService
menyertakan beberapa metode abstrak yang harus Anda implementasikan, tetapi jika Anda hanya berfokus pada peristiwa pengontrol media untuk menangani pemutaran media, Anda dapat membiarkan implementasi tersebut kosong dan sebagai gantinya berfokus pada metode RemoteController.OnClientUpdateListener
.
Rating dari pengontrol jarak jauh
Android 4.4 dibuat berdasarkan kemampuan yang ada untuk klien remote control (aplikasi yang menerima peristiwa kontrol media dengan RemoteControlClient
) dengan menambahkan kemampuan bagi pengguna untuk memberi rating pada trek saat ini dari remote pengontrol.
Class Rating
yang baru mengenkapsulasi informasi tentang rating pengguna. Rating ditentukan 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 sesuai untuk gaya tersebut.
Untuk memungkinkan pengguna menilai lagu Anda dari pengontrol jarak jauh:
- Sinyal bahwa Anda ingin menampilkan UI rating kepada pengguna (jika ada) dengan menambahkan flag
FLAG_KEY_MEDIA_RATING
disetTransportControlFlags()
. - Panggil
editMetadata()
untuk mengambilRemoteControlClient.MetadataEditor
dan teruskanRATING_KEY_BY_USER
denganaddEditableKey()
. - Kemudian, tentukan gaya rating dengan memanggil
putObject()
dan meneruskanRATING_KEY_BY_USER
sebagai kunci serta salah satu gaya rating di atas sebagai nilai.
Untuk menerima callback saat pengguna mengubah rating dari remote control, implementasikan antarmuka RemoteControlClient.OnMetadataUpdateListener
baru dan teruskan instance ke setMetadataUpdateListener()
. Saat pengguna mengubah rating, RemoteControlClient.OnMetadataUpdateListener
Anda menerima panggilan ke onMetadataUpdate()
, yang meneruskan RATING_KEY_BY_USER
sebagai kunci dan objek Rating
sebagai nilai.
Teks tertutup
VideoView
kini mendukung trek subtitel WebVTT saat memutar video HTTP Live Stream (HLS), yang menampilkan trek subtitel sesuai dengan preferensi teks tertutup yang telah ditentukan pengguna di setelan sistem.
Anda juga dapat memberi VideoView
trek subtitel WebVTT menggunakan metode addSubtitleSource()
. Metode ini menerima InputStream
yang membawa data subtitel dan objek MediaFormat
yang menentukan format untuk data subtitel, yang dapat Anda tentukan menggunakan createSubtitleFormat()
. Subtitel ini juga muncul di atas video sesuai dengan preferensi pengguna.
Jika Anda tidak menggunakan VideoView
untuk menampilkan konten video, Anda harus membuat overlay subtitel cocok dengan preferensi teks tertutup pengguna semirip mungkin. CaptioningManager
API baru memungkinkan Anda membuat kueri terhadap preferensi pemberian teks tertutup pengguna, termasuk gaya yang ditentukan oleh CaptioningManager.CaptionStyle
, seperti typeface dan warna. Jika pengguna menyesuaikan beberapa preferensi setelah video dimulai, Anda harus memproses perubahan preferensi dengan mendaftarkan instance CaptioningManager.CaptioningChangeListener
untuk menerima callback saat ada perubahan preferensi, lalu memperbarui subtitel seperlunya.
Animasi & Grafis
Adegan dan transisi
Framework android.transition
baru menyediakan API yang memfasilitasi animasi di antara berbagai status antarmuka pengguna. Fitur utamanya adalah kemampuan Anda untuk menentukan status UI yang berbeda, yang dikenal sebagai "adegan", dengan membuat tata letak terpisah untuk masing-masing status. Bila Anda ingin menganimasikan dari satu adegan ke adegan lainnya, jalankan "transisi", yang akan menghitung animasi yang diperlukan untuk mengubah tata letak dari adegan saat ini ke adegan berikutnya.
Pada transisi antara dua adegan, biasanya Anda perlu melakukan yang berikut ini:
- Tentukan
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 dapat menggunakan objek Scene
untuk menyelesaikan langkah 1 dan 2. Scene
berisi metadata yang menjelaskan properti tata letak yang diperlukan untuk melakukan transisi, termasuk tampilan induk scene dan tata letak scene. Anda dapat membuat Scene
menggunakan konstruktor class atau metode statis getSceneForLayout()
.
Anda kemudian harus menggunakan TransitionManager
untuk menyelesaikan langkah 3 dan 4. Salah satu caranya adalah meneruskan Scene
ke metode statis go()
. Fungsi ini akan menemukan tampilan induk scene dalam tata letak saat ini dan melakukan transisi pada tampilan turunan agar dapat mencapai tata letak yang ditentukan oleh Scene
.
Atau, Anda tidak perlu membuat objek Scene
sama sekali, tetapi Anda dapat memanggil beginDelayedTransition()
, yang menentukan ViewGroup
yang 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 dapat menentukan serangkaian transisi yang harus terjadi di antara scene yang telah ditentukan sebelumnya, menggunakan file XML dalam direktori res/transition/
project. Di dalam elemen <transitionManager>
, tentukan satu atau beberapa tag <transition>
yang masing-masing menentukan scene (referensi ke file tata letak) dan transisi yang akan diterapkan saat masuk dan/atau keluar dari scene tersebut. Kemudian, inflate rangkaian transisi ini menggunakan inflateTransitionManager()
. Gunakan TransitionManager
yang ditampilkan untuk menjalankan setiap transisi dengan transitionTo()
, dengan meneruskan Scene
yang diwakili oleh salah satu tag <transition>
. Anda juga dapat menentukan kumpulan transisi secara terprogram dengan TransitionManager
API.
Saat menentukan transisi, Anda dapat menggunakan beberapa jenis yang telah ditentukan sebelumnya dan ditentukan oleh subclass Transition
, seperti Fade
dan ChangeBounds
. Jika Anda tidak menentukan jenis transisi, sistem akan menggunakan AutoTransition
secara default, yang secara otomatis memudarkan, memindahkan, dan mengubah ukuran tampilan sesuai kebutuhan. Selain itu, Anda bisa membuat transisi kustom dengan memperluas salah satu class ini untuk menjalankan animasi sesuai keinginan Anda. Transisi kustom dapat melacak perubahan properti yang diinginkan dan membuat animasi yang diinginkan berdasarkan perubahan tersebut. Misalnya, Anda dapat menyediakan subclass Transition
yang memproses perubahan pada properti "rotasi" dari tampilan, lalu menganimasikan perubahan apa pun.
Untuk mengetahui informasi selengkapnya, lihat dokumentasi TransitionManager
.
Penghentian sementara animator
Animator
API kini memungkinkan Anda menjeda dan melanjutkan animasi yang sedang berlangsung dengan metode pause()
dan resume()
.
Untuk melacak status animasi, Anda dapat menerapkan antarmuka Animator.AnimatorPauseListener
, yang menyediakan callback saat animasi dijeda dan dilanjutkan: pause()
dan resume()
. Kemudian, tambahkan pemroses ke objek Animator
dengan addPauseListener()
.
Atau, Anda dapat membuat subclass untuk class abstrak AnimatorListenerAdapter
, yang kini menyertakan implementasi kosong untuk callback jeda dan lanjutkan yang ditentukan oleh Animator.AnimatorPauseListener
.
Bitmap yang bisa digunakan kembali
Anda kini dapat menggunakan kembali bitmap yang dapat berubah di BitmapFactory
untuk mendekode bitmap lain—meskipun jika bitmap baru memiliki ukuran berbeda---selama jumlah byte yang dihasilkan dari bitmap yang didekode (tersedia mulai getByteCount()
) kurang dari atau sama dengan jumlah byte yang dialokasikan dari bitmap yang digunakan kembali (tersedia mulai getAllocationByteCount()
. Untuk informasi selengkapnya, lihat inBitmap
:
API baru untuk Bitmap
memungkinkan konfigurasi ulang serupa untuk digunakan kembali di luar BitmapFactory
(untuk pembuatan bitmap manual atau logika decoding kustom). Anda kini dapat menyetel dimensi bitmap dengan metode setHeight()
dan setWidth()
, serta menentukan Bitmap.Config
baru dengan setConfig()
tanpa memengaruhi alokasi bitmap dasar. Metode reconfigure()
juga menyediakan cara yang mudah untuk menggabungkan perubahan ini dengan satu panggilan.
Namun, Anda tidak boleh mengonfigurasi ulang bitmap yang saat ini digunakan oleh sistem tampilan, karena buffer piksel yang mendasarinya tidak akan dipetakan ulang dengan cara yang dapat diprediksi.
Konten Pengguna
Storage Access Framework
Pada Android versi sebelumnya, jika Anda ingin aplikasi mengambil jenis file tertentu dari aplikasi lain, aplikasi harus memanggil intent dengan tindakan ACTION_GET_CONTENT
. Tindakan ini masih menjadi cara yang tepat untuk meminta file yang ingin Anda impor ke dalam aplikasi. Namun, Android 4.4 memperkenalkan tindakan ACTION_OPEN_DOCUMENT
, yang memungkinkan pengguna memilih file dari jenis tertentu dan memberi aplikasi Anda akses baca jangka panjang ke file tersebut (mungkin dengan akses tulis) tanpa mengimpor file ke aplikasi Anda.
Jika mengembangkan aplikasi yang menyediakan layanan penyimpanan untuk file (seperti layanan simpan di cloud), Anda dapat berpartisipasi dalam UI terpadu ini untuk memilih file dengan menerapkan penyedia konten sebagai subclass dari class DocumentsProvider
baru. Subclass DocumentsProvider
Anda harus menyertakan filter intent yang menerima tindakan PROVIDER_INTERFACE
("android.content.action.DOCUMENTS_PROVIDER"
). Anda kemudian harus menerapkan empat metode abstrak di DocumentsProvider
:
queryRoots()
- Ini harus menampilkan
Cursor
yang menjelaskan semua direktori utama penyimpanan dokumen Anda, menggunakan kolom yang ditentukan dalamDocumentsContract.Root
. queryChildDocuments()
- Tindakan ini harus menampilkan
Cursor
yang mendeskripsikan semua file dalam direktori yang ditentukan, menggunakan kolom yang ditentukan dalamDocumentsContract.Document
. queryDocument()
- Ini harus menampilkan
Cursor
yang mendeskripsikan file yang ditentukan, menggunakan kolom yang ditentukan dalamDocumentsContract.Document
. openDocument()
- Tindakan ini harus menampilkan
ParcelFileDescriptor
yang mewakili file yang ditentukan. Sistem memanggil metode ini setelah pengguna memilih file dan aplikasi klien meminta akses ke file tersebut dengan memanggilopenFileDescriptor()
.
Untuk mengetahui informasi selengkapnya, lihat panduan Storage Access Framework.
Akses penyimpanan eksternal
Anda kini bisa membaca dan menulis file spesifik aplikasi pada media penyimpanan eksternal sekunder, misalnya bila perangkat menyediakan storage emulasi maupun kartu SD. Metode baru getExternalFilesDirs()
berfungsi sama seperti metode getExternalFilesDir()
yang ada, kecuali metode ini menampilkan array objek File
. Sebelum membaca atau menulis ke salah satu jalur yang ditampilkan oleh metode ini, teruskan objek File
ke metode getStorageState()
baru untuk memverifikasi bahwa penyimpanan saat ini tersedia.
Metode lain untuk mengakses direktori cache khusus aplikasi dan direktori OBB kini juga memiliki versi terkait yang memberikan akses ke perangkat penyimpanan sekunder: getExternalCacheDirs()
dan getObbDirs()
.
Entri pertama dalam array File
yang ditampilkan dianggap sebagai penyimpanan eksternal utama perangkat, yang sama dengan File
yang ditampilkan oleh metode yang ada seperti getExternalFilesDir()
.
Catatan: Mulai dari Android 4.4, platform tidak lagi mengharuskan aplikasi Anda memperoleh WRITE_EXTERNAL_STORAGE
atau READ_EXTERNAL_STORAGE
bila Anda hanya perlu mengakses area khusus aplikasi pada penyimpanan eksternal menggunakan metode di atas. Namun, izin diperlukan jika Anda ingin mengakses region yang dapat dibagikan pada penyimpanan eksternal, yang disediakan oleh getExternalStoragePublicDirectory()
.
Adaptor sinkronisasi
Metode requestSync()
baru di ContentResolver
menyederhanakan beberapa prosedur untuk menentukan permintaan sinkronisasi bagi ContentProvider
Anda dengan mengenkapsulasi permintaan dalam objek SyncRequest
baru, yang dapat Anda buat dengan SyncRequest.Builder
. Properti di SyncRequest
menyediakan fungsi yang sama seperti panggilan sinkronisasi ContentProvider
yang ada, tetapi menambahkan kemampuan untuk menentukan bahwa sinkronisasi harus dihentikan jika jaringan berbayar, dengan mengaktifkan setDisallowMetered()
.
Masukan Pengguna
Tipe sensor baru
Sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR
baru menyediakan data vektor rotasi berdasarkan magnetometer, yang merupakan alternatif yang berguna untuk sensor TYPE_ROTATION_VECTOR
saat giroskop tidak tersedia atau saat digunakan dengan peristiwa sensor batch untuk merekam orientasi perangkat saat ponsel sedang tidur. Sensor ini memerlukan daya lebih sedikit daripada TYPE_ROTATION_VECTOR
, tetapi mungkin rentan terhadap data peristiwa 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 peristiwa setiap kali pengguna mengambil langkah. Pada setiap langkah pengguna, sensor ini akan mengirimkan peristiwa dengan nilai 1,0 dan stempel waktu yang menunjukkan kapan langkah tersebut terjadi.
TYPE_STEP_COUNTER
- Sensor ini juga memicu peristiwa pada setiap langkah yang terdeteksi, tetapi memberikan jumlah total akumulasi langkah sejak sensor ini pertama kali didaftarkan oleh aplikasi.
Perlu diketahui bahwa dua sensor langkah ini tidak selalu memberikan hasil yang sama. Peristiwa TYPE_STEP_COUNTER
terjadi dengan latensi yang lebih tinggi daripada peristiwa dari TYPE_STEP_DETECTOR
, tetapi itu karena algoritma TYPE_STEP_COUNTER
melakukan lebih banyak pemrosesan untuk menghilangkan positif palsu. Jadi, TYPE_STEP_COUNTER
mungkin lebih lambat mengirim peristiwa, tetapi hasilnya seharusnya lebih akurat.
Kedua sensor langkah bergantung pada hardware (Nexus 5 adalah perangkat pertama yang mendukungnya), jadi Anda harus memeriksa ketersediaan dengan hasSystemFeature()
, menggunakan konstanta FEATURE_SENSOR_STEP_DETECTOR
dan FEATURE_SENSOR_STEP_COUNTER
.
Kejadian sensor batch
Untuk mengelola daya perangkat dengan lebih baik, SensorManager
API kini memungkinkan Anda menentukan frekuensi yang akan digunakan sistem untuk mengirimkan batch peristiwa sensor ke aplikasi Anda. Hal ini tidak mengurangi jumlah peristiwa sensor aktual yang tersedia untuk aplikasi Anda selama jangka waktu tertentu, tetapi mengurangi frekuensi sistem memanggil SensorEventListener
dengan update 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 pengelompokan, class SensorManager
menambahkan dua versi baru metode registerListener()
yang memungkinkan Anda menentukan "latensi laporan maksimum". Parameter baru ini menentukan penundaan maksimum yang akan ditoleransi SensorEventListener
untuk pengiriman peristiwa sensor baru. Misalnya, jika Anda menentukan latensi batch selama satu menit, sistem akan mengirimkan kumpulan peristiwa batch terbaru pada interval tidak lebih dari satu menit dengan melakukan panggilan berturut-turut ke metode onSensorChanged()
—satu kali untuk setiap peristiwa yang dikelompokkan. 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.
Namun, perlu diketahui bahwa sensor akan mengirimkan peristiwa yang dikelompokkan ke aplikasi berdasarkan latensi laporan hanya saat CPU aktif. 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 dapat menghindari kehilangan peristiwa dengan mengaktifkan perangkat sebelum sensor mengisi memorinya, lalu memanggil flush()
untuk merekam batch peristiwa terbaru. Untuk memperkirakan kapan memori akan penuh dan harus dikosongkan, panggil getFifoMaxEventCount()
untuk mendapatkan jumlah maksimum peristiwa sensor yang dapat disimpan, dan bagi jumlah tersebut dengan kecepatan yang diinginkan aplikasi Anda setiap peristiwa. Gunakan penghitungan tersebut untuk menyetel alarm bangun dengan AlarmManager
yang memanggil Service
(yang mengimplementasikan SensorEventListener
) untuk mengosongkan sensor.
Catatan: Tidak semua perangkat mendukung pengelompokan peristiwa sensor karena memerlukan dukungan oleh sensor hardware. Namun, mulai Android 4.4, Anda harus selalu menggunakan metode registerListener()
baru, karena jika perangkat tidak mendukung pengelompokan, sistem akan mengabaikan argumen latensi batch dengan baik dan mengirimkan peristiwa sensor secara real time.
Identitas pengontrol
Android kini mengidentifikasi setiap pengontrol yang terhubung dengan bilangan bulat unik yang dapat Anda buat kuerinya dengan getControllerNumber()
, sehingga memudahkan Anda mengaitkan setiap pengontrol ke pemain yang berbeda dalam game. Nomor untuk setiap pengontrol dapat berubah karena pengontrol telah terputus, dihubungkan, atau dikonfigurasi ulang oleh pengguna. Oleh karena itu, Anda harus melacak nomor pengontrol mana yang sesuai dengan setiap perangkat input dengan mendaftarkan instance InputManager.InputDeviceListener
. Lalu, panggil getControllerNumber()
untuk setiap InputDevice
saat terjadi perubahan.
Perangkat yang terhubung kini juga menyediakan ID produk dan vendor yang tersedia dari getProductId()
dan getVendorId()
. Jika perlu mengubah pemetaan tombol berdasarkan kumpulan kunci yang tersedia di perangkat, Anda dapat mengkueri perangkat untuk memeriksa apakah kunci tertentu tersedia dengan hasKeys(int...)
.
Antarmuka Pengguna
Mode layar penuh yang mendalam
Untuk memberi aplikasi Anda tata letak yang mengisi seluruh layar, flag SYSTEM_UI_FLAG_IMMERSIVE
baru untuk setSystemUiVisibility()
(jika dikombinasikan dengan SYSTEM_UI_FLAG_HIDE_NAVIGATION
) akan memungkinkan mode layar penuh yang menakjubkan. 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 area yang biasanya menjadi tempat munculnya bilah sistem. Tindakan ini akan menghapus tanda SYSTEM_UI_FLAG_HIDE_NAVIGATION
(dan tanda SYSTEM_UI_FLAG_FULLSCREEN
, jika diterapkan) sehingga kolom sistem tetap terlihat. Namun, jika ingin kolom sistem disembunyikan lagi setelah beberapa saat, Anda dapat menggunakan flag SYSTEM_UI_FLAG_IMMERSIVE_STICKY
.
Bilah sistem tembus pandang
Anda sekarang dapat membuat kolom sistem transparan sebagian dengan tema baru, Theme.Holo.NoActionBar.TranslucentDecor
dan Theme.Holo.Light.NoActionBar.TranslucentDecor
. Dengan mengaktifkan kolom sistem transparan, tata letak Anda akan mengisi area di belakang kolom sistem, sehingga Anda juga harus mengaktifkan fitsSystemWindows
untuk bagian tata letak yang tidak boleh tertutup oleh kolom sistem.
Jika Anda membuat tema kustom, tetapkan salah satu tema ini sebagai tema induk atau sertakan properti gaya windowTranslucentNavigation
dan windowTranslucentStatus
dalam tema Anda.
Listener notifikasi yang disempurnakan
Android 4.3 menambahkan NotificationListenerService
API, yang memungkinkan aplikasi menerima informasi tentang notifikasi baru saat diposting oleh sistem. Di Android 4.4, pemroses notifikasi bisa mengambil metadata tambahan untuk notifikasi dan detail lengkap tentang tindakan notifikasi:
Kolom Notification.extras
baru menyertakan Bundle
untuk mengirimkan metadata tambahan pembuat notifikasi seperti EXTRA_TITLE
dan EXTRA_PICTURE
.
Class Notification.Action
baru menentukan karakteristik tindakan yang dilampirkan ke notifikasi, yang dapat Anda ambil dari kolom actions
baru.
Pencerminan dapat digambar untuk layout RTL
Pada versi Android sebelumnya, jika aplikasi Anda menyertakan gambar yang harus dibalik orientasi horizontalnya untuk tata letak kanan-ke-kiri, Anda harus menyertakan gambar yang dicerminkan dalam direktori resource drawables-ldrtl/
. Sekarang, sistem dapat secara otomatis mencerminkan gambar untuk Anda dengan mengaktifkan atribut autoMirrored
pada resource drawable atau dengan memanggil setAutoMirrored()
. Jika diaktifkan, Drawable
akan otomatis dicerminkan saat arah tata letak kanan-ke-kiri.
Aksesibilitas
Class View
kini memungkinkan Anda mendeklarasikan "wilayah aktif" untuk bagian UI yang diperbarui secara dinamis dengan konten teks baru, dengan menambahkan atribut accessibilityLiveRegion
baru ke tata letak XML atau memanggil setAccessibilityLiveRegion()
. Misalnya, layar login dengan kolom teks yang menampilkan notifikasi "sandi salah" harus ditandai sebagai live region, sehingga pembaca layar akan membacakan pesan saat berubah.
Aplikasi yang menyediakan layanan aksesibilitas kini juga dapat meningkatkan kemampuannya dengan API baru yang menyediakan informasi tentang koleksi tampilan seperti tampilan daftar atau petak menggunakan AccessibilityNodeInfo.CollectionInfo
dan AccessibilityNodeInfo.CollectionItemInfo
.
Izin Aplikasi
Berikut adalah izin baru yang harus diminta aplikasi Anda dengan tag <uses-permission>
untuk menggunakan API baru tertentu:
INSTALL_SHORTCUT
- Mengizinkan aplikasi menginstal pintasan di Peluncur
UNINSTALL_SHORTCUT
- Mengizinkan aplikasi meng-uninstal pintasan di Peluncur
TRANSMIT_IR
- Mengizinkan aplikasi menggunakan pemancar IR perangkat, jika tersedia
Catatan: Mulai dari Android 4.4, platform tidak lagi mengharuskan aplikasi Anda memperoleh WRITE_EXTERNAL_STORAGE
atau READ_EXTERNAL_STORAGE
saat Anda ingin mengakses region khusus aplikasi dari penyimpanan eksternal menggunakan metode seperti getExternalFilesDir()
. Namun, izin masih diperlukan jika Anda ingin mengakses region yang dapat dibagikan pada penyimpanan eksternal, yang disediakan oleh getExternalStoragePublicDirectory()
.
Fitur Perangkat
Berikut adalah fitur perangkat baru yang dapat Anda deklarasikan dengan tag <uses-feature>
untuk mendeklarasikan persyaratan aplikasi dan mengaktifkan pemfilteran di Google Play atau pemeriksaan saat runtime:
FEATURE_CONSUMER_IR
- Perangkat ini mampu berkomunikasi dengan perangkat IR konsumen.
FEATURE_DEVICE_ADMIN
- Perangkat mendukung penerapan kebijakan perangkat melalui admin perangkat.
FEATURE_NFC_HOST_CARD_EMULATION
- Perangkat mendukung emulasi kartu NFC berbasis host.
FEATURE_SENSOR_STEP_COUNTER
- Perangkat menyertakan penghitung langkah hardware.
FEATURE_SENSOR_STEP_DETECTOR
- Perangkat menyertakan detektor langkah hardware.
Untuk melihat tampilan mendetail semua perubahan API di Android 4.4, lihat Laporan Perbedaan API.