Para Tawanan Pengembangan Android Google

• Pekerjaan pemeliharaan kecil untuk menaikkan targetSdkVersion aplikasi Android lama agar memenuhi persyaratan Google meluas menjadi crash produksi di Android 13 dan antrean peninjauan Google Play yang panjang
• Aplikasi yang sudah ada harus menargetkan API level 31 atau lebih tinggi agar tetap tersedia bagi pengguna perangkat dengan versi Android yang lebih baru daripada level target, dan penulis menaikkan dari API level 30 ke 33 lalu merilisnya
• Rilis pertama disetujui dalam waktu 1 jam, tetapi aplikasi crash tepat setelah login di perangkat Android 13 nyata, dan tidak ada cara untuk rollback ke versi sebelumnya yang normal
• Build perbaikan diajukan segera setelah perubahan kode, tetapi tertahan dalam status menunggu peninjauan selama sekitar 72 jam, lalu baru dipublikasikan ke produksi pada 4 September setelah 11 hari
• Bahkan jika aplikasi mobile native mengoperasikan source code dan infrastrukturnya sendiri, kanal distribusi akhirnya tetap dikendalikan oleh operator app store, sehingga ada batasan pada perbaikan darurat, rollback, dan kecepatan distribusi

---

Pembaruan SDK kecil yang berubah menjadi insiden produksi

• Objek pemeliharaan adalah aplikasi Android lama yang digunakan oleh klien
  • Fungsinya sudah matang selama bertahun-tahun dan bukan aplikasi yang sedang dikembangkan secara aktif
  • Idealnya, versi stabil ingin dibiarkan apa adanya
• Pada 18 Agustus 2023, Google memberi tahu persyaratan level API Android melalui email
• Inti panduan Google adalah bahwa aplikasi yang sudah ada harus menargetkan API level 31 atau lebih tinggi agar tetap tersedia bagi pengguna perangkat dengan versi Android yang lebih tinggi
• Dampak pastinya pada aplikasi yang sudah terpasang tidak dijelaskan dengan jelas, dan pembaruan diprioritaskan berdasarkan interpretasi yang lebih aman
• Tersisa kurang dari 3 minggu sebelum tenggat, dan Google tidak mengirim pengingat lebih awal mengenai persyaratan ini

Mengubah targetSdkVersion dari 30 ke 33

• Pekerjaan dimulai pada 23 Agustus dan targetSdkVersion aplikasi dinaikkan dari API level 30 ke 33
• Build pertama gagal karena dependensi analitik yang tidak kompatibel
  • Dependensi tersebut tidak terkait erat dengan logika bisnis sehingga bisa dihapus
• Setelah itu aplikasi dijalankan di emulator Android, dan fungsi inti tampak tetap bekerja seperti sebelumnya
• Perubahan ini adalah pembaruan untuk memenuhi kebijakan, bukan untuk memberi nilai bisnis baru

Distribusi pertama di Google Play dan crash di Android 13

• Proses distribusi ke Google Play pada awalnya berjalan lancar
  • Karena aplikasi lama hanya diperbarui sekali atau dua kali setahun, sejumlah kuesioner harus diisi
  • Rilis lolos peninjauan dalam waktu 1 jam dan didistribusikan ke produksi
• Malam itu sekitar pukul 21:30, masalah terungkap ketika klien melaporkan ada pengguna yang tidak bisa login pada versi aplikasi baru
• Saat diuji di perangkat Android nyata, aplikasi mengalami crash tepat setelah login
• Investigasi tambahan menunjukkan bahwa masalah terjadi pada Android 13, versi Android terbaru saat itu, sementara versi sebelumnya berjalan normal
• Pada pekerjaan awal, hanya image emulator lama yang diuji sehingga masalah kompatibilitas ini tidak terlihat
• Jika beberapa versi Android diuji, masalah ini bisa ditemukan
  • Ruang lingkup perubahan yang kecil dan tekanan tenggat menciptakan rasa percaya diri yang keliru, tetapi kurangnya cakupan pengujian adalah kesalahan tim

Struktur distribusi yang menghalangi rollback

• Respons awal yang paling aman adalah memulihkan rilis stabil sebelumnya dan menyelidiki crash pada jam kerja berikutnya, tetapi Google Play tidak menyediakan opsi itu
• Tidak ada cara untuk menarik rilis produksi terbaru lalu mengaktifkan kembali versi sebelumnya
• Opsi berikutnya adalah mengembalikan targetSdkVersion ke 30, menaikkan versi aplikasi, dan menerbitkan build baru, tetapi Google Play menolaknya
  • Panduan yang dipublikasikan tampak seolah masih mengizinkan target yang lebih rendah sampai 1 September, tetapi muncul error bahwa pembaruan baru harus menargetkan API level 33
