Bakit Hindi Makapagdagdag ang Iyong Android App ng System VPN Profile

Tinatap mo ang hilera ng VPN sa Settings, nakikita ang profile na ininstol ng iba, at nagsisimulang hanapin ang tawag na nagdadagdag nito. Walang ganoong tawag. Makakabukas ang app ng sariling tunnel sa pamamagitan ng VpnService, ngunit ang mga entry sa listahang iyon ay pag-aari ng platform at ng kliyenteng gumawa ng mga ito. Ang malaman nang eksakto kung saan ang hangganan ay nagtitipid sa iyo ng isang linggo ng paghabol sa mga nakatagong klase.

Magsimula sa ipinapakita ng screen ng Settings

Ang listahan ng VPN ay isang rehistro ng mga profile na ininstol ng system o ng kliyente ng vendor: PPTP, L2TP/IPsec, IKEv2, at anumang hilera na itinulak ng OEM app o MDM. Bawat hilera ay may address ng server, mga kredensyal at implementasyon ng protocol na nabubuhay sa labas ng iyong proseso. Kapag tinap ng user ang Kumonekta doon, kliyente ng platform ang nagtataas ng tunnel, hindi ang iyong code. Kaya't ang hilera ay nananatili pagkatapos ng reboot at kaya't hindi ito inaalis ng pag-uninstall ng iyong app.

Sa panig ng user ang listahan ay mukhang API surface, isang lugar kung saan ang pagdaragdag ng VPN ay dapat isang intent lang ang layo. Hindi ito ganoon. Ang tanging pampublikong entry point na humahawak dito ay mga navigation intent, at lahat ng nagsusulat dito ay pag-aari ng platform o ng isang privileged na bahagi.

Praktikal na bunga: kung sinasabi ng text ng suporta sa mga user na idagdag ang profile sa Settings, ang iyong app ay hindi bahagi ng daloy na iyon.

Ano ang tunay na ibinibigay ng VpnService

Inilalarawan ng VpnService at VpnService.Builder ang isang tunnel na pag-aari ng iyong app. Nagdadagdag ka ng mga address, ruta, DNS server at MTU, nililimitahan ang trapiko gamit ang addAllowedApplication() o addDisallowedApplication(), at pagkatapos ay nagbabalik ang establish() ng ParcelFileDescriptor para sa TUN interface. Mula sa puntong iyon binabasa ng app ang mga IP packet at nagsusulat ng mga sagot, ibig sabihin, ang protocol ay sa iyo upang ipatupad o isama: OpenVPN, WireGuard, custom na transport.

Walang anuman sa pagkakasunod-sunod na iyon ang nagsasalita ng PPTP, L2TP/IPsec o IKEv2. Walang switch ang Builder na nagsasabing gamitin ang L2TP client ng system, at walang callback na nagpapahintulot sa iyong i-drive ang profile na pag-aari na ng platform. Ito ang tunay na hangganan, at ito ay hangganan ng disenyo, hindi butas sa mga pahintulot.

Kaya't ang isang app ay maaaring maging VPN client sa Android. Hindi lang ito maaaring maging manager ng mga kliyenteng kasama ng telepono.

Ang consent dialog ay hindi palamuti

Dahil ang iyong tunnel ay makakahuli ng trapiko ng ibang apps, hinihiling ng system na aprubahan ito ng user nang malinaw. Nagbabalik ang prepare() ng Intent na dapat mong ilunsad, ang pag-apruba ay nakatali sa iyong package, at habang nakaaktibo ang tunnel ay nagpapakita ang status bar ng permanenteng indicator. Ang pangalawang VPN na tumaas ay nagde-deactivate sa una, dahil isang aktibong VPN lang ang pinapatakbo ng Android sa isang pagkakataon.

Ang tuntunin ng isang aktibo ay nagpapadapa sa mga tao sa pagsubok. Itinataas mo ang iyong tunnel habang konektado ang corporate client at napagpasyahan mong sira ang iyong code, samantalang lumipat lang ang platform mula sa kabilang kliyente. Maaaring bawiin ang mga pag-apruba mamaya, at maaaring magbalik ng null ang prepare() sa mga device na walang consent activity, kaya't kailangan pa rin ng establish() na hawakan ang kabiguan.

Mga nakatagong API at settings intent

Ang mga lumang sagot ay tumutukoy sa mga klase ng com.android.internal at AIDL interface na ginagamit ng built-in na kliyente. Wala ang mga iyon sa SDK, nagbabago sila sa pagitan ng mga release nang walang abiso, at itinuturing ng mga app store na panganib ang ganoong access. Ang pag-root ng device ay hindi rin nagpapaging-matatag sa kanila, dahil ang root at access sa nakatagong API ay magkaibang problema.

Ang sinusuportahang navigation aid ay Settings.ACTION_VPN_SETTINGS, na ang halaga ay android.net.vpn.SETTINGS. I-resolve ito bago ilunsad, dahil may ilang OEM build na hindi naghahatid ng aktibidad na iyon, at bumalik sa mga nakasulat na hakbang kapag nabigo ang pag-resolve. Dinadala nito ang user sa screen at wala itong ini-configure.

Ang mga landas ng device-owner at MDM ang eksepsiyon na karaniwang tinutukoy ng mga tao. Maaaring magtalaga ang DevicePolicyManager ng always-on na VPN package, at ang mga managed configuration ay maaaring mag-preload ng settings para sa kliyenteng sumusuporta sa mga ito, ngunit hindi pa rin iyon ang pampublikong SDK na nagsusulat ng PPTP profile.

Suriin ang desisyon mula sa panig ng user

Kung kailangan ng iyong produkto na magdala ng trapiko, planuhin ang VpnService at isang tunay na protocol stack, at maglaan ng oras para sa consent flow at sa tuntunin ng isang VPN. Kung ang layunin ay kumonekta sa umiiral na corporate profile, ang trabaho mo ay gabay: deep link sa settings screen, idokumento ang mga field, at hayaang gawin ng platform client ang tunneling. Kung kailangan lang maabot ng app ang isang pribadong endpoint, hindi nito kailangan ng sariling tunnel.

Isulat ang desisyong iyon bago ka magsulat ng code, dahil ang tatlong landas ay halos walang pagkakatulad pagkatapos ng unang sprint.

Isang huling pagsusuri bago magsimula: sinasabi ba ng requirement na kumokonekta ang ating app, o kumokonekta ang device? Ang una ay VpnService, ang pangalawa ay profile na hindi mo magagawa. Ang gawing tama ang pangungusap na iyon ay mas mura kaysa anumang refactoring.