Android లో VPN కనెక్ట్ అయిందో లేదో కోడ్లో ఎలా తనిఖీ చేయాలి
Android లో VPN కనెక్షన్ స్థితిని ఇచ్చే getter లేదు. నెట్వర్క్ సామర్థ్యాలను అడగండి, రవాణా మార్పులను గమనించండి, మరియు యాప్ సమ్మతి, పరికర స్థితి, సర్వర్ రుజువు వేరుగా ఉంచండి.
Android ను VPN కనెక్ట్ అయిందా అని అడగలేరు. VpnService కనెక్షన్ స్థితిని ఇచ్చే getter ను బహిర్గతం చేయదు, స్టేటస్ బార్లోని కీ చిహ్నాన్ని సిస్టమ్ గీస్తుంది, మీ యాప్ చదవగలిగే ఏదీ కాదు. మీరు చేయగలిగింది కనెక్టివిటీ స్టాక్ను మరింత సన్నని ప్రశ్న అడగడం: ఈ యాప్ ట్రాఫిక్ ఏ నెట్వర్క్ను ఉపయోగిస్తోంది, ఆ నెట్వర్క్ VPN రవాణాను మోస్తుందా. ఈ మార్గదర్శిని తప్పుడు పాజిటివ్లను నివారించే క్రమంలో తనిఖీలను నిర్వహిస్తుంది, పరికరంలోని shell ఆదేశం నుండి యాప్లో మీరు వదిలే callback వరకు.
యాప్ కోడ్ను తాకే ముందు shell నుండి పరికరాన్ని తనిఖీ చేయండి
మొదట ప్రాథమిక స్థితిని తీసుకోండి. adb shell dumpsys connectivity సిస్టమ్కు తెలిసిన ప్రతి నెట్వర్క్ను ముద్రిస్తుంది, ప్రతి బ్లాక్ తన రవాణాలను జాబితా చేస్తుంది, కాబట్టి VPN నెట్వర్క్ ఆ జాబితాలో VPN తో కనిపిస్తుంది. అన్నింటికీ ముందు డిఫాల్ట్ నెట్వర్క్ బ్లాక్ను చదవండి, తర్వాత అదే రవాణాను మోసే ఇతర నెట్వర్క్లను వెతకండి.
రెండు అవుట్పుట్లు వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. VPN నెట్వర్క్ ఉండటం మీ యాప్ దానిని ఉపయోగించడం ఒకటి కాదు, పని ప్రొఫైల్ లేదా రెండవ వినియోగదారు ఉన్న పరికరంలో మీ ప్రక్రియ ఇంటర్నెట్తో నేరుగా మాట్లాడుతున్నప్పుడు రెండూ ఒకేసారి నిజం కావచ్చు. మీ సాకెట్లు ఏమి చేస్తాయో నిర్ణయించేది యాక్టివ్ నెట్వర్క్ లైన్.
యాప్ ఉపయోగిస్తున్న నెట్వర్క్ను అడగండి
కోడ్లో సామర్థ్య పరీక్ష నాలుగు పంక్తులు. మానిఫెస్ట్లో ACCESS_NETWORK_STATE అడగండి, తర్వాత యాక్టివ్ నెట్వర్క్ సామర్థ్యాలను 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);
సమాధానం ఉద్దేశపూర్వకంగా సన్నగా ఉంది: యాప్ డిఫాల్ట్ నెట్వర్క్ ఇప్పుడు VPN గా ఉందా. ఏ VPN, అది మీదేనా, లేదా సొరంగం ఆవలి చివరను చేరుతుందా అనేది ఏమీ చెప్పదు. true ను “ట్రాఫిక్ ఏదో సొరంగం ద్వారా బయటకు వెళ్తుంది” అని భావించి మీ స్వంత లెక్కను వేరుగా ఉంచండి. మూడు విషయాలను నిశ్శబ్దంగా ఒకేసారి సూచించే బూలియన్ కావడమే, వినియోగదారు VPN ద్వారా బ్రౌజ్ చేస్తున్నప్పుడు సెట్టింగ్ల స్క్రీన్ VPN ఆఫ్ అని నివేదించడానికి కారణం.
దీనికి విరుద్ధంగా, ఏదైనా VPN నెట్వర్క్ ఉందా అని తెలుసుకోవాలంటే, cm.getAllNetworks() పై పునరావృతం చేసి ప్రతి సామర్థ్య సమితిని పరీక్షించండి. ఇతర యాప్లను కవర్ చేసే కానీ మీ యాప్ను కవర్ చేయని యాప్-నిర్దిష్ట VPN అమలవుతున్న పరికరంలో రెండు సమాధానాలు భిన్నమవుతాయి, ఆ భేదమే స్పష్టంగా ఆన్లో ఉన్న VPN యాప్కు కనిపించడం లేదు అనే చాలా బగ్ నివేదికల మూలం.
పోలింగ్కు బదులుగా మార్పులను గమనించండి
టైమర్పై పోలింగ్ ఈ ప్రశ్నకు తప్పుడు రూపం, ఎందుకంటే స్థితి మార్పులు సంఘటనలుగా వస్తాయి. VPN రవాణాకు సరిపోయే అభ్యర్థనను నమోదు చేయండి మరియు సరిపోయే నెట్వర్క్ కనిపించినప్పుడు, అదృశ్యమైనప్పుడు లేదా మారినప్పుడు ఫ్రేమ్వర్క్ మీకు చెప్పనివ్వండి:
NetworkRequest request = new NetworkRequest.Builder()
.addTransportType(NetworkCapabilities.TRANSPORT_VPN)
.removeCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
.build();
cm.registerNetworkCallback(request, callback);
VPN నెట్వర్క్ ఎప్పుడూ NET_CAPABILITY_NOT_VPN మోయదు, కాబట్టి స్పష్టంగా తీసివేయడం ఉద్దేశాన్ని నమోదు చేస్తుంది. అది లేకున్నా అభ్యర్థన సరిపోతుంది, కానీ తర్వాత కోడ్ చదివే వ్యక్తి దాన్ని తానే గుర్తించాలి.
నమోదు పరిశీలన అవసరమయ్యే పరిధికి చెందుతుంది, సాధారణంగా స్క్రీన్ లేదా ఫోర్గ్రౌండ్ సేవ. onStop లేదా onDestroy లో నమోదు రద్దు చేయండి, ఇప్పటికే వెళ్లిపోయిన యాక్టివిటీకి callback ను వేలాడదీయవద్దు. కనిపించే భాగం లేని యాప్ శాశ్వత పరిశీలకుడికి చెడు ఆతిథ్యం, మరియు మీరు మరచిపోయిన callback లే కాన్ఫిగరేషన్ మార్పు తర్వాత క్రాష్ అయ్యేవి.
మూడు ప్రశ్నలను వేరుగా ఉంచండి
ఈ రంగంలో చాలా గందరగోళం మూడు వేర్వేరు తనిఖీలను ఒకటిగా చూడటం వల్ల వస్తుంది. అవి వేర్వేరు API లను ఉపయోగిస్తాయి, ఒకటి నిజమైనప్పుడు మిగతావి తప్పు కావచ్చు.
| Question | How you answer it | What a yes means |
|---|---|---|
| Did the user grant VPN consent to my app? | VpnService.prepare() returns null | Consent exists; the tunnel may still be down |
| Is the device sending default traffic through a VPN? | TRANSPORT_VPN on the active network | Something is tunneling, not necessarily your app |
| Did this request arrive through the VPN? | Source address seen by the server | Proof for that connection, nothing wider |
మూడవ వరుస ప్రజలు క్లయింట్లో సమాధానం ఇవ్వడానికి ప్రయత్నించేది, అక్కడ సమాధానం ఇవ్వలేము. VPN క్లయింట్లకు వారి స్వంత చిరునామా పూల్ ఇవ్వండి మరియు సర్వర్లో మూల చిరునామాను చదవండి; సెషన్ మధ్యలో వినియోగదారు సొరంగాన్ని మార్చినా మిగిలే ఏకైక రుజువు అదే.
తప్పుడు పాజిటివ్లను తొలగించే ధృవీకరణ క్రమం
ఇంకా చలామణిలో ఉన్న పాత నమూనా కోడ్ getNetworkInfo(ConnectivityManager.TYPE_VPN) ను పిలుస్తుంది. ఆ పిలుపు పాతబడింది, అనేక విడుదలల్లో VPN కనెక్ట్ అయి ఉన్నప్పటికీ null తిరిగి ఇచ్చింది, అందుకే కాపీ చేసిన స్నిప్పెట్లు పని చేసే పరికరంలో పాడైనట్లు కనిపిస్తాయి. సామర్థ్య తనిఖీలు ఆ ఉచ్చును నివారించి Android 5.0 నుండి అదే విధంగా ప్రవర్తిస్తాయి. ఇంకా దాన్ని పిలిచే కోడ్బేస్ను నిర్వహిస్తుంటే, ఫాల్బ్యాక్లో చుట్టడం బదులు పిలుపునే మార్చండి, ఎందుకంటే తప్పుడు సమాధానాన్ని మొదట సృష్టించింది ఆ ఫాల్బ్యాక్.
ఒక షార్ట్కట్ హెచ్చరికకు అర్హం. బాహ్య సేవ నివేదించే పబ్లిక్ చిరునామాను VPN నిష్క్రమణ చిరునామాతో పోల్చడం మార్గం గురించి ఏదో రుజువు చేస్తుంది, కానీ ప్రతి తనిఖీకి మూడవ పక్ష అభ్యర్థనను జోడిస్తుంది, ఆ సేవ నడుస్తూ ఉండటంపై ఆధారపడుతుంది, మరియు కాష్ లేదా బ్లాక్ చేయబడవచ్చు. దాన్ని చేతితో చేసే నిర్ధారణగా ఉంచండి, యాప్ లోపల స్థితి తనిఖీగా ఎప్పుడూ ఉంచవద్దు.
ఈ క్రమంలో తనిఖీలను నడిపి, వినియోగదారు నివేదికతో విభేదించే మొదటి దానిలో ఆపండి: shell లో రవాణా జాబితా, యాక్టివ్ నెట్వర్క్ సామర్థ్యాలు, సొరంగాన్ని ఆన్-ఆఫ్ చేస్తున్నప్పుడు callback సంఘటనలు, తర్వాత సర్వర్ వైపు మూల చిరునామా. నాలుగూ సరిపోయినా యాప్ ఇంకా తప్పుగా ప్రవర్తిస్తే, బగ్ Android నెట్వర్క్ దృష్టిలో కాదు, మీ స్వంత స్థితి యంత్రంలో ఉంది.