• Permintaan perpanjangan yang mengizinkan API level 30 sampai 1 November sudah diajukan, tetapi error publikasi tetap sama
• Satu-satunya jalur yang mungkin adalah memperbaiki crash di Android 13 dan mengajukan rilis baru

Perbaikan di bawah tekanan dan antrean peninjauan yang panjang

• Versi yang rusak sedang dikirim secara bertahap ke pengguna melalui pembaruan otomatis, dan semakin cepat build perbaikan mencapai produksi, semakin sedikit pelanggan yang terdampak
• Crash dapat direproduksi di emulator Android 13, dan perubahan kode yang dibutuhkan tidak banyak
• Namun pekerjaan harus dilakukan larut malam di bawah tekanan, dan waktu untuk melakukan regression test yang menyeluruh sangat terbatas
• Rencana saat itu lebih mendekati respons pragmatis
  • Memperbaiki semua crash yang diketahui
  • Menguji alur yang paling penting
  • Segera mengajukan versi perbaikan
  • Melanjutkan pengujian yang lebih luas dan menyiapkan pembaruan tambahan jika perlu
• Build baru diajukan ke Google Play, tetapi setelah 2 jam masih berstatus menunggu peninjauan, dan sekitar pukul 01:00 pun belum disetujui
• Keesokan paginya aplikasi masih berstatus in review
• Sebagian besar hari berikutnya dihabiskan untuk pengujian Android 13 dan memeriksa Google Play Console, sambil menemukan dan memperbaiki beberapa masalah kecil yang tidak separah crash login
• Hingga akhir hari itu, perbaikan untuk produksi masih belum disetujui
• Saat itu build perbaikan tertahan selama sekitar 72 jam; kodenya sudah diperbaiki, tetapi distribusinya terkunci di antrean peninjauan yang tidak transparan

Pembaruan berikutnya: peninjauan, chat dukungan, dan peluncuran bertahap

• Pada 27 Agustus, penulis memposting tulisannya di Hacker News, dan diskusi yang muncul mencakup strategi rilis Android dan berbagai kritik
  • Tulisan itu masuk ke halaman depan dan selama beberapa hari menerima sekitar 130 ribu pengunjung unik
  • Situs statis yang dijalankan di VPS dengan biaya sekitar €5 per bulan mampu menangani trafik tersebut
  • Perhatian ini tidak menghasilkan respons dari Google, dan pembaruan aplikasi tetap dalam peninjauan
• Pada 1 September, ditemukan adanya chat dukungan di balik ikon tanda tanya di Google Play Console
  • Petugas dukungan berjanji akan mempercepat peninjauan, tetapi tidak memberi jadwal yang jelas atau solusi konkret
  • Menariknya, tidak ada orang dalam diskusi besar di Hacker News yang menyebut jalur ini
  • Mungkin karena reputasi akses ke dukungan Google yang sulit, para pengembang memang tidak berharap bisa mendapat bantuan langsung
• Pada 4 September, pembaruan perbaikan akhirnya dipublikasikan setelah 11 hari peninjauan
• Setelah itu, alih-alih langsung merilis ke 100% pengguna, diajukan rilis lanjutan yang lebih kecil dengan peluncuran bertahap, dan pembaruan ini lolos peninjauan dalam waktu 1 jam
• Pada 7 September, pembaruan kecil lain diajukan untuk menggantikan versi yang telah mencapai 99.9999% pengguna
  • Begitu versi baru masuk peninjauan, Google otomatis menghentikan rollout sebelumnya tanpa peringatan
  • Jika peninjauan baru memakan beberapa hari, pengguna yang tersisa bahkan tidak akan menerima rilis sebelumnya
  • Bahkan jika pengajuan baru ditarik, rollout sebelumnya tidak dipulihkan
  • Untungnya, peninjauan kali ini selesai dalam waktu 1 jam

Kendali platform yang mengubah tanggung jawab produksi

