Perubahan perilaku: semua aplikasi

Android 10 menyertakan perubahan perilaku yang bisa memengaruhi aplikasi Anda. Perubahan yang tercantum dalam dokumen ini berlaku untuk aplikasi Anda ketika berjalan di Android 10, terlepas dari targetSdkVersion aplikasi. Anda harus menguji aplikasi dan mengubahnya sesuai kebutuhan untuk mendukung perubahan ini dengan benar.

Jika targetSdkVersion aplikasi adalah 29 atau lebih tinggi, Anda juga harus mendukung perubahan tambahan. Pastikan untuk membaca perubahan perilaku untuk aplikasi yang menargetkan 29 untuk detailnya.

Catatan: Selain perubahan perilaku, pastikan juga untuk meninjau dan mendukung fitur privasi Android 10 dalam dokumen ini.

Pembatasan antarmuka non-SDK

Untuk membantu memastikan stabilitas dan kompatibilitas aplikasi, platform akan mulai membatasi antarmuka non-SDK yang bisa digunakan aplikasi Anda di Android 9 (API level 28). Android 10 menyertakan daftar terbaru antarmuka non-SDK yang dibatasi berdasarkan kolaborasi dengan developer Android dan pengujian internal terbaru. Tujuan kami adalah memastikan bahwa alternatif publik tersedia sebelum kami membatasi antarmuka non-SDK.

Jika Anda nantinya tidak menargetkan Android 10 (API level 29), beberapa perubahan ini mungkin tidak langsung memengaruhi Anda. Namun, selagi bisa menggunakan antarmuka non-SDK yang merupakan bagian dari greylist (tergantung pada level API target aplikasi), penggunaan metode atau kolom non-SDK apa pun akan cukup berisiko merusak aplikasi Anda.

Jika tidak yakin apakah aplikasi Anda menggunakan antarmuka non-SDK atau tidak, Anda bisa menguji aplikasi untuk mencari tahu. Jika aplikasi Anda mengandalkan antarmuka non-SDK, sebaiknya Anda mulai merencanakan migrasi ke alternatif SDK. Namun demikian, kami memahami bahwa beberapa aplikasi memiliki kasus penggunaan yang valid untuk menggunakan antarmuka non-SDK. Jika tidak bisa menemukan cara selain penggunaan antarmuka non-SDK untuk fitur dalam aplikasi Anda, silakan minta API publik baru.

Untuk mempelajari lebih lanjut, lihat Pembaruan pada pembatasan antarmuka non-SDK di Android 10 dan lihat Pembatasan pada antarmuka non-SDK.

Navigasi Gestur

Dimulai dari Android 10, pengguna bisa mengaktifkan navigasi gestur di seluruh perangkat. Jika pengguna mengaktifkan navigasi gestur, semua aplikasi di perangkat akan terpengaruh, terlepas apakah aplikasi tersebut menargetkan API level 29 atau tidak. Misalnya, jika pengguna menggeser dari tepi layar ke tengah, sistem akan mengartikan gestur tersebut itu sebagai navigasi Kembali, kecuali jika aplikasi secara khusus mengganti gestur tersebut untuk beberapa bagian layar.

Agar aplikasi kompatibel dengan navigasi gestur, Anda bisa memperluas konten aplikasi dari satu tepi layar ke tepi lainnya, serta menangani gestur yang bermasalah dengan benar. Untuk mengetahui informasinya, lihat dokumentasi Navigasi gestur.

NDK

Android 10 menyertakan perubahan NDK berikut ini.

Objek bersama tidak boleh berisi relokasi teks

Android 6.0 (API level 23) melarang penggunaan relokasi teks dalam objek bersama. Kode harus dimuat apa adanya, dan tidak boleh dimodifikasi. Perubahan ini akan mempercepat waktu pemuatan aplikasi dan meningkatkan keamanannya.

SELinux memberlakukan batasan ini pada aplikasi yang menargetkan Android 10 atau yang lebih tinggi. Jika terus menggunakan objek bersama yang berisi relokasi teks, aplikasi ini akan sangat rentan mengalami kerusakan.

Perubahan pada library Bionic dan lokasi linker dinamis

Dimulai dari Android 10, beberapa lokasi akan menjadi link simbolis, bukan file biasa. Aplikasi yang bergantung pada lokasi yang berupa file reguler mungkin akan rusak:

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

