Pada artikel ini kami mengeksplorasi kebenaran mengapa perangkat Snapdragon 801 tidak mendapatkan Android Nougat. Dari pembuat chipset hingga vendor, ada banyak permasalahan!
Diperbarui untuk mencerminkan persyaratan Vulkan atau OpenGL ES 3.1 untuk Android 7.0
Akhir-akhir ini banyak sekali artikel yang ditulis tentang pembaruan versi, interaksi antara vendor dan pembuat chipset, serta apa pengaruhnya terhadap perangkat di masa mendatang. Mengapa angka ini meningkat minggu ini?
Ya, hal itu muncul minggu ini karena Nexus 5 yang terhormat tidak akan menerima pembaruan ke Android 7.0 (Nougat), dan Qualcomm mengumumkan hal itu tidak akan terjadi. memberikan dukungan untuk MSM8974 (lebih dikenal sebagai Snapdragon 801) pada 7.0. Artikel ini ditulis sebagai kolaborasi dengan XDA Recognized Pengembang kumbang.
Topik ini telah menarik cukup banyak minat dari berbagai situs berita, namun banyak yang melewatkan nuansa halus dari apa yang sebenarnya terjadi di balik layarS. Artikel ini akan menjelaskan lebih banyak tentang cara kerja pembaruan perangkat lunak, menggunakan pengalaman kami bekerja dengan OEM pada pembaruan firmware resmi mereka. Kami akan memandu Anda mengetahui apa yang terjadi di balik layar (dan alasannya), dan mengapa Anda mungkin tidak mendapatkan perangkat lunak terbaru di ponsel Anda.
Langkah pertama dalam kehidupan pembaruan firmware Android adalah pembaruan upstream. Inilah yang dikerjakan Google secara internal. Berbeda dengan "alur kerja terbuka", Android dikembangkan menggunakan alur kerja tertutup, dengan kode sumber dibuang setiap tahun atau lebih, saat rilis baru dirilis. Awalnya, Google mengatakan ini untuk mencegah fragmentasi dari orang-orang yang menjalankan versi terbaru Meskipun segala sesuatunya berkembang pesat pada masa-masa awal, namun mereka tampaknya tetap mempertahankan kebijakan ini tempat.
Pada suatu saat, biasanya sebelum pengumuman publik mengenai suatu pembaruan (walaupun dengan diperkenalkannya beta publik baru-baru ini, rentang waktu ini berubah), OEM akan diberi tahu tentang pembaruan yang akan datang. Mereka kemudian akan menerima kode sumber pada saat kedua untuk pembaruan terakhir (dulu terkadang sedikit sebelum peluncuran, meskipun kami juga mengetahui adanya kasus di mana peluncuran tidak dilakukan lebih awal melepaskan).
Repositori AOSP upstream berisi dukungan perangkat hanya untuk sejumlah perangkat terbatas. Biasanya ini adalah perangkat Nexus Anda. Namun untuk alasan yang akan menjadi jelas segera, penting untuk dicatat bahwa Google tidak memiliki kontrol perangkat keras penuh atas perangkat ini; perangkat tersebut diproduksi oleh OEM, dan OEM tersebut akan membeli System-on-Chip (SoC) dari pembuat chipset.
Setelah kode sumber dirilis, tim firmware OEM akan (secara kiasan) duduk santai dan bersiap. Pohon sumber utama Android tidak memiliki dukungan perangkat keras untuk berbagai chipset yang digunakan pada perangkat pengiriman. Misalnya, chipset Qualcomm Anda kemungkinan besar tidak didukung dalam AOSP. Exynos Anda pastinya tidak. Mediatek atau Hisilicon? Lupakan!
BSP berisi driver dan lapisan abstraksi perangkat keras (HAL) yang diperlukan untuk menjalankan Android
Yang dibutuhkan saat ini adalah a Paket Dukungan Dewan (BSP). Ini adalah paket komponen eksklusif yang sangat rahasia, yang dikirimkan oleh pembuat chipset ke OEM. BSP berisi kode sumber yang diperlukan agar OEM dapat membuat Android dan driver yang diperlukan untuk perangkat mereka.
Perlu dicatat di sini bahwa OEM seperti Qualcomm belum tentu sepenuhnya mempercayai mitra OEM mereka -- BSP tersedia berdasarkan "kebutuhan untuk mengetahui". OEM biasanya tidak mendapatkan akses ke kode sumber untuk beberapa bagian perangkat yang sangat rahasia (seperti perangkat lunak yang berjalan pada baseband). Menutup bagian ini tentunya juga memiliki potensi masalah, seperti yang ditunjukkan oleh beberapa hal banyak sekali Dan berulang ASN.1 menguraikan kerentanan.
BSP berisi driver dan lapisan abstraksi perangkat keras (HAL) yang diperlukan agar Android dapat berjalan di perangkat Anda. AOSP berisi sekumpulan HAL, yang bertindak sebagai definisi tentang apa yang diharapkan sistem operasi untuk diterapkan oleh driver Anda. Untuk menggunakan contoh yang terlalu disederhanakan (dan dibuat-buat, untuk tujuan demonstrasi), bayangkan senter di ponsel Anda.
Contoh HAL - Senter Anda
Bayangkan perangkat Anda memiliki senter di bagian belakang (jika Anda memiliki Nexus 7 2013, Anda harus lebih banyak berimajinasi dibandingkan orang lain -- maaf!). Ini dikendalikan oleh pengemudi. Untuk contoh sederhana kita, misalkan HAL v1 mengatakan Anda harus memiliki satu fungsi yang disebut "setLED" yang mengambil satu parameter, yaitu keadaan cahaya. Itu boolean - benar atau salah. Di C, ini akan terlihat seperti ini:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Fungsi ini didefinisikan dalam kode sumber BSP. BSP kemudian dikompilasi oleh OEM selama pembuatan ROM, dan ini menjadi salah satu perpustakaan ".so" milik di partisi vendor atau area perangkat Anda. Hal ini memungkinkan OEM merahasiakan bagian tertentu dari cara kerja perangkat mereka. Untuk saat ini, anggaplah mereka ingin menghentikan semua orang melihat bagaimana mereka menyalakan dan mematikan LED tersebut.
Sekarang bayangkan Google merilis versi terbaru HAL mereka di versi Android yang akan datang. Mereka sekarang memutuskan bahwa akan lebih baik jika Anda mengizinkan Anda memperbarui kecerahan LED Anda, daripada hanya menyalakan atau mematikannya. Mungkin ini untuk flash adaptif, atau mungkin hanya untuk memaksakan pembaruan HAL, dan mempertahankan bisnis pembuat chipset? Kami akan membiarkan Anda, para pembaca, memberikan pendapat Anda sendiri tentang hal itu. Beberapa pembaruan HAL memiliki manfaat yang jelas (seperti Kamera HAL baru yang mengekspos pengambilan gambar mentah dan sejenisnya), sedangkan pembaruan lainnya kurang jelas tujuannya.
Dengan HAL (fiksi) baru untuk kecerahan, misalkan Google mengatakan Anda perlu mengekspos lagi fungsi yang disebut setLED, tetapi kali ini dengan bilangan bulat yang dimasukkan untuk kecerahan. Sekarang, 0 akan mematikannya, dan 255 akan mengaktifkannya secara penuh.
Jika Anda OEM, Anda dapat mengambil kode super rahasia untuk menyalakan LED itu, dan memasukkannya ke dalam fungsi baru ini. Anda bahkan dapat menggunakan modulasi lebar pulsa untuk menyesuaikan kecerahan LED berdasarkan nomornya. Anda mengubah fungsinya menjadi seperti ini sekarang:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Terus? Nah, sekarang Android versi baru ini tidak kompatibel dengan "blob" yang ada. OEM Anda perlu menggunakan blob baru ini, karena OS Android mengharapkan untuk melihat definisi fungsi baru, dan tidak akan "menemukan" yang lama saat mencari cara untuk menyetel LED.
Pada titik ini, mari kita istirahat sejenak untuk melihat bagaimana Custom ROM (dibangun dari sumber) dikelola di sini. Itulah yang akan diteriakkan oleh orang-orang cerdas di layar Anda saat ini - lagipula, kami adalah XDA, rumah dari HTC HD2, ponsel paling tahan lama di dunia... (Sebagai catatan, para jenius gila di sana sedang berlari Android 6.0 pada HD2 hari ini! Lumayan untuk ponsel yang awalnya dikirimkan dengan Windows Mobile 6.5 pada tahun 2009)
Ada berbagai pendekatan yang diambil di sini - terkadang pengembang meretas ROM dan memberi tahu OS untuk menggunakan definisi fungsi lama. Itu agak berantakan, dan membuat banyak perubahan yang harus dipertahankan. Pendekatan lainnya adalah dengan "shim" biner OEM.
Pendekatan "shim" adalah dengan menulis dan membangun sendiri perpustakaan kecil baru, yang berisi definisi fungsi yang diharapkan - sebagai contoh, kami akan mendukung bilangan bulat untuk kecerahan. Kemudian, di dalam shim, ini diterjemahkan untuk memenuhi persyaratan HAL lama. Jadi sebagai contoh, kita mungkin mengatakan bahwa kecerahan apa pun yang diminta di atas 128 akan menyalakan LED, dan kecerahan apa pun di bawah itu akan mematikannya. Atau bisa dibilang apa pun yang bukan nol akan menyalakannya. Terserah pengembangnya. Mereka mengkompilasi shim, dan membuat Android menggunakannya, bukan yang asli. Shim kemudian memanggil gumpalan OEM.
`adb push` dan reboot yang cepat akan membuat shim berjalan, dan memungkinkan Anda mengontrol LED fiksi Anda, meskipun Anda hanya memiliki HAL lama.
Masalahnya adalah ini jelas merupakan proses yang tidak sempurna. Sekarang Anda akan mendapatkan keunikan - perangkat ini akan memiliki flash yang agak jelek, yang menyala atau mati sepenuhnya. Itu tidak ideal - OS menganggapnya menghasilkan cahaya yang sangat lembut, namun LED sebenarnya diberi tahu bahwa ia bersaing dalam kontes matahari buatan, dan mencoba membutakan Anda. Tapi hei, hidup ini tidak sempurna, dan Anda sekarang memiliki LED yang berfungsi di ponsel lama Anda!
(Ya, ini adalah salah satu alasan mengapa ada keanehan dan bug ketika pengguna dan pengembang XDA mengelola kehebatan porting mereka yang gila dan gila. Maksudku sih, itu Galaksi S II sedang membawa sesuatu yang tampaknya bisa digunakan ROM Android 6.0 sekarang. Banyak ponsel yang dirilis tahun lalu masih belum memiliki 6.0!)
Mari kita kembali ke perspektif OEM. Sayangnya, sebagian besar OEM sudah bekerja setidaknya 1 ponsel lebih unggul dari yang kita miliki saat ini. Fokus mereka adalah pada ponsel berikutnya yang akan mereka jual - Anda tidak dapat menyalahkan mereka, karena mereka hanya menghasilkan uang dari perangkat yang mereka jual. Mereka tidak menghasilkan uang dari perangkat yang mereka jual satu atau dua tahun lalu, sehingga mereka harus terus merilis perangkat baru agar bisa eksis. Inilah salah satu alasan HTC dan Blackberry berada dalam masalah - tidak peduli berapa banyak eksekutif yang masih mempertahankan Blackberry Curve lama mereka, karena mereka tidak mendapatkan penjualan perangkat baru di sana.
Jika OEM tidak mendapatkan BSP, mereka tidak akan melakukan pendekatan XDA dalam meretas sebuah build. Mengapa? Dengan baik, mereka perlu mendukung firmware ini untuk pelanggan mereka. Jika mereka merilis firmware yang setengah berfungsi, pengguna akan membencinya, mengoceh dan mengoceh, dan terus menghubungi saluran dukungan mereka selama berhari-hari.
OEM juga harus bersaing dengan operator, setidaknya di pasar non-Eropa. Operator tidak ingin pelanggan mengalami masalah dengan pembaruan perangkat lunak. Faktanya, operator sering kali memilih untuk tidak merilis pembaruan perangkat lunak.
Untuk memahami hal ini, bayangkan Bibi Alice Anda. Dialah yang menelepon Anda pada waktu-waktu yang tidak tepat untuk meminta bantuan dengan "masalah komputer itu". Anda kemudian menjelaskan cara mengeklik "Menu Mulai", dan harus mengidentifikasinya sebagai "bendera besar di pojok kiri bawah", dan menemui kebingungan. Sekitar 45 menit (dan sangat membuat frustrasi) kemudian, ternyata Bibi Alice telah menyeret menu mulai ke tepi kanan layar, dan hanya perlu menyeretnya kembali. Ya, dengan tombol kiri mouse!
Sekarang bayangkan Anda mempunyai seribu Bibi Alice. Mereka semua menelepon dukungan pelanggan Anda, tidak dapat menemukan Candy Crush di ponsel mereka, khawatir peretas menghapusnya dari ponsel mereka. Oh, dan ikonnya terlihat sedikit berbeda sekarang - mungkin peretasnya masih ada di ponselnya?
Ya, ini dimaksudkan untuk menjadi sedikit humor ringan, tetapi sampai Anda mengetahui alasan orang-orang menghubungi operator mereka untuk meminta dukungan, Anda tidak akan percaya dengan masalah yang mereka hadapi. Pembaruan perangkat lunak yang mengubah cara kerja ponsel, atau lokasinya, akan menyebabkan overhead dukungan yang signifikan. Minimal, hal ini memerlukan pelatihan ulang staf pendukung (sayangnya, karena kebanyakan dari mereka bukan pembaca XDA yang rajin).
Setelah OEM mendapatkan BSP, mereka akan mem-porting ROM-nya, dan menerapkan semua perubahannya ke ROM. Mereka akan menumpuk bloatware mereka, dan menambahkan tampilan kartun mengerikan yang akan terlihat lebih cocok di Anime remaja. Kemudian mereka akan mengujinya.
Banyak.
Ada berbagai macam persyaratan yang harus dipatuhi ponsel Anda. Jaringan seluler dirancang untuk memercayai peralatan pengguna (yang kita sebut telepon) untuk berperilaku benar. Ini berarti ada banyak pengujian yang diperlukan agar perangkat tersebut disetujui. Pembaruan perangkat lunak berisiko mengubah perilaku, sehingga segala sesuatunya perlu diuji kembali. Inilah sebabnya mengapa Anda biasanya akan melihat informasi tentang pembaruan perangkat lunak Sony yang akan datang dari layanan pengujian eksternal, yang mengonfirmasi bahwa firmware mematuhi persyaratan pengujian.
Sekarang... apa yang terjadi setelah satu atau dua pembaruan (atau dalam beberapa kasus, tidak ada pembaruan)? Pembuat SoC tidak akan memberikan BSP yang diperbarui kepada OEM. Lagi pula, pembuat SoC tidak akan mendapatkan banyak manfaat dari ini. OEM tidak menghasilkan uang lagi dari ponsel Anda sejak dijual. Dan saat ini, ponsel Anda tidak mendapatkan pembaruan versi utama lagi.
Mengurangi jumlah BSP yang ingin dikirimkan oleh OEM adalah cara terbaik untuk menghemat uang - jika Anda hanya memerlukan BSP saat ini, dan tidak bermaksud mengirimkan versi utama apa pun meningkat, ini akan menghemat uang pada pembelian dan lisensi SoC awal, tetapi dengan mengorbankan beberapa kutu buku yang marah di XDA, bertanya-tanya mengapa mereka tidak mendapatkan memperbarui.
Pembaruan itu rumit. Ada banyak orang berbeda yang terlibat dalam rantai ini. Semua ini tidak menjadi alasan bagi OEM untuk melihat kondisi pembaruan Android yang lesu dan menyedihkan saat ini. Meskipun demikian, ada beberapa tantangan nyata di sini.
Banyak OEM yang harus disalahkan karena memberikan janji yang berlebihan, dan under-delivering yang tak terelakkan yang sekarang kita kaitkan. Kenyataan yang menyedihkan adalah bagi sebagian besar OEM, pembaruan perangkat lunak hanyalah sebuah gangguan yang tidak dapat mereka lakukan.
Sektor seluler sebagian besar terjebak dalam pola pikir feature phone. Artinya, perangkat tidak pernah mendapat pembaruan apa pun. Uji sekali, kirimkan, dan jangan pernah melihat ke belakang. Dengan adanya masalah keamanan pada ponsel pintar modern, dan rumitnya menjalankan sistem operasi serba guna, dengan ratusan pustaka eksternal, hal tersebut bukan lagi suatu pilihan. Atau setidaknya itu tidak seharusnya menjadi. Google telah mengambil beberapa langkah untuk memperbaikinya, setidaknya dengan menerbitkan buletin keamanan dan patch untuk rilis yang ada Android (ingat bahwa hingga saat ini, satu-satunya cara untuk mendapatkan pembaruan keamanan adalah melalui versi OS Android utama yang baru!)
Namun sayangnya, ini tidak cukup. Meskipun Google terus merilis pembaruan, keamanan perangkat Anda masih bergantung pada pembuat SoC - karena pembuat SoC sangat ketakutan terhadap hal tersebut. seseorang mengetahui bagaimana mereka menyalakan beberapa LED atau mengeluarkan suara melalui speaker, mereka mengirimkan gumpalan biner dalam jumlah besar ke perangkat mereka. perangkat. Gumpalan ini berisi beberapa kode yang sangat tidak aman (lihat saja buletin keamanan Google sebelumnya jika menurut Anda ini berlebihan!), dan perlu diperbarui. Artinya, BSP yang diperbarui diperlukan.
Komputer desktop (dan lebih jauh lagi, laptop) memiliki arsitektur yang sangat berbeda dari perangkat seluler. Ponsel atau tablet Anda pada dasarnya adalah bongkahan silikon yang sangat eksklusif, dirancang secara terburu-buru oleh beberapa orang yang bermaksud baik, namun tidak memiliki cukup waktu untuk membuat sesuatu yang baik. Pasar bergerak begitu cepat sehingga mereka hampir tidak mampu mengikuti laju pemasaran yang menuntut peluncuran produk baru.
Ini berarti jalan pintas diambil - Anda tidak akan menemukan ponsel Anda didukung oleh kernel Linux arus utama, dan Anda akan menemukan setiap ponsel memiliki cara berbeda untuk melakukan booting. Namun, di laptop atau desktop Anda, vendor menetapkan beberapa cara standar untuk melakukan booting - sebelumnya MBR (master boot record) dengan BIOS, dan sekarang UEFI. Standarisasi ini memungkinkan untuk menjalankan perangkat lunak yang sama di setiap perangkat.
Meskipun ada beberapa langkah menuju hal ini baru-baru ini, terutama dengan program penjangkauan Sony dan program mereka kernel terpadu, menjalankan kernel jalur utama di sebagian besar ponsel tidak praktis, karena banyaknya peretasan khusus vendor baru yang diperkenalkan ke setiap perangkat.
Menyambungkan jack headphone dengan cara yang salah? Retas saja di driver! Tidak ada waktu untuk memperbaikinya dalam desain produksi.
Tim manufaktur telah memasang modul kamera secara terbalik pada produksi batch 1? Lakukan peretasan untuk memeriksa kode versi internal, dan balikkan videonya jika itu versi 1!
Peretasan seperti ini menyelesaikan masalah langsung, namun hanya mengikis permukaan dari perubahan aneh dan spesifik produk yang sedang terjadi. Heck, terkadang ada chip yang sama sekali berbeda dalam revisi berbeda pada ponsel yang sama, karena keputusan komersial. Hal ini menyebabkan peretasan pada driver dan keputusan aneh yang hanya masuk akal pada saat itu, agar ponsel berfungsi sehingga dapat dikirimkan minggu depan.
Meskipun masih ada upaya untuk mendukung chip ARM 64-bit agar dapat melakukan booting menggunakan UEFI, sejauh ini sudah ada upaya untuk melakukan booting ke chip ARM 64-bit. tidak ada pergerakan yang jelas menuju cara yang lebih terstandarisasi untuk mem-boot perangkat ARM. Dan itu menyedihkan, karena itu berarti ponsel akan terus dibuang jauh sebelum masa pakainya habis kehidupan kerja, karena terlalu mahal untuk mempertahankan utang teknis dan beban mereka perangkat lunak.
Namun di sisi lain, jika OEM hanya menghasilkan uang dari penjualan perangkat, bukankah mereka perlu memastikan orang terus membeli ponsel baru? Akankah pasar PC beralih ke model ini jika tidak ada momentum selama 30 tahun dan perangkat lunak lama yang menggunakan platform dan standar PC terbuka?
Ini adalah pertanyaan sulit tanpa sepengetahuan Qualcomm, yang sayangnya tidak kami miliki saat ini. Namun, kami dapat mengambil beberapa informasi dari API driver Android 7.0 dan persyaratan CTS. Persyaratan CTS menentukan apa yang diharapkan Google dari perangkat yang menjalankan firmware tertentu. "Palu besar" yang digunakan untuk menegakkan persyaratan ini adalah lisensi Google untuk menggunakan paket Layanan Google Play milik mereka - jika Anda tidak mematuhinya, Anda tidak dapat mengirimkan Google Apps pada perangkat tersebut. Sementara bagi sebagian orang, ini mungkin dianggap sebagai sebuah keuntungan, ini jelas bukan yang diinginkan dan diharapkan pengguna dari sebuah perangkat.
Android 7.0 belum menambahkan banyak perubahan pada HAL atau driver (seperti dijelaskan di atas), jadi ketidakcocokan apa pun kemungkinan besar tidak berasal dari sana secara spesifik. Namun, hal yang lebih mungkin menimbulkan masalah adalah diperkenalkannya a persyaratan baru untuk API grafis Vulkan, atau GLES 3.1, tersedia untuk lulus CTS.
Saat ini, banyak Systems-on-Chip (SoC) yang belum memiliki dukungan Vulkan pada prosesor grafisnya, termasuk MSM8974. Kemungkinan besar juga akan muncul masalah kompatibilitas dengan Android 7.0. Namun sekali lagi, tanpa pengetahuan mendalam dari Qualcomm, dan rencana masa depan mereka, sulit bagi kami untuk memberikan pernyataan pasti tanpa memenuhi syarat. Namun saat ini, kami yakin kemungkinan besar ini adalah kasus "sederhana" di mana Qualcomm menghentikan dukungannya chipset MSM8974 (di mata mereka) yang menua, dan tidak menyediakan BSP (paket dukungan board) untuk 7.0 pada platform itu. Jika hal tersebut terjadi, berarti OEM hampir pasti tidak akan mengirimkan versi 7.0 pada perangkatnya - mereka harus menemukan dukungan Vulkan atau GLEs 3.1 untuk GPU mereka, dan sumber GPU. kode adalah salah satu bagian tumpukan seluler yang dijaga sangat ketat (tanpa alasan nyata, kami akan menambahkan - lihat AMD, membuka sumber driver AMDGPU mereka sendiri di desktop untuk Linux). Namun sayangnya, grafik Vulkan dan akselerasi (GLES) secara umum sedikit lebih rumit daripada LED sederhana, jadi kita tidak akan melihat shim untuk memperkenalkan kompatibilitasnya.
Karena 7.0 belum lama dirilis, ada kemungkinan nyata bahwa chipset lain (selain sejumlah kecil dalam AOSP itu sendiri) akan ditinggalkan. tertinggal dari versi 6.0, karena masalah perangkat keras dan driver (yaitu tidak ada BSP yang diperbarui) atau kurangnya dukungan vendor SoC sehubungan dengan Vulkan atau GLES 3.1 API. Saat ini, baik Snapdragon 800 atau 801 tidak mendukung salah satu dari keduanya.
Taruhan terbaik adalah mengawasi ruang ini - Pengembang di XDA telah membuat kemajuan yang baik dengan port tidak resmi ke 7.0 untuk banyak perangkat yang tidak mendapatkan dukungan resmi 7.0 dari Google. Namun ini tanpa dukungan Vulkan atau GLES 3.1 - mungkin pengembang game di Android akan mulai melakukannya mengalami frustrasi melalui fragmentasi jika cukup banyak pengguna yang mulai menjalankan ROM khusus tanpa Vulkan atau GLES 3.1 mendukung?
Apple cenderung mendukung lini iPhone mereka pada versi iOS terbaru selama sekitar 5 tahun - iPhone 4s diluncurkan pada Oktober 2011, dan terus diperbarui hingga iOS 9. Namun, ia tidak akan menerima pembaruan iOS 10 yang akan datang, yang akan memberikan umur efektif ponsel ini selama 5 tahun, dengan asumsi iOS 10 diluncurkan sekitar bulan Oktober. Perlu dicatat bahwa Apple tidak selalu mendukung dukungan API grafis - iPhone 4s dan iPhone 5 tidak menampilkan API grafis Metal Apple, yang merupakan skenario yang agak mirip dengan yang terlihat pada Android Vulkan. Satu-satunya perbedaan adalah Apple terus mendukung perangkat lama tanpa API grafis baru.
Bagaimana menurutmu? Apakah Anda akan mem-flash ROM khusus di ponsel Anda untuk memperpanjang umurnya? Sudahkah Anda mengatakannya di komentar di bawah.