Sut i wirio mewn cod a yw VPN wedi cysylltu ar Android

Ni allwch ofyn i Android a yw VPN wedi cysylltu. Nid yw VpnService yn datgelu getter cysylltiad, a'r system sy'n tynnu'r eicon allwedd yn y bar statws, nid unrhyw beth y gall eich ap ei ddarllen. Yr hyn y gallwch ei wneud yw gofyn cwestiwn culach i'r pentwr cysylltedd: pa rwydwaith mae traffig yr ap hwn yn ei ddefnyddio, ac a yw'r rhwydwaith hwnnw'n cario cludiant VPN. Mae'r llyfr gweithredu hwn yn mynd trwy'r gwiriadau yn y drefn sy'n osgoi canlyniadau positif ffug, o orchymyn shell ar y ddyfais hyd at y callback rydych yn ei adael yn rhedeg yn yr ap.

Gwiriwch y ddyfais o shell cyn cyffwrdd cod yr ap

Sicrhewch linell sylfaen yn gyntaf. Mae adb shell dumpsys connectivity yn argraffu pob rhwydwaith y mae'r system yn ei hadnabod, ac mae pob bloc yn rhestru ei gludiant, felly mae rhwydwaith VPN yn ymddangos gyda VPN yn y rhestr honno. Darllenwch floc y rhwydwaith diofyn cyn unrhyw beth arall, yna chwiliwch am rwydweithiau eraill sy'n cario'r un cludiant.

Mae dau allbwn yn ateb cwestiynau gwahanol. Nid yw bodolaeth rhwydwaith VPN yn hynod o'r un peth ag a yw eich ap yn ei ddefnyddio, ac ar ddyfais sydd â phroffil gwaith neu ail ddefnyddiwr gall y ddau fod yn wir ar unwaith tra bo'ch proses yn siarad â'r rhyngrwyd yn uniongyrchol. Y llinell rhwydwaith actif yw'r un sy'n penderfynu beth mae eich socedi'n ei wneud.

Gofynnwch am y rhwydwaith mae'r ap yn ei ddefnyddio

Mewn cod, y prawf gallu yw pedair llinell. Gofynnwch am ACCESS_NETWORK_STATE yn y maniffest, yna cymharwch alluoedd y rhwydwaith actif â chludiant VPN:

ConnectivityManager cm = (ConnectivityManager)
    context.getSystemService(Context.CONNECTIVITY_SERVICE);
Network active = cm.getActiveNetwork();
NetworkCapabilities caps = cm.getNetworkCapabilities(active);
boolean vpnInUse = caps != null
    && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

Mae'r ateb yn gul o fwriad: a yw rhwydwaith diofyn yr ap yn VPN ar hyn o bryd. Nid yw'n dweud dim am ba VPN, a yw'n perthyn i chi, nac a yw'r tiwnel yn cyrraedd ei ben pell. Triniwch true fel “mae traffig yn gadael trwy ryw diwnel” a chadwch eich cyfriflyfr eich hun ar wahân. Boole a olyga dri pheth ar unwaith yn dawel yw'r rheswm y mae sgrin gosodiadau'n gorffen adrodd bod y VPN i ffwrdd tra bo'r defnyddiwr yn pori trwyddo.

Pan fydd angen gwybod a oes unrhyw rwydwaith VPN yn bresennol yn lle hynny, iterwch cm.getAllNetworks() a phrofwch bob set alluoedd. Mae'r ddau ateb yn gwahanu ar ddyfais sy'n rhedeg VPN fesul ap sy'n cwmpasu apiau eraill ond nid eich un chi, a'r gwahaniaeth hwnnw yw ffynhonnell y rhan fwyaf o adroddiadau nam sy'n dweud nad yw'r ap yn gweld VPN sydd yn amlwg ymlaen.

Gwyliwch am newidiadau yn lle poulio

