Jawaban cepat: Pembaruan OTA (over-the-air) adalah perubahan software yang dikirim ke perangkat lewat jaringan tanpa kabel atau instalasi fisik baru. Aplikasi OTA adalah aplikasi yang benar-benar terpasang dan menarik update tersebut setelah diunduh dari store atau image pabrik. Di ponsel, istilah ini mencakup keduanya OTA perangkat (contohnya update sistem Android) dan OTA level aplikasi (live updates ke lapisan web di aplikasi Capacitor atau Cordova, dan live updates ke bundle JavaScript di aplikasi React Native).
Untuk batasan yang sesuai kebijakan toko, baca panduan lengkap OTA update yang sesuai kebijakan app store. Untuk live delivery level produk, lihat Capacitor live updates yang lebih cepat dan cara kerja live update untuk Capacitor.
OTA perangkat dan firmware vs OTA level aplikasi
OTA perangkat dan firmware memperbarui sistem operasi atau firmware radio. Pembaruan OTA Android dari Google atau OEM menggantikan partisi sistem. iOS menggunakan jalur over-the-air serupa untuk rilis platform. Pengguna melihat ini di pengaturan sistem, bukan di catatan rilis produk Anda.
OTA level aplikasi update yang dimuat aplikasi Anda saat runtime setelah instalasi sudah ada di perangkat. Pada stack hybrid, ini biasanya berarti JavaScript, HTML, CSS, gambar, konfigurasi, dan teks di dalam WebView atau mesin JavaScript. Binary native yang sudah lolos review App Store atau Google Play tetap berada di tempatnya sampai Anda merilis build store baru.
| Lapisan | Apa yang berubah | Contoh umum |
|---|---|---|
| OTA Perangkat | OS, driver, patch keamanan | Prompt update sistem Android |
| Update aplikasi via store | APK atau IPA lengkap | Update in-app Google Play |
| OTA Level Aplikasi | Web bundle dan aset runtime | channel Capacitor live update |
Tim Cordova dan Capacitor hampir selalu maksudnya baris ketiga saat bertanya soal aplikasi over the air atau rilis OTA di CI. Kalau butuh definisi yang lebih sempit, apa itu OTA update membahas pemisahan yang sama dengan contoh mobile.
Apakah update OTA aman dan diizinkan Apple dan Google?
Keamanan tergantung pada signing, pemeriksaan integritas, channel bertahap, rollback, dan telemetri, bukan pada kata OTA. Updater produksi harus memverifikasi manifest, menyimpan bundle yang sudah terbukti baik, dan mengaktifkannya secara atomik agar unduhan parsial tidak merusak aplikasi.
Kebijakan store terpisah dari rekayasa keamanan. Perjanjian Lisensi Program Apple Developer (bagian 3.3.1(B)) membatasi code yang diinterpretasikan dan dikirimkan setelah review. Konten ini harus tetap dalam tujuan utama aplikasi dan menghindari penghindaran keamanan platform. Panduan Review Aplikasi 2.5.2 juga melarang code yang diunduh untuk memperkenalkan atau mengubah fitur. Panduan 2.5.19 melarang fitur tersembunyi atau yang tidak terdokumentasi. Google Play umumnya mengizinkan pembaruan untuk JavaScript dan code web lainnya yang dieksekusi dalam WebView atau mesin JavaScript yang dibundel, selama sesuai dengan fungsionalitas yang dideklarasikan aplikasi. Plugin native, izin baru, atau penggantian SDK tetap harus melalui rilis toko di kedua platform.
Capgo panduan pembaruan OTA yang sesuai aturan toko aplikasi memetakan aturan tersebut ke pilihan rilis sehari-hari. Untuk build vs buy pada infrastruktur, lihat solusi pembaruan aplikasi open source vs proprietary.
Table of Contents
- OTA perangkat dan firmware vs OTA tingkat aplikasi
- Apakah update OTA aman dan diizinkan Apple dan Google?
- Definisi Praktis OTA Updates
- Bagaimana OTA update benar-benar sampai ke perangkat
- Perbandingan OS Updates, In-App Updates, dan Web Bundle Live Updates
- Tingkat Adopsi dan Pentingnya bagi Engineering
- Trade-off Nyata Saat Melakukan Update Over the Air
- Framework Klasifikasi Perubahan: OTA vs Rilis Store
- Kontrol Keamanan agar OTA Aman Digunakan
- Pertanyaan Umum tentang OTA Update
- Kesimpulan dan Cara Memilih Pendekatan OTA
Definisi Praktis OTA Updates
Masalah seperti ini selalu muncul di Jumat sore. Alur checkout rusak, tim support menghubungi engineering, dan seseorang di tim mulai bertanya apakah ini butuh rilis ke store atau bisa langsung dikirim sekarang. Jika perubahannya hanya di web layer aplikasi hybrid, OTA bisa jadi pembeda antara pemulihan cepat dan akhir pekan panjang penuh menunggu.
Pada level yang paling sederhana, update over-the-air adalah update software yang dikirim langsung ke perangkat melalui jaringan nirkabel, bukan lewat kabel, installer desktop, atau kunjungan servis fisik. Dalam mobile computing, Apple menjadikan OTA sebagai pola distribusi utama saat menambahkan dukungan OTA update di iOS 5 pada tahun 2011. Alur dasarnya sangat langsung: vendor merilis versi baru, perangkat yang memenuhi syarat mendapat notifikasi, paket diunduh via Wi-Fi atau seluler, perangkat memverifikasinya, lalu menginstalnya secara lokal, biasanya setelah restart. Ringkasan Wikipedia tentang over-the-air updates menjelaskan model level perangkat tersebut dengan jelas.
Istilah ini sering membingungkan karena digunakan untuk beberapa layer yang berbeda. Salah satu layernya adalah sistem operasi, di mana Apple atau produsen perangkat Android merilis update platform. Cara lainnya adalah paket aplikasi, di mana alur in-app update Google Play dapat memperbarui paket aplikasi Android yang sudah didistribusikan. Cara ketiga adalah bundle web runtime, di mana aplikasi bergaya Capacitor dapat mengunduh JavaScript, CSS, gambar, atau teks setelah binary native lolos review.
Aturan praktis: jika aplikasi atau sistem operasi sudah terinstal di perangkat, dan versi baru datang lewat jaringan, bukan lewat instalasi fisik baru, berarti Anda sudah masuk ranah OTA.
Perbedaan ini penting karena istilah yang sama bisa merujuk pada jalur rilis yang sangat berbeda. Seorang product manager mungkin berkata “ship it over the air,” sementara jawaban teknisnya bergantung pada apakah perubahan tersebut menyentuh native code, interpreted code, atau sistem operasi itu sendiri.
Bagaimana OTA update benar-benar sampai ke perangkat
Pipeline ini terlihat sederhana dari luar, tetapi sistem OTA yang andal harus melakukan beberapa hal dalam urutan yang ketat. Publisher melakukan build untuk rilis, menandatanganinya, menghubungkannya dengan channel atau aturan versi, lalu menyediakannya untuk perangkat yang memenuhi syarat. Client melakukan check-in atau menerima notifikasi, mengunduh paket, memverifikasinya, melakukan staging, dan baru kemudian mengaktifkannya.
Bagian-bagian yang harus selaras
Download bukanlah instalasi, dan instalasi bukanlah aktivasi. Perangkat harus tahu bahwa artifact itu asli, lengkap, dan memang untuk versi app tersebut sebelum menyentuh runtime aktif. Itulah sebabnya sistem OTA yang baik memisahkan slot download dari dari slot aktif, lalu mengalihkan pointer hanya setelah verifikasi lolos.
Dalam praktiknya, titik rawan bisa diprediksi. Koneksi terputus saat download, versi yang salah masuk ke channel yang salah, paket gagal pengecekan integritas, atau app restart sebelum bundle baru siap. Sistem yang menganggap OTA sebagai fitur “ambil file lalu jalankan” biasanya belajar dari pengalaman pahit.
Alur OTA yang aman selalu mengasumsikan ada kegagalan di antara download dan aktivasi, lalu memberi app fallback yang sudah terbukti berfungsi.
Alur end-to-end terlihat di sebagian besar updater produksi, meskipun detail implementasinya berbeda tiap platform. Beberapa sistem mengandalkan background download agar pengguna bisa terus bekerja. Yang lain memakai alur foreground jika update terlalu penting untuk ditunda. Poin pentingnya adalah paket update melewati verifikasi, staging, aktivasi, dan recovery, bukan sekadar transfer.
Bagi tim yang mengintegrasikan ini ke CI/CD, trigger pengiriman juga penting. Build bisa dipublikasikan otomatis setelah tes lulus, lalu diekspos ke channel perangkat yang hanya bisa dilihat audiens yang tepat. Otomasi semacam ini membuat release engineering terasa bukan lagi sekadar mengirim aplikasi, tapi distribusi software yang terkontrol. Panduan tentang cara tool CI/CD memicu OTA update ini adalah referensi yang berguna untuk workflow tersebut.
Perbandingan OS Updates, In-App Updates, dan Web Bundle Live Updates
Sumber kebingungan terbesar adalah bahwa OTA bisa berarti tiga hal berbeda, dan masing-masing punya aturan sendiri. OTA sistem operasi dikontrol oleh pemilik platform. In-app update lewat app store memperbarui paket aplikasi. Update web-bundle runtime mengubah aset yang dimuat aplikasi terinstal saat diluncurkan.
Tiga lapisan tempat OTA beroperasi
| Lapisan | Artifact Diperbarui | Gating | Ulasan Toko |
|---|---|---|---|
| OTA level OS | Sistem operasi dan patch-nya | Kebijakan signing dan rollout vendor platform | Bukan review app-store, tapi dikontrol platform |
| Update in-app | Android application package yang terdistribusi | Alur update Google Play, fleksibel atau langsung | Lewat Store |
| Web-bundle live update | JavaScript, CSS, copy, gambar, config, dan aset runtime lainnya | Aturan channel dan eligibilitas yang ditentukan aplikasi | Biasanya sudah lolos review native store |
Mekanisme in-app update Google Play sangat penting dipisahkan dari tools “live update”. Ini mendukung Android 5.0 ke atas, dan punya dua mode operasional. A update yang fleksibel mengunduh di background saat pengguna tetap memakai aplikasi, tetapi aplikasi harus mendeteksi status siap dan menyelesaikan instalasi secara eksplisit. An update langsung memblokir pengguna dengan alur full-screen dan mewajibkan instalasi plus restart sebelum bisa digunakan kembali. Dokumentasi in-app update Google adalah referensi paling jelas untuk perbedaan tersebut.
Perbedaan itu membentuk desain aplikasi. Update fleksibel mengurangi gangguan, tetapi code lama tetap berjalan sampai aplikasi menyelesaikan handoff. Immediate update mengurangi version skew, yang berguna untuk perbaikan mendesak, tetapi juga mengganggu sesi. Untuk aplikasi bergaya Capacitor, pemisahan praktisnya bahkan lebih tajam karena aset web sering dapat bergerak independen dari binary native, sementara kapabilitas native tetap butuh jalur package-update normal.
Jika Anda bekerja di Ionic, Capacitor, atau workflow di sekitar Electron, biasanya jalur-jalur ini dilapis, bukan memilih satu untuk selamanya. OS meng-update shell, store meng-update binary, dan OTA meng-update web payload. Itu bukan duplikasi, melainkan version control di lapisan stack yang berbeda.
Tingkat Adopsi dan Pentingnya bagi Engineering
OTA hanya relevan jika perangkat akhirnya memakai versi baru. Data historis iOS dari Apple menunjukkan apa yang bisa dilakukan distribusi nirkabel yang dikelola terpusat ketika satu pemilik platform mengontrol signing, kelayakan, notifikasi, dan pengiriman. Apple melaporkan bahwa 81% dari seluruh iPhone aktif sudah menjalankan iOS 16 pada Februari 2023, dan 90% di antara iPhone yang diperkenalkan dalam empat tahun sebelumnya per Juni 2023. Kemudian, Apple melaporkan 76% iPhone yang dirilis dalam empat tahun terakhir sudah menjalankan iOS 18 pada awal 2025, dibandingkan dengan 74% menjalankan iOS 26 sekitar lima bulan setelah rilis 15 September 2025, diukur pada 12 Februari 2026. Ringkasan Computerworld atas data adopsi Apple adalah tempat praktis untuk melihat angka-angka itu dalam satu tempat.
Apa arti angka tersebut bagi engineer
Poin pertama adalah OTA yang dikelola secara terpusat bisa mencapai adopsi mayoritas dalam hitungan bulan. Poin kedua adalah adopsi tidak pernah instan dan tidak pernah menjangkau semua orang sekaligus. Perangkat lama, pilihan pengguna, keterbatasan penyimpanan, masalah konektivitas, staged rollout, dan persepsi risiko membuat sebagian perangkat tertahan di versi lama.
Sisa perangkat itulah sebabnya sistem OTA produksi butuh lebih dari sekadar endpoint download. Sistem itu butuh targeting versi, verifikasi integritas, telemetri, penanganan kegagalan, dan mekanisme rollback atau recovery. Tanpa kontrol tersebut, Anda bisa merilis update dengan cepat tetapi tetap tidak tahu siapa yang menerimanya, siapa yang crash saat startup, atau audiens mana yang butuh rollback.
Metrik adopsi bukan sekadar angka vanity. Metrik itu bukti bahwa mekanisme rilis menjangkau basis pengguna terinstal dengan cukup aman untuk dipercaya.
Bagi tim yang mengevaluasi platform live-update, visibilitas rilis dengan cepat menjadi persyaratan produk inti. Contoh metrik adopsi Capgo adalah ilustrasi bagus tentang bagaimana tim biasanya memikirkan kesehatan rollout dalam praktiknya.
Trade-off Nyata Saat Melakukan Update Over the Air
OTA terasa cepat karena melewati antrean store, tapi kecepatan itu punya budget interupsi. Sebuah update yang fleksibel memungkinkan pengguna tetap bekerja saat bundle baru di-download, yang bagus untuk kenyamanan tapi berisiko untuk perbaikan mendesak karena code lama bisa terus berjalan sampai aplikasi secara eksplisit menyelesaikan update. Sebuah update langsung memangkas version skew lebih cepat, tapi memblokir pengguna dan memaksa restart.
Biaya yang harus dibayar demi kecepatan
Trade-off itu muncul di tiga aspek. Pertama, UX. Update paksa bisa merusak alur di tengah sesi, dan itu terutama terasa di aplikasi consumer. Kedua, keamanan rilis. OTA memperluas blast radius dari package yang buruk jika signing, kontrol channel, atau logika rollback Anda lemah. Ketiga, risiko kebijakan, karena tim bisa tergoda mendorong perubahan yang seharusnya masuk ke rilis store.
Jika pengguna Anda ingin kontrol lebih ketat atas kapan pembaruan dilakukan, mekanisme teknisnya sama pentingnya dengan kebijakan produk. Tinjauan praktis seperti panduan SpecStory tentang kontrol update berguna karena mengingatkan tim bahwa pengguna mengalami update sebagai gangguan, bukan abstraksi.
Strategi rollout yang matang biasanya menggunakan channel dan audiens untuk mengontrol gangguan tersebut. Pengguna beta melihat satu stream, staging melihat stream lain, dan production menggunakan jalur paling konservatif. Ini memberi tim engineering cara untuk bergerak cepat tanpa membuat setiap rilis menjadi kejadian all-or-nothing.
Delta updates yang mengurangi ukuran payload juga bisa membantu saat bandwidth atau startup time menjadi krusial, namun download yang lebih kecil tetap harus diperlakukan sebagai rilis lengkap yang terverifikasi sebelum aktivasi. Ukuran lebih kecil tidak berarti lebih aman kecuali jika integrity checks sudah diterapkan.
Framework Klasifikasi Perubahan: OTA vs Rilis Store
Inilah bagian yang paling dibutuhkan kebanyakan tim. Pertanyaannya bukan “bisakah kita pakai OTA?” melainkan “perubahan apa yang kita buat, dan jalur rilis mana yang layak untuk perubahan tersebut?” Cara yang berguna untuk memutuskan adalah mengklasifikasikan setiap pull request sebelum di-ship.
Aturan keputusan praktis untuk engineer
Mulailah dengan artifact-nya, bukan labelnya. Logika JavaScript, CSS, copy, gambar, konfigurasi, dan aset interpreted atau web-layer lainnya biasanya cocok untuk OTA jika tetap sesuai dengan tujuan aplikasi dan batasan yang telah ditinjau. Plugin native, izin, perubahan SDK, dan apa pun yang mengubah tujuan utama aplikasi harus masuk ke rilis store.
Perbedaan ini penting karena “hanya JavaScript” tidak otomatis aman secara kebijakan. Kelonggaran Apple untuk code yang diinterpretasikan bersifat bersyarat; tidak boleh mengubah tujuan utama aplikasi, mengakali keamanan platform, atau menambahkan fungsionalitas yang belum ditinjau. Jadi tim tidak cukup bertanya “apakah ini JS?”. Pertanyaan yang lebih tepat: apakah perubahan ini mengubah fungsi dasar aplikasi?
Tabel klasifikasi praktis berikut dapat membantu:
- Logika layer web atau teks UI, biasanya OTA jika tetap dalam perilaku yang disetujui.
- Aset dan gambar, biasanya OTA jika tidak mengubah kapabilitas native.
- Konfigurasi dan flag backend, biasanya OTA jika client sudah mendukungnya.
- Plugin native, izin, atau perubahan SDK, rilis store.
- Perubahan campuran yang ambigu, gunakan rilis binary sebagai default dan catat alasan kebijakannya.
Jika pull request menyentuh perilaku web-layer sekaligus kapabilitas native, sisi native yang menang. Anggap sebagai rilis store kecuali perubahannya jelas bisa dipisahkan.
Aturan itu menjaga release train tetap jujur. Ini juga memberi tim produk dan QA kosakata bersama, yang lebih penting dari dugaan orang saat timeline mengetat.
Kontrol Keamanan agar OTA Aman Digunakan
OTA yang aman adalah masalah supply-chain dulu, baru fitur download. Updater produksi harus mengautentikasi bundle, memverifikasi integritas sebelum aktivasi, menyimpan versi known-good, dan membuat aktivasi bersifat atomik agar download yang rusak tidak bisa menggantikan rilis yang sedang berjalan dengan artefak parsial. Panduan verifikasi signature ini membahas sisi kepercayaan dari model tersebut dengan baik.
Kontrol wajib dalam setiap sistem OTA yang serius
Kontrol pertamanya adalah signing. Manifest dan aset yang ditunjuknya harus ditandatangani, lalu diverifikasi sebelum aplikasi mempercayainya. Yang kedua adalah channel binding, di mana rilis diikat ke versi aplikasi dan audiens agar perangkat yang salah tidak mengonsumsi bundle yang salah. Yang ketiga adalah inactive-slot download, yang menjaga payload baru tetap terpisah hingga semua pemeriksaan lulus.
Setelah itu datang bagian yang sering dilewati tim, aktivasi atomik. Aplikasi harus beralih ke bundle baru hanya setelah hash dan tanda tangan cocok, bukan di tengah unduhan atau saat restart yang gagal. Bundle sebelumnya yang immutable penting di sini, karena rollback hanya berfungsi jika versi terakhir yang diketahui baik masih tersedia.
Pembaruan diferensial dapat membantu mengurangi bandwidth, tetapi bukan jalan pintas untuk menghindari verifikasi. Delta masih harus direkonstruksi dan diperiksa terhadap bundle target lengkap sebelum aplikasi menggunakannya. Jika tidak, Anda hanya membuat payload lebih kecil, bukan rilis lebih aman.
Bagian terakhir adalah telemetri. Saat startup, aplikasi harus mencatat bundle aktif, hasil instalasi, crash-loop atau kegagalan peluncuran apa pun, dan keputusan rollback. Catatan itulah yang mengubah insiden aneh menjadi sesuatu yang bisa dijelaskan dan diperbaiki oleh tim.
Untuk lingkungan yang diatur, aturan operasinya sederhana. Jaga perubahan kemampuan native di biner yang ditinjau toko, batasi OTA untuk perubahan lapisan web yang kompatibel, gunakan audiens bertahap, dan pastikan pemulihan otomatis tetap aktif.
Pertanyaan Umum tentang OTA Update
Apakah aplikasi OTA itu nyata?
Ya. Aplikasi OTA adalah aplikasi mobile biasa yang mengunduh pembaruan lewat Wi-Fi atau seluler setelah instalasi. Produsen perangkat memakai OTA untuk patch sistem operasi. Aplikasi hybrid memakai OTA tingkat aplikasi untuk memperbarui lapisan web di dalam Capacitor atau shell Cordova. Aplikasi React Native memakai OTA tingkat aplikasi untuk memperbarui bundle JavaScript mereka.
Apakah update OTA berfungsi di Android dan iOS?
Ya, tapi bentuknya berbeda. Android bisa memperbarui OS, APK Play Store lewat in-app updates, atau bundle web di dalam aplikasi hybrid. iOS memakai OTA untuk update sistem. OTA tingkat aplikasi biasanya memperbarui JavaScript, HTML, CSS, dan aset di dalam shell WebView yang sudah ditinjau. Perubahan plugin native atau izin tetap butuh binary store baru di kedua platform.
Apakah update OTA diizinkan di App Store dan Google Play?
Aturan store mengizinkan banyak perubahan lapisan web via OTA selama tidak mengubah tujuan utama aplikasi atau melewati keamanan platform. Apple Developer Program License Agreement (bagian 3.3.1(B)) menetapkan kondisi code yang ditafsirkan. App Review Guidelines 2.5.2 melarang code yang diunduh yang menambah atau mengubah fitur. Guideline 2.5.19 melarang fitur tersembunyi atau tidak terdokumentasi. Google Play mengizinkan update JavaScript dan code web di dalam WebView atau mesin JavaScript selama tetap sesuai perilaku yang dideklarasikan aplikasi. Lihat update OTA yang sesuai app-store untuk checklist praktis.
Apa bedanya update OTA Android dan OTA aplikasi?
OTA sistem Android memperbarui firmware dan gambar OS dari pembuat perangkat atau operator. OTA Aplikasi memperbarui apa yang dimuat aplikasi Anda setelah instalasi, seperti web bundle baru, konfigurasi, atau teks. In-app updates di Google Play adalah jalur ketiga yang menggantikan APK yang didistribusikan. Sebutkan lapisan mana yang Anda maksud sebelum merencanakan rilis.
Apakah Anda harus membangun atau membeli sistem pembaruan OTA?
Bangun jika Anda membutuhkan kontrol penuh, dapat memelihara penandatanganan, channel, rollback, dan telemetri sendiri, serta memiliki kapasitas tinjauan keamanan. Beli atau gunakan platform terkelola jika Anda menginginkan rollout lebih cepat, infrastruktur hosted, dan alur kerja yang terbukti sesuai kebijakan toko. Bandingkan trade-off dalam solusi pembaruan aplikasi open source vs proprietary sebelum Anda berkomitmen.
Apa itu rilis OTA untuk aplikasi mobile?
Sebuah rilis OTA adalah paket ber-versi yang dipublikasikan ke channel, diunduh oleh klien yang memenuhi syarat, diverifikasi, distag, dan diaktifkan tanpa menginstal ulang dari toko. Untuk aplikasi bergaya Capacitor, ini biasanya berupa web bundle yang ditandatangani. Pipeline rilis yang sama dapat mengatur audiens beta, staging, dan produksi.
Kesimpulan dan Cara Memilih Pendekatan OTA
Keputusan OTA yang baik biasanya membosankan dengan cara terbaik. Klasifikasikan perubahan, pilih channel yang tepat, tandai dan verifikasi bundle, rencanakan rollback, dan pantau telemetri. Jika ada bagian yang terasa tidak jelas, perubahan itu sebaiknya lewat jalur store.
Pertanyaan yang layak diajukan ke vendor
- Bisakah melakukan signed manifests dan verifikasi aset? Jika tidak, model trust terlalu lemah untuk produksi.
- Apakah mendukung staged channels dan penargetan audiens? Anda butuh kontrol, bukan satu saklar global.
- Apakah rollback otomatis dan dapat diamati? Jalur pemulihan yang harus diingat secara manual itu rapuh.
- Apakah ada logs per-perangkat? Tanpa itu, tim support dan engineering hanya menebak-nebak.
- Bisakah CI/CD memicu rilis melalui API? Rilis manual tidak scalable.
- Apakah mendukung differential updates? Itu bisa membantu, tapi hanya jika integrity checks tetap terjaga.
Jika Anda membandingkan platform, pola otomasi deployment adalah cara yang baik untuk menilai apakah tool tersebut cocok untuk release engineering sungguhan atau sekadar marketing copy. Itu sangat relevan bagi tim yang butuh otomasi tanpa melepas kendali.
Capgo adalah salah satu opsi di area ini bagi tim CapacitorJS yang membutuhkan update web-bundle bertanda tangan, rollout berbasis channel, rollback, dan telemetri rilis. Jika tim Anda ingin memisahkan perubahan OTA-safe dari perubahan yang terikat store, kunjungi Capgo dan lihat apakah workflow-nya cocok dengan cara Anda ship.
