Anda mengetuk baris VPN di Setelan, melihat profil yang dipasang orang lain, dan mulai mencari panggilan yang menambahkannya. Panggilan seperti itu tidak ada. Aplikasi bisa membuka terowongannya sendiri lewat VpnService, tetapi entri di daftar itu milik platform dan milik klien mana pun yang membuatnya. Mengetahui persis di mana batasnya menghemat satu minggu Anda mengejar kelas tersembunyi.

Mulai dari apa yang ditampilkan layar Setelan

Daftar VPN adalah register profil yang dipasang sistem atau klien vendor: PPTP, L2TP/IPsec, IKEv2, dan baris apa pun yang didorong aplikasi OEM atau MDM. Setiap baris membawa alamat server, kredensial, dan implementasi protokol yang hidup di luar proses Anda. Saat pengguna mengetuk Sambungkan di sana, klien platform yang menaikkan terowongan, bukan kode Anda. Itulah sebabnya baris itu bertahan setelah reboot dan sebabnya menghapus instalasi aplikasi Anda tidak pernah menghapusnya.

Dari sisi pengguna daftar itu terlihat seperti permukaan API, tempat menambahkan VPN seharusnya hanya berjarak satu intent. Bukan begitu. Satu-satunya titik masuk publik yang menyentuhnya adalah intent navigasi, dan semua yang menulis ke sana milik platform atau komponen berhak istimewa.

Konsekuensi praktis: jika teks dukungan menyuruh pengguna menambahkan profil di Setelan, aplikasi Anda sama sekali bukan bagian dari alur itu.

Apa yang sebenarnya diberikan VpnService

VpnService dan VpnService.Builder menjelaskan satu terowongan yang dimiliki aplikasi Anda. Anda menambahkan alamat, rute, server DNS, dan MTU, membatasi lalu lintas dengan addAllowedApplication() atau addDisallowedApplication(), lalu establish() mengembalikan ParcelFileDescriptor untuk antarmuka TUN. Sejak titik itu aplikasi membaca paket IP dan menulis balasan, artinya protokolnya milik Anda untuk diimplementasikan atau disematkan: OpenVPN, WireGuard, transport khusus.

Tidak ada apa pun dalam urutan itu yang berbicara PPTP, L2TP/IPsec, atau IKEv2. Builder tidak punya sakelar yang mengatakan gunakan klien L2TP sistem, dan tidak ada callback yang memungkinkan Anda mengendalikan profil yang sudah dimiliki platform. Itulah batas sebenarnya, dan itu batas desain, bukan celah izin.

Jadi aplikasi benar-benar bisa menjadi klien VPN di Android. Hanya saja tidak bisa menjadi pengelola bagi klien yang dibawa ponsel.

Dialog persetujuan bukan hiasan

Karena terowongan Anda bisa menangkap lalu lintas aplikasi lain, sistem membuat pengguna menyetujuinya secara eksplisit. prepare() mengembalikan Intent yang harus Anda luncurkan, persetujuan terikat pada paket Anda, dan selama terowongan aktif bilah status menampilkan indikator permanen. VPN kedua yang naik menonaktifkan yang pertama, karena Android menjalankan satu VPN aktif dalam satu waktu.

Aturan satu-aktif itu membuat orang tersandung saat pengujian. Anda menaikkan terowongan sementara klien korporat tersambung dan menyimpulkan kode Anda rusak, padahal platform sekadar berpindah dari klien lain. Persetujuan bisa dicabut belakangan, dan prepare() bisa mengembalikan null pada perangkat yang tidak punya aktivitas persetujuan, jadi establish() tetap harus menangani kegagalan.

API tersembunyi dan intent setelan

Jawaban lama menunjuk ke kelas com.android.internal dan antarmuka AIDL yang dipakai klien bawaan. Itu tidak ada di SDK, berubah antar rilis tanpa pemberitahuan, dan toko aplikasi menganggap akses itu berisiko. Melakukan root pada perangkat juga tidak membuatnya stabil, karena root dan akses API tersembunyi adalah masalah yang tidak berkaitan.

Bantuan navigasi yang didukung adalah Settings.ACTION_VPN_SETTINGS, yang nilainya android.net.vpn.SETTINGS. Selesaikan itu sebelum meluncurkannya, karena sebagian build OEM tidak menyertakan aktivitas itu, dan beralih ke langkah tertulis jika penyelesaiannya gagal. Itu membawa pengguna ke layar dan tidak mengonfigurasi apa pun.

Jalur pemilik perangkat dan MDM adalah pengecualian yang biasanya dimaksud orang. DevicePolicyManager dapat menetapkan paket VPN yang selalu aktif, dan konfigurasi terkelola dapat memuat awal setelan untuk klien yang mendukungnya, tetapi itu tetap bukan SDK publik yang menulis profil PPTP.

Telusuri keputusan dari sisi pengguna

Jika produk Anda perlu membawa lalu lintas, rencanakan VpnService plus tumpukan protokol sungguhan, dan anggarkan waktu untuk alur persetujuan dan aturan satu VPN. Jika tujuannya tersambung ke profil korporat yang sudah ada, pekerjaan Anda adalah panduan: tautan dalam ke layar setelan, dokumentasikan kolomnya, dan biarkan klien platform melakukan terowongan. Jika aplikasi hanya perlu menjangkau titik akhir privat, ia sama sekali tidak perlu terowongan sendiri.

Tuliskan keputusan itu sebelum menulis kode, karena ketiga jalur hampir tidak punya kesamaan setelah sprint pertama.

Pemeriksaan terakhir sebelum mulai: apakah persyaratan mengatakan aplikasi kita yang tersambung, atau perangkat yang tersambung? Yang pertama adalah VpnService, yang kedua adalah profil yang tidak bisa Anda buat. Menyusun kalimat itu dengan benar lebih murah daripada refaktor apa pun.

Artikel terkait