Perubahan ini juga berlaku untuk varian file 64-bit, dengan lib/ yang digantikan oleh lib64/.

Untuk kompatibilitas, symlink disediakan pada lokasi yang lama. Misalnya, /system/lib/libc.so adalah symlink ke /apex/com.android.runtime/lib/bionic/libc.so. Jadi, dlopen(“/system/lib/libc.so”) akan terus berfungsi, tetapi aplikasi akan menemukan perbedaannya ketika mencoba memeriksa library yang dimuat dengan membaca /proc/self/maps atau yang serupa. Meskipun hal ini tidak umum terjadi, kami telah menjumpai beberapa aplikasi melakukannya sebagai bagian dari proses antiperetasan. Jika demikian, lokasi /apex/… harus ditambahkan sebagai lokasi yang valid bagi file Bionic tersebut.

Biner/library sistem dipetakan ke memori khusus eksekusi

Dimulai dari Android 10, segmen biner dan library sistem yang bisa dijalankan kini dipetakan ke memori khusus eksekusi (tidak bisa dibaca) sebagai teknik hardening terhadap serangan dari kode yang digunakan kembali. Jika aplikasi Anda melakukan operasi baca ke segmen memori yang ditandai sebagai khusus eksekusi, baik dari bug, kerentanan, maupun inspeksi memori yang disengaja, sistem akan mengirimkan sinyal SIGSEGV ke aplikasi Anda.

Anda bisa mengidentifikasi apakah perilaku ini menyebabkan error dengan memeriksa file tombstone yang terkait di /data/tombstones/. Error terkait memori khusus eksekusi memuat pesan pembatalan berikut:

    Cause: execute-only (no-read) memory access error; likely due to data in .text.

Untuk mengatasi masalah ini guna melakukan operasi seperti inspeksi memori, Anda bisa menandai segmen khusus eksekusi sebagai baca+eksekusi dengan memanggil mprotect(). Namun, kami sangat merekomendasikan untuk mengembalikannya ke setelan khusus eksekusi setelahnya, karena setelan izin akses ini memberikan perlindungan yang lebih baik bagi aplikasi dan pengguna Anda.

Keamanan

Android 10 menghadirkan perubahan keamanan berikut.

TLS 1.3 diaktifkan secara default

Di Android 10 dan yang lebih tinggi, TLS 1.3 diaktifkan secara default untuk semua koneksi TLS. Berikut adalah beberapa detail penting tentang implementasi TLS 1.3 kami:

  • Cipher suite TLS 1.3 tidak bisa disesuaikan. Cipher suite TLS 1.3 yang didukung selalu diaktifkan saat TLS 1.3 diaktifkan. Upaya apa pun untuk menonaktifkannya dengan memanggil setEnabledCipherSuites() akan diabaikan.
  • Saat TLS 1.3 dinegosiasikan, objek HandshakeCompletedListener akan dipanggil sebelum sesi ditambahkan ke cache sesi. (Pada TLS 1.2 dan versi sebelumnya, objek ini dipanggil setelah sesi ditambahkan ke cache sesi.)
  • Dalam beberapa situasi ketika instance SSLEngine menampilkan SSLHandshakeException pada versi Android sebelumnya, instance ini akan menampilkan SSLProtocolException di Android 10 dan versi yang lebih tinggi.
  • Mode 0-RTT tidak didukung.

Jika diinginkan, Anda dapat memperoleh SSLContext dengan TLS 1.3 yang dinonaktifkan melalui pemanggilan SSLContext.getInstance("TLSv1.2"). Anda juga dapat mengaktifkan atau menonaktifkan versi protokol per koneksi dengan memanggil setEnabledProtocols() pada objek yang sesuai.

Sertifikat yang ditandatangani dengan SHA-1 tidak dipercaya di TLS

Di Android 10, sertifikat yang menggunakan algoritme hash SHA-1 tidak dipercaya dalam koneksi TLS. CA root belum menerbitkan sertifikat seperti itu sejak tahun 2016, dan sertifikat tersebut tidak lagi dipercaya di Chrome atau browser utama lainnya.

Setiap upaya untuk terhubung akan gagal jika koneksi dibuat ke situs yang menyajikan sertifikat yang menggunakan SHA-1.

Perubahan dan peningkatan perilaku KeyChain

