Kial via Android-a aplikaĵo ne povas aldoni sistemprofilon de VPN

Vi frapetas la vicon VPN en Agordoj, vidas profilon instalitan de iu alia kaj komencas serĉi la vokon, kiu aldonas unu. Tia voko ne ekzistas. Aplikaĵo povas malfermi propran tunelon per VpnService, sed la rikordoj en tiu listo apartenas al la platformo kaj al tiu kliento, kiu kreis ilin. Scii precize, kie staras la limo, ŝparas al vi semajnon da ĉasado de kaŝitaj klasoj.

Komencu per tio, kion montras la ekrano Agordoj

La listo VPN estas registro de profiloj instalitaj de la sistemo aŭ de kliento de vendisto: PPTP, L2TP/IPsec, IKEv2 kaj ĉiuj vicoj, kiujn puŝis OEM-aplikaĵo aŭ MDM. Ĉiu vico portas servilan adreson, akreditaĵojn kaj protokolan efektivigon, kiu vivas ekster via procezo. Kiam la uzanto frapetas Konekti tie, la kliento de la platformo levas la tunelon, ne via kodo. Tial la vico postvivas restartigon kaj tial malinstalo de via aplikaĵo neniam forigas ĝin.

De la flanko de la uzanto la listo aspektas kiel API-surfaco, loko, kie aldoni VPN devus esti unu intenco for. Ĝi ne estas. La solaj publikaj enirpunktoj, kiuj tuŝas ĝin, estas navigaj intencoj, kaj ĉio, kio skribas en ĝin, apartenas al la platformo aŭ al privilegiita komponanto.

Praktika sekvo: se subtena teksto diras al uzantoj aldoni la profilon en Agordoj, via aplikaĵo tute ne estas parto de tiu fluo.

Kion VpnService efektive donas al vi

VpnService kaj VpnService.Builder priskribas unu tunelon, kiun posedas via aplikaĵo. Vi aldonas adresojn, vojojn, DNS-servilojn kaj MTU, limigas trafikon per addAllowedApplication() aŭ addDisallowedApplication(), kaj poste establish() redonas ParcelFileDescriptor por TUN-interfaco. De tiu punkto la aplikaĵo legas IP-paketojn kaj skribas respondojn, kio signifas, ke la protokolo estas via por efektivigi aŭ enigi: OpenVPN, WireGuard, propra transporto.

Nenio en tiu sinsekvo parolas PPTP, L2TP/IPsec aŭ IKEv2. Builder havas neniun ŝaltilon, kiu dirus uzu la sistemklienton L2TP, kaj ne ekzistas rea voko, kiu lasus vin gvidi profilon, kiun la platformo jam posedas. Tio estas la vera limo, kaj ĝi estas limo de dezajno, ne manko de permesoj.

Do aplikaĵo tute povas esti VPN-kliento en Android. Ĝi simple ne povas esti administranto por la klientoj, kiuj venas kun la telefono.

La konsenta dialogo ne estas ornamo

Ĉar via tunelo povas kapti la trafikon de aliaj aplikaĵoj, la sistemo devigas la uzanton eksplicite aprobi ĝin. prepare() redonas Intent, kiun vi devas lanĉi, la aprobo estas ligita al via pako, kaj dum la tunelo funkcias la statusbreto montras daŭran indikilon. Dua VPN, kiu leviĝas, malŝaltas la unuan, ĉar Android funkciigas unu aktivan VPN samtempe.

Tiu regulo de unu aktiva faligas homojn en testado. Vi levas vian tunelon dum entreprena kliento estas konektita kaj konkludas, ke via kodo rompiĝis, dum la platformo simple ŝaltis for de la alia kliento. Aproboj povas esti revokitaj poste, kaj prepare() povas redoni null sur aparatoj, kie mankas la konsenta agado, do establish() ankoraŭ devas trakti malsukceson.

Kaŝitaj API-oj kaj agordaj intencoj

Pli malnovaj respondoj montras al klasoj com.android.internal kaj AIDL-interfacoj, kiujn uzas la enkonstruita kliento. Ili ne estas en la SDK, ili ŝanĝiĝas inter eldonoj sen sciigo, kaj aplikaĵbutikoj traktas tiun aliron kiel riskon. Rootigo de la aparato ankaŭ ne faras ilin stabilaj, ĉar root kaj aliro al kaŝitaj API estas nesamrilataj problemoj.

La subtenata naviga helpilo estas Settings.ACTION_VPN_SETTINGS, kies valoro estas android.net.vpn.SETTINGS. Solvu ĝin antaŭ lanĉo, ĉar kelkaj OEM-konstruoj ne liveras tiun agadon, kaj revenu al skribitaj paŝoj, kiam la solvo malsukcesas. Ĝi kondukas la uzanton al la ekrano kaj agordas nenion.

La vojoj de aparatposedanto kaj MDM estas la escepto, kiun homoj kutime celas. DevicePolicyManager povas nomumi pakon de ĉiam-aktiva VPN, kaj administritaj agordoj povas antaŭŝuti agordojn por kliento, kiu subtenas ilin, sed tio ankoraŭ ne estas la publika SDK verkanta PPTP-profilon.

Iru la decidon de la uzanta flanko

Se via produkto devas porti trafikon, planu VpnService plus veran protokolstakon, kaj buĝetu tempon por la konsenta fluo kaj la regulo de unu VPN. Se la celo estas konekti al ekzistanta entreprena profilo, via tasko estas gvidado: profundligilo al la agorda ekrano, dokumentu la kampojn, kaj lasu la platformklienton fari la tuneladon. Se la aplikaĵo nur bezonas atingi privatan finpunkton, ĝi tute ne bezonas propran tunelon.

Skribu tiun decidon antaŭ ol skribi kodon, ĉar la tri vojoj havas preskaŭ nenion komunan post la unua sprinto.

Lasta kontrolo antaŭ ol vi komencu: ĉu la postulo diras, ke nia aplikaĵo konektiĝas, aŭ ke la aparato konektiĝas? La unua estas VpnService, la dua estas profilo, kiun vi ne povas krei. Ĝuste formuli tiun frazon estas pli malmultekosta ol ajna refaktoro.