Wêrom't jo Android-app gjin systeem-VPN-profyl tafoegje kin

Jo tikke op 'e VPN-rige yn Ynstellings, sjogge in profyl dat immen oars ynstallearre hat, en begjinne te sykjen nei de oprop dy't ien tafoeget. Sa'n oprop is der net. In app kin in eigen tunnel iepenje fia VpnService, mar de ynskriuwings yn dy list hearre ta it platfoarm en ta hokker klant dan ek dy't se makke hat. Krekt witte wêr't de grins leit, besparret jo in wike jacht op ferburgen klassen.

Begjin mei wat it skerm Ynstellings sjen lit

De VPN-list is in register fan profilen dy't it systeem of in klant fan in leveransier ynstallearre hat: PPTP, L2TP/IPsec, IKEv2 en alle rigen dy't in OEM-app of in MDM der yn skood hat. Eltse rige draacht in serveradres, oanmeldgegevens en in protokolimplementaasje dy't bûten jo proses libbet. As de brûker dêr op Ferbine tikket, hellet de klant fan it platfoarm de tunnel omheech, net jo koade. Dêrom oerlibbet de rige in werstart en dêrom ferwideret it de-ynstallearjen fan jo app him nea.

Fan 'e kant fan 'e brûker liket de list op in API-oerflak, in plak dêr't it tafoegjen fan in VPN ien intent fuort wêze moat. Dat is it net. De iennige iepenbiere yngongspunten dy't him reitsje binne navigaasje-intents, en alles wat der yn skriuwt heart ta it platfoarm of ta in privilegiearre komponint.

Praktyske gefolch: as in stiptekst brûkers seit om it profyl yn Ynstellings ta te foegjen, is jo app hielendal gjin part fan dy stream.

Wat VpnService jo eins jout

VpnService en VpnService.Builder beskriuwe ien tunnel dy't jo app besit. Jo foegje adressen, rûtes, DNS-servers en in MTU ta, jo beheine ferkear mei addAllowedApplication() of addDisallowedApplication(), en dan jout establish() in ParcelFileDescriptor foar in TUN-ynterface werom. Fan dat punt ôf lêst de app IP-pakketten en skriuwt antwurden, wat betsjut dat it protokol fan jo is om te ymplementearjen of yn te bouwen: OpenVPN, WireGuard, in eigen transport.

Neat yn dy searje praat PPTP, L2TP/IPsec of IKEv2. Builder hat gjin skeakel dy't seit brûk de L2TP-klant fan it systeem, en der is gjin callback dy't jo in profyl bestjoere lit dat it platfoarm al besit. Dat is de echte grins, en it is in ûntwerpgrins, net in gat yn 'e tastimmingen.

Sa kin in app grif in VPN-klant wêze op Android. Hy kin gewoan gjin behearder wêze foar de klanten dy't mei de telefoan komme.

De tastimmingsdialooch is gjin fersiering

Om't jo tunnel it ferkear fan oare apps fange kin, makket it systeem dat de brûker dat eksplisyt goedkart. prepare() jout in Intent werom dy't jo starte moatte, de goedkarring is oan jo pakket bûn, en wylst de tunnel oan is lit de statusbalke in permaninte yndikator sjen. In twadde VPN dy't omheech giet, deaktivearret de earste, om't Android ien aktyf VPN tagelyk draait.

Dy regel fan ien aktyf struikelt minsken by it testen. Jo helje jo tunnel omheech wylst in bedriuwsclient ferbûn is en konkludearje dat jo koade stikken is, wylst it platfoarm gewoan fan 'e oare klant ôf skeakele hat. Goedkarringen kinne letter ynlutsen wurde, en prepare() kin null weromjaan op apparaten dêr't de tastimmingsaktiwiteit mist, dus establish() moat noch hieltyd mislearring ôfhandelje.

Ferburgen API's en ynstellings-intents

Aldere antwurden wize nei com.android.internal-klassen en AIDL-ynterfaces dy't de ynboude klant brûkt. Se binne net yn 'e SDK, se feroarje tusken releases sûnder warskôging, en app-winkels sjogge dy tagong as in risiko. It rooten fan it apparaat makket se ek net stabyl, om't root en tagong ta ferburgen API's ûnôfhinklike problemen binne.

De stipe navigaasjehelp is Settings.ACTION_VPN_SETTINGS, waans wearde android.net.vpn.SETTINGS is. Los it op foardat jo it starte, om't guon OEM-builts dy aktiviteit net leverje, en fal werom op skreaune stappen as it oplossen mislearret. It bringt de brûker nei it skerm en konfigurearret neat.

Apparaat-eigener- en MDM-paden binne de útsûndering dy't minsken meastentiids bedoele. DevicePolicyManager kin in altyd-aktive VPN-pakket oanwize, en behearde konfiguraasjes kinne ynstellings foarôf lade foar in klant dy't se stipet, mar dat is noch hieltyd net de iepenbiere SDK dy't in PPTP-profyl skriuwt.

Rin it beslút fan 'e brûker syn kant ôf

As jo produkt ferkear drage moat, planje dan VpnService plus in echte protokolstapel, en budgettearje tiid foar de tastimmingsstream en de ien-VPN-regel. As it doel is om te ferbinen mei in besteand bedriuwsprofyl, is jo wurk begelieding: djippe keppeling nei it ynstellingsskerm, dokumintearje de fjilden, en lit de klant fan it platfoarm it tunneljen dwaan. As de app allinnich in privee einpunt berikke moat, hat hy hielendal gjin eigen tunnel nedich.

Skriuw dat beslút op foardat jo koade skriuwe, om't de trije paden nei de earste sprint hast neat mienskiplik hawwe.

In lêste kontrôle foardat jo begjinne: seit de eask dat ús app ferbynt, of dat it apparaat ferbynt? It earste is VpnService, it twadde is in profyl dat jo net meitsje kinne. Dy sin goed krije is goedkeaper as hokker refaktoring dan ek.