Beberapa browser seperti Google Chrome memungkinkan pengguna untuk memilih sertifikat ketika server TLS mengirimkan pesan permintaan sertifikat sebagai bagian dari handshake TLS. Dimulai dari Android 10, objek KeyChain kini akan menerapkan penerbit dan parameter spesifikasi utama saat memanggil KeyChain.choosePrivateKeyAlias() untuk menunjukkan perintah pemilihan sertifikat kepada pengguna. Secara khusus, perintah ini tidak berisi pilihan yang tidak mematuhi spesifikasi server.

Jika tidak ada sertifikat yang bisa dipilih pengguna, seperti ketika tidak ada sertifikat yang cocok dengan spesifikasi server atau perangkat tidak memiliki sertifikat yang terinstal, perintah pemilihan sertifikat tidak akan muncul.

Selain itu, di Android 10 atau yang lebih tinggi, Anda tidak harus menyetel kunci layar perangkat untuk mengimpor kunci atau sertifikat CA ke objek KeyChain.

Perubahan TLS dan kriptografi lainnya

Ada beberapa perubahan kecil dalam library TLS dan kriptografi yang diberlakukan di Android 10:

  • Cipher AES/GCM/NoPadding dan ChaCha20/Poly1305/NoPadding menghasilkan ukuran buffer yang lebih akurat dari getOutputSize().
  • Tidak ada lagi cipher suite TLS_FALLBACK_SCSV dalam upaya koneksi dengan protokol maksimal TLS 1.2 atau yang lebih tinggi. Dengan diimplementasikannya peningkatan di server TLS, kami tidak merekomendasikan Anda untuk mencoba penggantian TLS eksternal. Sebagai gantinya, cobalah untuk mengandalkan negosiasi versi TLS.
  • ChaCha20-Poly1305 adalah alias untuk ChaCha20/Poly1305/NoPadding.
  • Hostname yang memiliki titik akhir tidak dianggap sebagai nama host SNI yang valid.
  • Ekstensi supported_signature_algorithms dalam CertificateRequest dihormati ketika memilih kunci penandatanganan untuk respons sertifikat.
  • Kunci penandatanganan yang tidak jelas, seperti yang berasal dari Android Keystore, bisa digunakan dengan tanda tangan RSA-PSS di TLS.

Siaran Wi-Fi Langsung

Di Android 10, siaran berikut ini yang terkait dengan Wi-Fi Langsung tidak melekat:

Jika aplikasi Anda mengandalkan penerimaan siaran ini pada saat pendaftaran karena sifatnya yang melekat, gunakan metode get() yang sesuai saat inisialisasi untuk mendapatkan informasi tersebut.

Kemampuan Wi-Fi Aware

Android 10 menambahkan dukungan untuk memudahkan pembuatan Soket TCP/UDP menggunakan lokasi data Wi-Fi Aware. Untuk membuat soket TCP/UDP yang terhubung ke ServerSocket, perangkat klien harus mengetahui alamat IPv6 dan port server. Sebelumnya, hal ini perlu dikomunikasikan di luar band, seperti menggunakan messaging 2 lapis Wi-Fi Aware atau BT, atau ditemukan dalam band menggunakan protokol lain, seperti mDNS. Dengan Android 10, informasi ini bisa dikomunikasikan sebagai bagian dari penyiapan jaringan.

Server bisa melakukan salah satu hal berikut:

  • Memulai ServerSocket serta menyetel atau mendapatkan port yang akan digunakan.
  • Menentukan informasi port sebagai bagian dari permintaan jaringan Wi-Fi Aware.

Contoh kode berikut menunjukkan cara menentukan informasi port sebagai bagian dari permintaan jaringan:

Kotlin

    val ss = ServerSocket()
    val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
      .setPskPassphrase("some-password")
      .setPort(ss.localPort)
      .build()

    val myNetworkRequest = NetworkRequest.Builder()
      .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
      .setNetworkSpecifier(ns)
      .build()

Java

    ServerSocket ss = new ServerSocket();
    WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
      .Builder(discoverySession, peerHandle)
      .setPskPassphrase(“some-password”)
      .setPort(ss.getLocalPort())
      .build();

    NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
      .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
      .setNetworkSpecifier(ns)
      .build();

Klien kemudian melakukan permintaan jaringan Wi-Fi Aware untuk mendapatkan IPv6 dan port yang disediakan oleh server:

