ADB-ն և Android-ի էմուլյատորը ձախողվում են VPN-ի հետևում. երեք ուղիներ
ADB-ի հայտնաբերումը, էմուլյատորի վիրտուալ ցանցային քարտը և հոսթի լուծիչը VPN-ի հետևում առանձին են ձախողվում։ Ստուգեք յուրաքանչյուր ուղին հերթով, նախքան թունելին մեղադրելը։
Միանում եք գրասենյակի VPN-ին, և Android Studio-ն կորցնում է աշխատող էմուլյատորը, adb start-server-ը կախվում է, իսկ Wi-Fi-ով ֆիզիկական հեռախոսը դուրս է ընկնում սարքերի ցանկից։ Թվում է՝ մեկ թունելը արգելափակում է մեկ ապրանք։ Իրականում երեք առանձին ուղիներ ձախողվում են երեք ձևով՝ adb-ի սարքերի հայտնաբերումը, էմուլյատորի վիրտուալ ցանցը և հոսթի լուծիչը։ Թունելը սովորաբար տիրապետում է միայն վերջինին, և հաճախ միայն դրա մի մասին։
Երեք սոքեթ, երեք սեփականատեր
adb սերվերը լսում է հոսթի 5037 պորտին և խոսում սարքերի հետ USB-ով կամ TCP-ով, ցանցային հայտնաբերման համար օգտագործում է mDNS։ Էմուլյատորն աշխատում է իր իսկ վիրտուալ երթուղիչի հետևում. հյուրը 10.0.2.15-ն է, դարպասը՝ 10.0.2.2-ը, DNS սերվերը՝ 10.0.2.3-ը, և էմուլյատորի գործընթացը այդ ամենը թարգմանում է հոսթի սոքեթների։ Հոսթի լուծիչն այն տեղն է, որտեղ VPN հաճախորդը տեղադրում է DNS-ը և որոնման դոմենները։
Այդ բաժանումը բացատրում է, թե ինչու ուղղումը աշխատում է մեկ գործիքի համար և չի աշխատում մյուսի համար։ Հոսթի լուծիչը փոխող հաճախորդը աշխատող էմուլյատորի գործընթացը թողնում է մեկնարկին կարդացած լուծիչի վիճակով։ multicast-ը զտող հաճախորդը կոտրում է հայտնաբերումը՝ առանց DNS-ին դիպչելու։ Վիրտուալ ադապտերները զտող հաճախորդը մերժում է էմուլյատորը, մինչ հոսթի զննարկիչը շարունակում է աշխատել։ Յուրաքանչյուր ախտանիշ ունի այլ պատճառ, ուստի նախ բացահայտեք ձախողվող ուղին, ապա փոխեք որևէ կարգավորում։
Սկսեք նրանից, ինչ adb-ն տեսնում է
Գործարկեք adb devices նախքան VPN-ին դիպչելը։ Դատարկ ցանկը տրանսպորտի խնդիր է, ոչ երթուղավորման, և ոչ մի թունելի կարգավորում չի ուղղի սարք, որը սերվերը երբեք չի թվարկել։ Վերսկսեք սերվերը մաքուր կերպով. նախ adb kill-server ապա adb start-server, և կարդացեք ելքը՝ տեսնելու, թե որ պորտն է զբաղեցրել։ Եթե ինքը մեկնարկը կախվում է, multicast-ը զտող ցանցում mDNS հայտնաբերումը սովորական կասկածյալն է. փաստաթղթավորված լուծումը սերվերը հայտնաբերումն անջատած գործարկելն է.
ADB_MDNS_OPENSCREEN=0 adb start-server
adb devicesՖիզիկական սարքի համար USB-ն ամենակարճ ուղին է։ Եթե TCP է պետք, սարքը դրեք լսելու ռեժիմի adb tcpip 5555 -ով և միացեք սարքի հասցեին ու պորտին՝ adb connect 192.0.2.10:5555։ 5037 պորտը հոսթի սերվերի պորտն է, ոչ այն պորտը, որին լսում է սարքը։
Ստուգեք էմուլյատորը ներսից
Էմուլյատորը DNS-ին պատասխանում է 10.0.2.3-ից, և այդ լուծիչը սնվում է հոսթի գործընթացից։ Երբ VPN հաճախորդը փոխում է հոսթի լուծիչը, էմուլյատորը կարող է ժառանգել այն. երբ հաճախորդը զտում է էմուլյատորի գործընթացը կամ մեկնարկից հետո փոխվում է հոսթի ադապտերների ցանկը, չի կարող։ Առանձնացրեք երկուսը թվային թիրախով և անունով նույն shell-ից։ adb shell ping -c 2 10.0.2.2 ապացուցում է, որ վիրտուալ ցանցը հասնում է հոսթի կողմը։ Դրանից հետո անվան որոնումը ցույց է տալիս՝ լուծումը հատել է սահմանը։
Ապա գործարկեք նույն անվան որոնումը հոսթում։ Հոսթը լուծում է, էմուլյատորը՝ ոչ, նշանակում է՝ խզումը հոսթի լուծիչի և էմուլյատորի վիրտուալ ցանցի միջև է, ոչ թունելում։ Երկուսն էլ ձախողվում են, նշանակում է՝ պետք է նայել հոսթի լուծիչը։ VPN-ին միանալուց հետո էմուլյատորը վերսկսելը արժե մեկ փորձ, քանի որ որոշ հաճախորդներ տեղադրում են լուծիչի վիճակ, որը աշխատող էմուլյատորի գործընթացը չի ընկալում։
Ստուգեք հոսթի լուծիչը և հաճախորդի զտիչները
Լրիվ թունելի հաճախորդը հոսթի լուծիչը փոխարինում է իրով, իսկ split-DNS հաճախորդը ավելացնում է որոնման դոմեններ և պայմանական փոխանցիչներ։ Ներքին անունները հաճախ կախված են հենց այդ split-DNS կարգավորումից, ուստի տեսեք՝ ինչ է օգտագործում հոսթը միացած ժամանակ. լուծիչի հասցեն, որոնման դոմենը և արդյոք ներքին գոտին ուղղորդվում է կորպորատիվ DNS-ին։ Լուծիչը, որը պատասխանում է հանրային, բայց ոչ ներքին անուններին, քաղաքականության հարց է, ոչ կոտրված թունել։
Որոշ կորպորատիվ հաճախորդներ արգելափակում են նաև վիրտուալ ադապտերներից եկող տրաֆիկը։ Զտիչ դրայվերի համար էմուլյատորը վիրտուալ ադապտերի տեսք ունի, ուստի հոսթը կարող է անթերի աշխատել, մինչ քաղաքականությունը մերժում է էմուլյատորին։ Այդ քաղաքականությունը տեսանելի չէ աշխատանքային կայանից, և պրոքսի կարգավորումների գուշակությունը չի բացահայտի այն։ Եթե հոսթը լուծում է, իսկ էմուլյատորը արգելափակված է անկախ լուծիչի կարգավորումներից, ճիշտ էսկալացիան հաճախորդի քաղաքականությանը տիրապետող թիմինն է։
Ստուգումների հերթականությունը և ինչ է նշանակում յուրաքանչյուր արդյունք
Աշխատեք վերևից ներքև և կանգ առեք առաջին ձախողված տողում։ Յուրաքանչյուր արդյունք մատնանշում է այլ սեփականատիրոջ, և ոչ մեկը չի շտկվում Android Studio-ն վերատեղադրելով։
| Result | Likely owner | Next check |
|---|---|---|
| adb devices is empty with USB attached | USB, driver or adb server | cable, authorization prompt, adb kill-server |
| adb start-server hangs | mDNS discovery | ADB_MDNS_OPENSCREEN=0 |
| Emulator reaches 10.0.2.2, names fail | Host resolver to emulator boundary | host lookup of the same name |
| Host resolves, emulator still fails | Emulator process or client filter | restart emulator, ask IT about virtual adapters |
| Both fail for internal names only | Split DNS or search domain | resolver and zone configuration |
Միայն վերջին երկու տողերն են VPN հարցեր սովորական իմաստով, և միայն վերջինն է DNS բովանդակության մասին։ adb-ի փաստաթղթերը ընդգրկում են սերվերի պորտը և այստեղ նշված միջավայրի փոփոխականները, ինչը բավական է տրանսպորտի կողմը ազնիվ պահելու համար, մինչ ստուգում եք մնացածը։