• Para pengembang mobile telah lama mengalami banyak kasus serupa ketika Google atau Apple menunda perbaikan produksi darurat, menghapus aplikasi, atau hampir tidak memberikan penjelasan atas keputusan mereka
• Sekalipun tim teknis dapat mendiagnosis dan memperbaiki cacat dengan cepat, waktu ketika pengguna menerima solusinya tetap dikendalikan oleh operator app store
• Bagi pengguna umum, mungkin tidak ada rollback, jalur distribusi alternatif, atau metode percepatan peninjauan yang andal
• Bahkan jika source code dan infrastruktur dimiliki sendiri, sifat kepemilikan produksi berubah bila kanal distribusi akhir tidak bisa dikendalikan
• Jika aplikasi mobile native tidak benar-benar diperlukan, alasan untuk lebih memilih platform web terbuka menjadi lebih kuat
  • Aplikasi web sering kali dapat menyediakan fungsi yang dibutuhkan sambil memungkinkan tim menangani distribusi, pemantauan, dan rollback secara langsung
• Tetap ada use case yang valid untuk aplikasi native
  • Ketergantungan pada fitur perangkat
  • Operasi di background
  • Kasus yang memang memerlukan distribusi lewat app store
• Memilih mobile berarti menerima biaya operasional di mana pihak ketiga yang sangat berkuasa ikut masuk ke dalam proses rilis, bersamaan dengan keuntungan produknya

[GN⁺]

Komentar Hacker News

• Saya menerima email ini baik secara pribadi maupun untuk pekerjaan
  Secara pribadi, saya secara sukarela membuat dan mengoperasikan aplikasi open source untuk sistem transportasi umum di 16 kota, dan karena pekerjaan yang tidak menguntungkan siapa pun, saya harus memperbarui 16 aplikasi dalam 2 minggu
  Aplikasi saya adalah PWA, dan versi Android-nya berupa Cordova dengan beberapa plugin yang menambahkan sedikit opsi native. Saat saya menaikkan versi Cordova untuk mendukung target Android API baru, plugin-plugin yang belum diperbarui rusak, jadi saya harus bekerja dan mengujinya sepanjang akhir pekan
  Jujur saja, saya ingin menghapus aplikasinya dan membuat pengguna membuka situs web lalu memasang PWA, tetapi pengguna rata-rata belum tahu caranya. Tempat pertama pengguna mencari aplikasi juga masih Play Store. Akan bagus kalau Google memungkinkan PWA diajukan langsung ke app store, dan saya tidak ingin mengulang ini setiap tahun
  Di pekerjaan pun kami sedang menanganinya dengan panik. Ada aplikasi legacy yang digunakan sebagian pelanggan dukungan sampai akhir tahun, dan karena aplikasinya cukup kompleks, hanya mengubah target versi API saja membuat berbagai bagian rusak dalam pengujian dasar. Kami mendapat perpanjangan, tetapi saya tahu pembaruan yang tidak mengubah fitur apa pun selain menenangkan Google ini akan memakan 1–2 minggu developer dan 1–2 minggu QA. Padahal ini aplikasi yang akan secara resmi dihapus dari store pada akhir tahun setelah semua pelanggan pindah ke aplikasi baru

  • Untuk kasus seperti ini ada Trusted Web Activities (TWA). Anda bisa mengunggah PWA ke Play Store tanpa framework seperti Cordova
    https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
    https://developers.google.com/codelabs/pwa-in-play#0
  • Agar jelas, ini bukan semata-mata karena pengguna tidak tahu caranya. Ini karena Google dan Apple tidak membuatnya semudah memasang aplikasi dari app store mereka. Itu adalah pilihan, dan pilihan yang disengaja
  • Sepertinya Anda salah memahami pengguna. Ini bukan sekadar masalah ketidaktahuan. Saya berharap aplikasi kembali menjadi aplikasi native sungguhan, yaitu bukan Cordova. Hampir tidak ada aplikasi web yang menyamai pengalaman aplikasi nyata yang dibuat dengan baik, bukan barang berbasis web yang dibuat asal-asalan
  • Saya setuju. Beberapa aplikasi pribadi saya juga terdampak
    Namun tenggat ini sudah diberitahukan terus selama beberapa bulan, dan jelas suatu saat akan ditampilkan dengan lebih terang-terangan. Saya tidak suka redaksinya, dan mengeluh bahwa versi produksi baik-baik saja tetapi versi pengujian tidak memenuhi standar juga tidak masuk akal
    Selain itu, ini selalu soal mendorong update baru, dan memang seperti ini setiap tahun. Aplikasi masih bisa tetap dalam status publik untuk sementara waktu
    Jadi mengatakan hanya ada 2 minggu itu tidak akurat
  • Entah ini membantu atau tidak, tetapi kalau saya berada di situasi Anda, saya akan merilis beberapa pembaruan aplikasi sambil memasukkan layar yang menjelaskan cara memasang versi PWA, lalu secara bertahap keluar dari masalah-masalah ini. Mungkin juga bisa menyediakan formulir umpan balik untuk kesulitan yang dialami pengguna