Mae poulio ar amserydd yn siâp anghywir ar gyfer y cwestiwn hwn, oherwydd mae newidiadau cyflwr yn cyrraedd fel digwyddiadau. Cofrestrwch gais sy'n cyfateb i gludiant VPN a gadewch i'r fframwaith ddweud wrthych pan fydd rhwydwaith cyfatebol yn ymddangos, yn diflannu neu'n newid:

NetworkRequest request = new NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .removeCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
    .build();
cm.registerNetworkCallback(request, callback);

Nid yw rhwydwaith VPN byth yn cario NET_CAPABILITY_NOT_VPN, felly mae'r tynnu ymadroddus yn dogfennu'r bwriad. Heb hynny mae'r cais yn dal i gyfateb, ond rhaid i'r person nesaf sy'n darllen y cod weithio hynny allan.

Mae'r cofrestriad yn perthyn i'r cwmpas sydd angen y sylwi, fel arfer sgrin neu wasanaeth blaen. Dadgofrestrwch yn onStop neu onDestroy, a pheidiwch â gadael callback ynghlwm wrth actifedd sydd eisoes wedi mynd. Ap heb gydran weladwy yw gwesteiwr gwael ar gyfer sylwedydd parhaol, a'r callbacks rydych yn eu hanghofio yw'r rhai sy'n chwalu ar ôl newid cyfluniad.

Cadwch dri chwestiwn ar wahân

Mae'r rhan fwyaf o'r dryswch yn y maes hwn yn dod o drin tri gwiriad gwahanol fel un. Maent yn defnyddio APIau gwahanol, a gall pob un fod yn wir tra bo'r lleill yn gau.

Y trydydd rhes yw'r un y mae pobl yn ceisio ei ateb ar y cleient, ac ni ellir ei ateb yno. Rhowch gronfa gyfeiriadau ei hun i gleientiaid VPN a darllenwch y cyfeiriad ffynhonnell ar y gweinydd; dyna'r unig dystiolaeth sy'n goroesi pan fydd defnyddiwr yn newid tiwnel yng nghanol sesiwn.

Trefn wirio sy'n diarddel canlyniadau positif ffug

Mae cod enghreifftiol hŷn sydd dal mewn cylchrediad yn galw getNetworkInfo(ConnectivityManager.TYPE_VPN). Mae'r alwad honno'n darfodus, ac mewn sawl rhyddhau roedd yn dychwelyd null hyd yn oed pan oedd VPN wedi cysylltu, a dyna pam mae cymaint o ddarnau copïedig yn edrych yn doredig ar ddyfais sy'n gweithio. Mae gwiriadau gallu'n osgoi'r fagl ac yn ymddwyn yr un fath o Android 5.0 ymlaen. Os ydych yn cynnal cronfa god sy'n dal i'w galw, disodlwch yr alwad yn lle ei lapio mewn cwympwr, oherwydd y cwympwr a gynhyrchodd yr ateb anghywir yn y lle cyntaf.

Mae un llwybr byr yn haeddu rhybudd. Mae cymharu'r cyfeiriad cyhoeddus a adroddir gan wasanaeth allanol â chyfeiriad allanfa'r VPN yn profi rhywbeth am y llwybr, ond mae'n ychwanegu cais trydydd parti at bob gwiriad, yn dibynnu ar y gwasanaeth hwnnw'n aros i fyny, a gellir ei storio neu ei rwystro. Cadwch ef fel diagnosig â llaw, byth fel y gwiriad cyflwr y tu mewn i'r ap.

Rhedwch y gwiriadau yn y drefn hon a stopiwch ar yr un cyntaf sy'n anghytuno ag adroddiad y defnyddiwr: rhestr gludiant shell, alluoedd y rhwydwaith actif, digwyddiadau callback wrth i chi doglo'r tiwnel, yna cyfeiriad ffynhonnell ar ochr y gweinydd. Os yw'r pedwar yn cyd-fynd ac mae'r ap yn dal i gamymddwyn, mae'r nam yn eich peiriant cyflwr eich hun yn hytrach nag yn nhyb Android o'r rhwydwaith.