Kotlin


    val callback = object : ConnectivityManager.NetworkCallback() {
      override fun onAvailable(network: Network) {
        ...
      }

      override fun onLinkPropertiesChanged(network: Network,
          linkProperties: LinkProperties) {
        ...
      }

      override fun onCapabilitiesChanged(network: Network,
          networkCapabilities: NetworkCapabilities) {
        ...
        val ti = networkCapabilities.transportInfo
        if (ti is WifiAwareNetworkInfo) {
           val peerAddress = ti.peerIpv6Addr
           val peerPort = ti.port
        }
      }
      override fun onLost(network: Network) {
        ...
      }
    };

    connMgr.requestNetwork(networkRequest, callback)

Java

    callback = new ConnectivityManager.NetworkCallback() {
      @Override
      public void onAvailable(Network network) {
        ...
      }
      @Override
      public void onLinkPropertiesChanged(Network network,
          LinkProperties linkProperties) {
        ...
      }
      @Override
      Public void onCapabilitiesChanged(Network network,
          NetworkCapabilities networkCapabilities) {
        ...
        TransportInfo ti = networkCapabilities.getTransportInfo();
        if (ti instanceof WifiAwareNetworkInfo) {
           WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
           Inet6Address peerAddress = info.getPeerIpv6Addr();
           int peerPort = info.getPort();
        }
      }
      @Override
      public void onLost(Network network) {
        ...
      }
    };

    connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW di perangkat Go

Aplikasi yang berjalan di perangkat Android 10 (edisi Go) tidak dapat menerima izin SYSTEM_ALERT_WINDOW. Hal ini dikarenakan proses penggambaran jendela overlay membutuhkan banyak sekali memori, yang menjadi cukup berbahaya bagi performa perangkat Android dengan memori rendah.

Jika aplikasi di perangkat edisi Go yang menjalankan Android 9 atau lebih rendah menerima izin SYSTEM_ALERT_WINDOW, aplikasi akan tetap memiliki izin tersebut meskipun perangkat di-upgrade ke Android 10. Namun, aplikasi yang belum memiliki izin tersebut tidak dapat diberi izin setelah perangkat di-upgrade.

Jika aplikasi di perangkat Go mengirim intent dengan tindakan ACTION_MANAGE_OVERLAY_PERMISSION, sistem akan menolak permintaan secara otomatis, dan mengalihkan pengguna ke layar Setelan yang menyatakan bahwa izin tersebut tidak diberikan karena akan memperlambat perangkat. Jika aplikasi di perangkat Go memanggil Settings.canDrawOverlays(), metode ini akan selalu menghasilkan nilai false. Sekali lagi, pembatasan ini tidak berlaku untuk aplikasi yang menerima izin SYSTEM_ALERT_WINDOW sebelum perangkat di-upgrade ke Android 10.

Peringatan untuk aplikasi yang menargetkan versi lama Android

Perangkat yang menjalankan Android 10 atau yang lebih tinggi akan memperingatkan pengguna pada kali pertama mereka menjalankan aplikasi yang menargetkan Android 5.1 (API level 22) atau yang lebih rendah. Jika aplikasi tersebut mengharuskan pengguna memberikan izin, pengguna juga akan diberi kesempatan untuk menyesuaikan izin aplikasi sebelum aplikasi diizinkan berjalan untuk kali pertama.

Sehubungan dengan persyaratan API target Google Play, pengguna hanya akan melihat peringatan ini ketika menjalankan aplikasi yang belum diupdate baru-baru ini. Untuk aplikasi yang didistribusikan melalui toko lainnya, persyaratan API target yang serupa akan berlaku selama tahun 2019. Untuk mengetahui informasi selengkapnya tentang persyaratan ini, lihat Memperluas persyaratan level API target pada tahun 2019.

Cipher suite SHA-2 CBC dihapus

Cipher suite SHA-2 CBC berikut telah dihapus dari platform:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Cipher suite ini kurang aman dibandingkan cipher suite serupa yang menggunakan GCM. Sebagian besar server mendukung varian GCM sekaligus CBC cipher suite ini, atau tidak mendukung keduanya sama sekali.

Penggunaan aplikasi

