Android tətbiqi adları VPN xaricində həll edir: bağlama yoxlama siyahısı

Android tətbiqi daxili adı həll edə bilmir, halbuki VPN müştərisinin öz brauzeri həmin adı açır və eyni build başqa telefonda işləyir. Dəyişən URL deyil. Dəyişən tətbiq prosesinin həll üçün hansı şəbəkədən istifadə etməsinə icazə verildiyidir və Android aktiv VPN-in sizin soketlərinizin istifadə etdiyi şəbəkə olduğuna zəmanət vermir. Bu yoxlamaları ardıcıllıqla aparın və həlledici mənzərəsi fərziyyənizlə uyğun gəlmədikdə dayanın.

Addım 1: Tətbiqin hansı şəbəkədə olduğunu sübut edin

Status panelini deyil, tətbiqin öz görünüşünü oxuyun. ConnectivityManager üzərindən aktiv şəbəkəni, onun LinkProperties , DNS server siyahısını və şəxsi DNS parametrini götürün. Siyahıda VPN-in həlledicisi varsa, tətbiqin ora gedən yolu var; Wi-Fi həlledicisi varsa, tunel həmin proses üçün standart şəbəkə deyil.

VPN ikonası yalnız tunelin mövcud olduğunu deyir. Tətbiq prosesinin ona bağlandığını demir və Android ad həllini həmişə aktiv görünən şəbəkədən keçirmir. Başqa cihaza yönləndirən yerli VPN tətbiqləri, internetsiz Wi-Fi şəbəkələri və istehsalçı build-ləri tətbiqi tunelin serverləri yerinə standart həllediciyə müraciət etməyə qoya bilər.

Addım 2: VPN nəqliyyatını tələb edin və prosesi bağlayın

Tətbiq tunelin həlledicisindən istifadə etməlidirsə, VPN nəqliyyatı olan şəbəkə tələb edin və prosesi callback-də bağlayın ki, kod şəbəkənin nə vaxt görünəcəyini təxmin etməsin:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

Çağırış proses miqyasında standart şəbəkəni dəyişir, ona görə sonradan yaradılan hər soket ondan istifadə edir. Artıq mövcud olan soketlər yaradıldıqları şəbəkəni saxlayır, buna görə bağlamadan əvvəl açılmış əlaqə hovuzu köhnə yol ilə həll etməyə davam edə bilər. Qaytarılan dəyər boolean-dır və yanlış nəticə bağlamanın baş vermədiyini bildirir; qısa fasilədən sonra yenidən cəhd edin və iki cəhdi də qeyd edin.

Addım 3: Bağlamanı yalnız lazım olana məhdudlaşdırın

Proses miqyasında bağlama kobuddur. Telemetriya, yeniləmə yoxlamaları və üçüncü tərəf SDK-ları da tunelə keçir və tunelin interneti yoxdursa, uğursuz olmağa başlayırlar. Tək sorğu üçün şəbəkənin soket fabrikindən istifadə edin və qalan hər şey üçün cihaz standartını saxlayın. Bir modeli qəsdən seçin: hər əlaqə üçün dar bağlama, ya da VPN yox olduqda açıq bağlama açma ilə proses bağlaması.

İki həlledici xüsusiyyəti bağlamanı heç bir xəta olmadan məğlub edə bilər. Ciddi rejimdə şəxsi DNS sorğuları şəbəkə həlledicisi yerinə adlanmış DoT serverinə göndərir və öz DNS-over-HTTPS müştərisini gətirən tətbiq sistem həlledicisini tamamilə yan keçir. Bağlamanın uğursuz olduğu qənaətinə gəlməzdən əvvəl ikisini də yoxlayın. VPN-in DNS serverinə heç çatmayan sorğu heç bir tunel tərəfindəki jurnalda görünməyəcək.

Addım 4: CONNECTED məhdudiyyətinə güvənməyin

WorkManager-in NetworkType.CONNECTED şəbəkənin qoşulduğunu bildirir və VPN nəqliyyatı altındakı Wi-Fi və ya mobil əlaqə yox olsa belə onu ödəyir. İş çalışır, hər sorğu uğursuz olur və təkrar cəhd siyasəti bunu planlaşdırma xətası kimi görünən fırtınaya çevirir. Tunel bir şəbəkədir; məhdudiyyət heç vaxt internet yoxlaması deyildi.

İşin həqiqətən ehtiyac duyduğu qabiliyyəti yoxlayın, məsələn təsdiqlənmiş internet çıxışı, və geri çəkilmə ilə məhdud təkrar cəhd siyasəti saxlayın. İş daxili ad lazımdırsa, işi görməzdən əvvəl həmin adı seçilmiş şəbəkədə həll edin və uğur qazana bilməyəcək sorğunu təkrarlamaq yerinə aydın xəta ilə tez uğursuz olun.

Addım 5: Sübutu qeyd edin və diapazonu yenidən yoxlayın

Seçilmiş şəbəkənin nəqliyyat növlərini, LinkProperties ünvanından DNS serverlərini, bağlamanın true qaytarıb-qaytarmadığını və ilk sorğunun dəqiq uğursuzluğunu qeyd edin. Sonra eyni bağlama altında daxili və ictimai ad işə salın. Bu cüt tətbiqin tunel həlledicisindən istifadə etdiyini, yoxsa səssizcə cihaz standartına qayıtdığını göstərir və istifadəçinin hiss etdiyi fərq budur.

Dəstəklədiyiniz ən köhnə Android versiyasında və bir cari buraxılışda təkrarlayın. Standart yolu düzgün göstərən həlledici davranışı cihazların və versiyaların fərqləndiyi yerdir və yalnız ən yeni test cihazında keçən build göndərdiyiniz diapazon üçün təsdiqlənməyib. adb shell dumpsys connectivitynasazlığı təkrarlayarkən cihazın hansı şəbəkələri və qabiliyyətləri bildirdiyini təsdiqləməyin sürətli yoludur.