• Saya setuju bahwa pengembangan Android itu sulit, tetapi penulis melakukan dua kesalahan besar
  Pertama, ia tidak menguji aplikasi di versi Android terbaru. Ini kesalahan yang sangat besar, dan itulah alasan kami memelihara 11 virtual machine untuk semua versi Android yang kami dukung
  Kedua, saat mendistribusikan aplikasi di Google Play, jangan pernah mendistribusikannya ke 100% pengguna sejak awal. Peluncuran bertahap adalah default, dan setelah menerbitkan rilis, awalnya kami tidak pernah melewati 10% pengguna. Jika sudah yakin, kami mendistribusikannya ke 99%, bukan 100%. Dengan begitu, jika karena alasan apa pun distribusi harus dihentikan, selama belum didistribusikan ke 100%, itu bisa dihentikan dengan mudah
  Suka atau tidak, dua metode ini adalah taktik yang dikenal baik oleh developer Android berpengalaman

  • Saya setuju bahwa dalam banyak hal kami bisa melakukannya lebih baik. Namun seperti yang sudah dijelaskan, ini adalah aplikasi legacy yang tidak lagi aktif dikembangkan saat ini, jadi tidak masuk akal membangun sistem QA yang sekokoh itu. Aplikasi ini ditulis lama sekali oleh perusahaan lain dan bahkan tidak memiliki unit test sederhana. Itulah kenyataannya
    Namun bahkan dengan sistem serumit itu pun kesalahan tetap terjadi, dan masalah sebenarnya adalah tidak adanya cara untuk mengembalikan rilis, membatalkannya, atau melakukan rollback
    Dalam situasi ini, bagaimana peluncuran bertahap membantu semua pelanggan? Ketika pengguna akhir menerima versi yang rusak, adakah cara bagi mereka untuk mendapatkan versi yang normal?
  • Sebagai tips, kolom input itu juga menerima angka desimal. Kami selalu menyetelnya ke 99.99999999% agar tidak ada pengguna yang terlewat secara tidak sengaja. Namun seperti yang Anda katakan, pembatalan distribusi tetap menjadi mungkin
  • Jika memang harus memelihara virtual machine untuk setiap versi Android yang didukung, ya sudahlah, tetapi pada akhirnya saya jadi bertanya-tanya, sebenarnya komisi 30% dari pendapatan itu dipungut untuk apa?
  • Ini terasa agak seperti menyalahkan korban. Dua hal itu seharusnya tidak menjadi masalah sejak awal
  • Apa yang Anda katakan sepenuhnya benar, dan itu satu-satunya cara praktis untuk melakukan update dan rilis. Namun sayang sekali kita tidak bisa berharap bahwa update API akan langsung berfungsi apa adanya setelah berhasil dikompilasi

• Saya tidak paham reaksi yang menyudutkan penulis asli. Tentu saja ia bisa saja lebih berhati-hati, dan bisa saja menguji login di Android terbaru. Tapi bagaimana kalau itu bukan crash saat login? Bagaimana kalau berfungsi di versi terbaru, tetapi tidak di versi lain? Di mana batasnya harus ditarik?
  Pada titik tertentu, kita harus mengatakan, “Ini secara harfiah adalah platform yang dipakai jutaan aplikasi dan jutaan developer; kesalahan bisa terjadi; dan harus ada cara mudah untuk memperbaikinya, seperti segera menerbitkan ulang versi lama yang sudah disetujui, meskipun seseorang tidak tahu trik seperti menghentikan distribusi sendiri atau staged rollout.” Terutama di tempat seperti app store, membuat segala sesuatu bisa dibatalkan dan bisa dipulihkan adalah prinsip desain dasar.

  • Saya penulis aslinya, dan terima kasih sudah memikirkannya bersama. Seperti sudah saya katakan di beberapa balasan, saya sepenuhnya setuju bahwa saya bisa melakukan lebih baik dari sisi pengujian. Tentu saja bagian itu selalu bisa ditingkatkan.
    Google menetapkan tenggatnya, dan sekali lagi, saya baru pertama kali mendengarnya pada 18 Agustus; sebelumnya saya tidak tahu. Perubahannya saat itu tampak sepele, dan karena aplikasinya tetap berjalan seperti sebelumnya di versi Android lama, saya tidak memperkirakan kegagalannya akan separah ini.
    Saya bukan developer Android yang berpengalaman, tetapi saya punya pengalaman lebih dari 15 tahun dalam pengembangan perangkat lunak secara umum, jadi saya punya semacam intuisi tentang bagaimana sesuatu akan bekerja, serta apa yang perlu diharapkan dan dikhawatirkan. Saya benar-benar tidak tahu bahwa staged rollout 99,99999999% adalah praktik terbaik jika ingin tetap menyisakan kemungkinan untuk “menarik kembali” rilis terbaru, meski hanya sebagian.
    Saya sama sekali tidak membayangkan bahwa tidak ada cara untuk membatalkan atau menghapus rilis terbaru dan kembali ke versi lama yang masih berfungsi. Sepertinya hal semacam ini baru dipelajari setelah mengalaminya sendiri.
    Kalian bisa menyalahkan saya karena tidak menguji semua fitur di semua versi Android, dan saya juga berpikir begitu, tetapi saya harap kalian membuka mata dan memahami bahwa cara Play Store saat ini menangani rilis bukanlah cara yang akan dilakukan orang waras jika berada di luar Play Store. Siapa pun suatu hari bisa mengalami masalah seperti ini, dan semoga tulisan serta thread ini mengurangi jumlah developer yang mengalami situasi serupa.
  • “Bagaimana kalau berfungsi di versi terbaru, tetapi tidak di versi lain?” adalah alasan yang lemah. Bahkan untuk aplikasi web pun Anda harus mengujinya di beberapa browser.
    Smoke test untuk rilis baru adalah etika profesional yang mendasar.
    Staged rollout dengan rollback juga bukan konsep baru.
  • Mem-porting aplikasi ke Android 13, yaitu targetSdkVersion 33, tetapi tidak melakukan pengujian Android 13 itu tidak bisa dibenarkan.