Android 10 memperkenalkan perubahan perilaku berikut yang terkait dengan penggunaan aplikasi:

  • Peningkatan penggunaan aplikasi UsageStats - Android 10 melacak penggunaan aplikasi secara akurat dengan UsageStats ketika aplikasi digunakan dalam mode layar terpisah atau picture-in-picture. Selain itu, Android 10 juga melacak penggunaan aplikasi instan dengan benar.

  • Hitam putih per aplikasi - Android 10 bisa menyetel mode tampilan hitam putih per aplikasi.

  • Status gangguan per aplikasi - Android 10 bisa menetapkan aplikasi ke "status gangguan" secara selektif ketika notifikasinya disembunyikan dan aplikasi tersebut tidak akan muncul sebagai aplikasi yang disarankan.

  • Penangguhan dan pemutaran - Di Android 10, aplikasi yang ditangguhkan tidak bisa memutar audio.

Perubahan koneksi HTTPS

Jika aplikasi yang menjalankan Android 10 meneruskan null ke setSSLSocketFactory(), IllegalArgumentException akan terjadi. Pada versi sebelumnya, penerusan null ke setSSLSocketFactory() menunjukkan efek yang sama dengan penerusan nilai pabrik default yang aktif.

Library android.preference tidak digunakan lagi

Library android.preference tidak digunakan lagi mulai di Android 10. Sebagai gantinya, developer sebaiknya menggunakan library preferensi AndroidX yang merupakan bagian dari Android Jetpack. Sebagai referensi tambahan untuk membantu proses migrasi dan pengembangan, lihat Panduan Setelan yang telah diperbarui beserta aplikasi sampel publik dan dokumentasi referensi kami.

Perubahan library utilitas file ZIP

Android 10 memperkenalkan perubahan berikut ini untuk class dalam paket java.util.zip, yang menangani file ZIP. Perubahan ini membuat perilaku library menjadi lebih konsisten antara Android dan platform lain yang menggunakan java.util.zip.

Inflater

Dalam versi sebelumnya, beberapa metode dalam class Inflater akan memunculkan IllegalStateException jika dipanggil setelah panggilan ke end(). Di Android 10, metode ini akan memunculkan NullPointerException.

ZipFile

Di Android 10 dan versi yang lebih baru, konstruktor untuk ZipFile yang mengambil argumen jenis File, int, dan Charset tidak lagi menampilkan ZipException jika file ZIP yang disediakan tidak berisi file apa pun.

ZipOutputStream

Di Android 10 dan versi yang lebih baru, metode finish() dalam ZipOutputStream tidak menampilkan ZipException jika metode tersebut mencoba menulis streaming keluaran untuk file ZIP yang tidak berisi file apa pun.

Perubahan kamera

Banyak aplikasi yang memanfaatkan fungsi kamera menganggap bahwa jika perangkat berada dalam konfigurasi potret, perangkat fisiknya juga berada dalam orientasi potret, seperti yang dijelaskan dalam Orientasi kamera. Asumsi ini sebelumnya memang benar, tetapi sekarang telah berubah dengan semakin banyaknya faktor bentuk baru, seperti perangkat foldable. Jika asumsi tersebut diberlakukan pada perangkat semacam ini, tampilan jendela bidik kamera mungkin akan diputar atau diskalakan secara tidak semestinya (atau keduanya).

Aplikasi yang menargetkan API level 24 atau versi lebih tinggi harus secara eksplisit menyetel android:resizeableActivity dan menyediakan fungsionalitas yang diperlukan untuk menangani operasi multi-aplikasi.

Pelacakan penggunaan baterai

Dimulai dari Android 10, SystemHealthManager akan menyetel ulang statistik penggunaan baterai setiap pengisi daya dilepas dari perangkat setelah peristiwa pengisian daya utama. Secara umum, aktivitas pengisian daya utama adalah: Daya perangkat sudah terisi penuh, atau daya sudah terisi dari hampir habis hingga hampir penuh.

Sebelum Android 10, statistik penggunaan baterai disetel ulang setiap kali kabel pengisian daya perangkat dicabut meskipun baru ada sedikit perubahan level baterai.

Android Beam tidak digunakan lagi

Di Android 10, kami secara resmi menghentikan Android Beam, fitur yang lebih lama untuk memulai berbagi data di seluruh perangkat melalui Komunikasi Nirkabel Jarak Dekat (NFC). Kami juga akan menghentikan beberapa API NFC yang terkait. Android Beam akan tetap tersedia secara opsional bagi partner pembuat perangkat yang ingin menggunakannya, tetapi tidak lagi dikembangkan secara aktif. Namun, Android akan terus mendukung kemampuan dan API NFC lainnya, dan kasus penggunaan seperti membaca dari tag dan pembayaran akan terus berfungsi seperti yang diharapkan.