• Seruan untuk “kembali ke standar web terbuka dan merebut kembali kendali” mungkin akan terdengar berbeda ketika menyadari bahwa web juga setengahnya dikendalikan oleh Google, perusahaan yang sedang menimbulkan masalah ini. Apple, dengan Safari yang secara praktis menjadi satu-satunya browser di iOS, juga bukan teman.

  • Itu juga benar, tetapi setidaknya masalah seperti ini bisa ditangani dengan cara seperti rollback. Situasi sekarang adalah kita tahu ada build buruk yang sudah masuk produksi dan ponsel-ponsel otomatis diperbarui ke build itu, tetapi kita tidak bisa melakukan apa-apa. Itu yang paling buruk.
  • Jika di-host sebagai web, pemeliharaannya bisa jadi lebih banyak daripada sekadar membayar biaya.
    Saya jelas lebih memilih situs web daripada sembarang aplikasi yang ada hanya untuk pelacakan yang lebih baik, tetapi tulisan ini terbaca sebagai contoh pemeliharaan yang dilakukan setengah asal-asalan.
  • Jika menolak ikut arah yang memprioritaskan privasi dan keamanan pengguna, Apple jelas bukan teman. Kalau mau memberi alasan, ya itu.

• Ini situasi yang tidak bisa dimenangkan
  Microsoft mencurahkan upaya luar biasa besar untuk kompatibilitas mundur, dan itu sangat patut diapresiasi. Namun, sebesar itu pula permukaan serangannya ikut bertambah
  Demikian pula, banyak sisi terburuk C++ yang sering dicela secara tidak adil berasal dari sikap keras terhadap kompatibilitas mundur. Kode lama sebisa mungkin, bahkan kode C lama sekalipun, harus tetap bisa dikompilasi dan berjalan sesuai ekspektasi, sampai rela menanggung titik ketika harus menautkan dengan binary lama yang source code-nya sudah hilang
  Kebanyakan pihak tidak berusaha sejauh itu dan membatalkan hal-hal lama demi alasan maintainability, reliability, dan keamanan
  Apa pun titik percabangan yang dipilih, pasti ada yang dirugikan. Kalau tidak, berarti tidak ada yang memakai kode itu

  • Benar. Itu salah satu sisi masalahnya, dan saya juga tidak menuntut kompatibilitas mundur yang berlebihan. Kekhawatiran terbesar dalam situasi khusus ini adalah bahwa di Android tidak ada cara untuk mengembalikan, membatalkan, atau me-rollback rilis, dan semuanya tertahan di balik proses review Google
    Mengapa tidak mungkin “menarik” rilis yang bermasalah dan tetap menampilkan rilis sebelumnya sebagai versi terbaru? Dalam konteks masalah ini, itu akan menyelesaikan sebagian besarnya
  • Menurut saya titik tengah yang membantu semua orang adalah mengubah API dan membuat kompilasi gagal. Biarkan developer memperbaiki error kompilasi dan memakai API dengan benar
    Namun jangan mengubah perilaku fungsi lama yang memiliki signature yang sama. Jika Anda penyedia API, Anda harus berusaha sebaik mungkin agar kompilasi memiliki makna
  • Tidak ada pilihan kemenangan terbaik, tetapi aplikasi juga bisa didistribusikan secara terpisah. Ini bukan persyaratan Android, melainkan persyaratan Play Store
    Dalam banyak kasus itu sama sekali tidak sederhana dan tidak akan dipakai sebanyak versi Play Store, tetapi bagus bahwa ada jalan keluar
  • Keluhan utama penulis tampaknya adalah bahwa Google berperan sebagai hakim atas software apa yang bisa dijalankan pengguna. Masalah deprecation API hanyalah pemicu yang membuat kita sadar betapa rentannya kita terhadap tingkah Google
  • Sulit menerima ini sebagai alasan dari Google
    Sebagian besar aplikasi yang didistribusikan di Android menargetkan bytecode Android. Bukan aplikasi yang dikompilasi secara native
    Alasan C++ menciptakan masalah keamanan yang sulit diatasi adalah sifat low-level-nya, dan fakta bahwa begitu native binary tercipta, selesai sudah
    Namun jika itu bytecode dari bahasa yang memory-safe, apa alasan perbaikan keamanan tidak bisa di-backport? Menjalankan kode seperti itu sendiri pada dasarnya bersifat terus mengompilasi ulang bytecode
    Untuk melihat betapa absurdnya posisi ini bagi Google, JVM hingga sekarang masih bisa menjalankan dan memakai class yang menargetkan Java 1.0 dari tahun 1996
    Ini bukan masalah keamanan, melainkan masalah “Google tidak ingin mendukung platformnya”
    Sampai batas tertentu, bisa dipahami jika Google lebih ketat terhadap artefak yang berisi kode yang dikompilasi secara native. Namun kebijakan menyapu rata seperti “aplikasi ini dibangun dengan target versi Android lama, jadi tidak akan kami dukung lagi” sama sekali tidak masuk akal. Ini lebih terlihat seperti cara memangkas aplikasi lama dari store daripada soal keamanan
    Terutama karena kebijakan seperti ini pada dasarnya melempar beban maintenance besar kepada developer Android. Untuk mendukung aplikasi seluas mungkin, mereka terdorong menargetkan versi Android setua mungkin. Hampir tidak ada yang menargetkan versi Android terbaru karena takut mengecualikan terlalu banyak pelanggan
    Jika Google serius soal keamanan dan akses luas ke teknologi Android terbaru, mereka akan mencoba memisahkan runtime Android dari versi sistem operasi. Tidak ada alasan ART dan runtime Dalvik tidak bisa didistribusikan melalui Google Play seperti bagian lain dari ekosistem Android. Situasi konyol seperti “untuk melakukan ini Anda perlu Android 17… oh, produsen hardware tidak memperbarui driver-nya” juga bisa dihapus
    Tapi itu akan memukul penjualan perangkat baru, jadi tentu tidak bisa diterima

• Sejak awal sudah jelas bahwa Play Store dan “komunitas” developer yang terkurung di dalamnya adalah jebakan. Pemaksaan upgrade API hanyalah salah satu sisinya
  Jelas ada pekerjaan yang paling cocok dilakukan ponsel atau aplikasi mobile. Biasanya hal-hal terkait mobilitas seperti navigasi, atau hal yang bergantung pada sensor ponsel seperti menentukan sisi mana yang “atas”. Namun hampir selebihnya bisa dilakukan dengan website
  Jika Anda developer solo yang memelihara aplikasi mobile cross-platform, saya rasa itu benar-benar berat dan saya bersimpati. Namun karena sejak lama saya memutuskan tidak ingin ikut dalam permainan platform proprietary dan gatekeeper, simpati saya sepenuhnya dari posisi orang luar

  • Sebenarnya dua hal itu pun bisa dilakukan dengan mudah di aplikasi browser
    Hampir satu-satunya hal yang belum mudah dilakukan di mobile saat ini adalah GPU compute shader. Namun ketika WebGPU berpindah dari browser desktop, itu pun akan runtuh
    Satu hal lain yang terpikir adalah manajemen file umum untuk seluruh sistem. Itu mungkin tidak akan pernah datang. File System API memang memungkinkan pengguna memberi izin akses ke direktori tertentu, tetapi saya tidak tahu apakah izin itu bertahan setelah halaman di-refresh
  • Saya dulu yakin app store akan gagal. Saya tidak mengira cukup banyak developer akan berkumpul sampai rela melepaskan jaminan bahwa mereka benar-benar bisa mendistribusikan aplikasinya sendiri
  • Lucu membaca ini di situs yang sering menyerang Google karena dianggap tidak cukup melakukan gatekeeping software di Android, dan memuji iPhone sebagai lebih baik karena menindak lebih agresif
  • Bukannya Anda mau berpegang secara ideologis pada kedaulatan pengguna atas perangkatnya sendiri, kan? Lebih baik bersikap cerdas dan praktis saja, lalu mengikuti jalan dengan hambatan paling kecil masuk ke dalam kandang

• Ironis jika mengingat bahwa salah satu prinsip SRE Google adalah “rollback itu normal”
  https://cloud.google.com/blog/products/gcp/reliable-releases...
  “Di Google, filosofi kami adalah ‘rollback itu normal’. Jika ditemukan kesalahan dalam rilis baru, atau ada kecurigaan yang masuk akal, tim rilis terlebih dahulu melakukan rollback lalu menyelidiki masalahnya. Permintaan rollback tidak ditafsirkan sebagai serangan terhadap tim rilis atau orang yang menulis kode yang bermasalah. Sebaliknya, itu dipahami sebagai hal yang benar untuk membuat sistem seandal mungkin bagi pengguna. Selama daftar perubahan rollback menjelaskan masalah yang diamati, tidak ada yang bertanya ‘mengapa perubahan ini di-rollback’”

  • Per tahun lalu, akibat campuran kebijakan Google Play dan pembaruan Android, jika Anda mendistribusikan aplikasi melalui Play Store, satu-satunya cara untuk melakukan rollback adalah menghapus aplikasi lalu menginisialisasi ulang data pengguna
    Tidak bisa downgrade ke versionCode yang lebih rendah, dan versionCode ditentukan oleh developer
    Android 11 melarang penulisan ke penyimpanan “permanen” ponsel, kecuali menggunakan pengecualian media atau API DocumentFile yang memperlakukan folder lokal seperti penyimpanan cloud. DocumentFile tidak bisa digunakan untuk banyak kasus penggunaan
    Developer dapat menyetel hasFragileUserData, dan dengan begitu saat penghapusan, pengguna seharusnya ditanya apakah ingin menghapus datanya. Namun karena bug Google/Android, dialog ini bisa saja tidak ditampilkan
    Jika aplikasi dihapus tetapi pengguna tidak menghapus datanya, Android mencegah downgrade ke versionCode yang lebih rendah
    Jika meminta MANAGE_EXTERNAL_STRORAGE, Anda bisa memakai java.io.File biasa
    Google Play hanya mengizinkan MANAGE_EXTERNAL_STRORAGE dalam kasus-kasus luar biasa
  • “Rollback untukku, tidak ada rollback untukmu”

• Hal yang sama juga terjadi pada beberapa aplikasi berbasis framework yang saya buat. Versi API baru bentrok dengan dependensi yang ada, dan untuk kembali ke kondisi yang persis sama seperti sebelumnya, diperlukan pekerjaan yang benar-benar luar biasa banyak
  Saya jadi jauh lebih menghormati Microsoft, karena barang dari era 90-an berjalan lebih lancar di Windows terbaru dibanding aplikasi mobile yang saya tulis di Android 4 tahun lalu

  • Kalau framework yang digunakan bukan berasal dari Google, itu pernyataan yang tidak adil
    Kita tidak menyalahkan Microsoft karena Adobe Flash tidak berjalan di Windows 11 Store, kan?

• Menurut saya, dipaksa mendistribusikan aplikasi hanya lewat satu app store “yang disetujui sendiri” punya terlalu banyak kekurangan dan hampir tidak ada kelebihan
  Kalau pun ada kelebihan, ironisnya, itu karena pengelola app store memeriksa malware dan virus sebelum publikasi. Namun aplikasi yang penuh iklan Google dan pelacak Google/Facebook justru diterima dengan segala bentuknya
  Ada juga poin bahwa ini memudahkan pengguna mencari, memasang, dan memperbarui aplikasi. Itu pun kalau mereka bisa menemukan yang dicari di antara miliaran aplikasi gim dan aplikasi-aplikasi yang sangat mirip yang diterbitkan hanya untuk mengirim iklan atau mengumpulkan data pribadi
  Kekurangannya adalah kita terikat pada kemauan pengelola app store, dan tidak punya kendali atas proses publikasi aplikasi. Saya tidak bisa menentukan apakah dan kapan aplikasi bisa dipublikasikan; pengelola App Store yang memutuskan berdasarkan apakah itu nyaman bagi mereka. Menurut saya hak ini seharusnya hanya ada pada pengguna
  Untuk aplikasi native komersial, misalnya aplikasi home banking, saya ingin mengunduhnya dengan login ke area pribadi di situs web pengembang. Aplikasinya harus ditandatangani dengan GPG dan integritas paketnya bisa diverifikasi. Fitur pembaruan otomatis juga bisa disediakan
  Untuk aplikasi open source, ada toko F-Droid dan kita bisa menambahkan repositori sendiri. Saya akui ini agak teknis dan tidak cocok untuk semua orang. Akan sangat membantu jika F-Droid sudah terpasang di ponsel baru, tetapi saya rasa Google tidak akan mengizinkannya
  Pilihan realistis lainnya adalah PWA. Menurut saya, sangat sedikit aplikasi yang benar-benar membutuhkan fitur native, dan hampir semua sisanya bisa dibuat dengan teknologi PWA. Tidak perlu juga mengirim pembaruan ke pengguna atau meminta mereka melakukan upgrade
  App store eksklusif dan komersial yang dijalankan dengan dalih memudahkan hidup pengguna dan menyediakan “keamanan yang lebih baik” adalah sarana yang “hebat” bagi Apple dan Google untuk meraup miliaran dolar dari kerja para pengembang independen, dan dalam kasus Google, untuk mengumpulkan serta menjual data pribadi pengguna dan menjual iklan dengan segala cara

  • Ada satu kelebihan lain yang terlewat. Yaitu bisa membuat Boston Strangler[0] tetap di luar rumah. Jika tangan pengguna diikat ke belakang, Anda bisa menentukan dengan syarat apa mereka menggunakan karya Anda. Tidak ada pembajakan, tidak ada pemblokiran iklan
    Inilah alasan mengapa pengembang gim pada era 80–90-an umumnya mengikuti model “Licensed by Nintendo”, dan pengembang aplikasi mobile pada akhir 2000-an mengikuti hal yang sama di iOS App Store. Mereka tidak ingin bekerja sama langsung dengan pengguna untuk melewati pemilik platform. Mereka ingin pemilik platform mengikat tangan pengguna, dan rela tangan mereka sendiri ikut terikat dalam prosesnya
    Ambil contoh aplikasi perbankan. Bank menginginkan atestasi jarak jauh yang aman. Mereka ingin memblokir pengguna yang melakukan serangan credential stuffing terhadap aplikasi, mencegah malware membuka aplikasi bank dan menekan tombol “kirim uang ke penipu”, mencegah pengguna mengekstrak secret kriptografis terkait tap-to-pay, dan juga mencegah secret curian disuntikkan ke aplikasi di ponsel
    Aplikasi tidak bisa memverifikasi sendiri apakah tangan pengguna sudah terikat. Diperlukan pihak ketiga yang tepercaya bagi bank, bukan bagi pengguna, yang berada di boot chain atau EL3. Jadi mereka bukan sekadar ingin memberi aplikasi dan tanda tangan; mereka ingin Google melakukannya agar Google bisa mengikat tangan pengguna
    Penting untuk dicatat bahwa semua manfaat app store dari sisi pengguna adalah rasionalisasi setelah fakta. Sejak awal tujuannya adalah mengikat pengguna. Karena bagi mereka, pengguna itu seperti nyamuk pencuri kecil. Inilah “bagian yang diam-diam” yang tidak mereka ucapkan keras-keras
    Saya sangat berharap proposal WEI dari Google tidak menjadi kenyataan dan PWA tidak mendapat akses ke fungsi atestasi. Google sudah melakukan omong kosong seperti “tidak bisa login dari browser yang tidak dikenal”, dan kanker itu tidak perlu menyebar
    F-Droid itu bagus. Ulah Google di Android harus dihentikan. EU sebenarnya bisa melakukannya, tetapi AS juga harus melakukan hal yang sama dan membuatnya berlaku secara internasional
    [0] Nama sandi yang dipakai MPAA untuk penyalinan kecil-kecilan nonkomersial, yaitu merekam acara TV dengan VCR. Jack Valenti benar-benar orang yang buruk, ya?

• Saya juga sudah bertahun-tahun menentang pengembangan aplikasi mobile, karena begitu memutuskan membuat aplikasi mobile, Anda menyerahkan kendali atas produk atau layanan kepada pihak ketiga
  Tidak sulit untuk setuju
  Jika “dukungan” yang dimaksud hanya berharap mendapat perhatian yang membantu di HN atau Twitter, berarti kita sedang menuju arah yang salah