Android WebView: ужывіце пераазначэнне проксі да навігацыі

Навігацыя, якая залежыць ад пераазначэння проксі WebView, павінна пачынацца пасля таго, як адпрацуе слухач завяршэння пераазначэння. Калі ўсталяваць яго і адразу загрузіць старонку, аперацыя будзе спаборнічаць з асінхронным абнаўленнем.

1. Праверце WebViewFeature.isFeatureSupported(WebViewFeature.PROXY_OVERRIDE). Падтрымка залежыць ад рэалізацыі WebView і бібліятэкі AndroidX WebKit, а таксама ад узроўню API Android. Вызначце, што адбываецца, калі яго няма; маўклівы прамы пераход можа звесці функцыю на нішто.
2. Пабудуйце патрэбны ProxyConfig з яго дакументаванымі правіламі проксі, сінтаксісам канчатковай кропкі і паводзінамі абыходу. Для дазволенай навігацыі па публічных сайтах выберыце кандыдата са спісу бясплатных проксі, пратакол якога адпавядае правілу, якое падтрымлівае гэтая рэалізацыя WebView. PAC URL, SOCKS URI і голы хост — гэта розныя ўводы.
3. Выклічце ProxyController.setProxyOverride() з гэтай канфігурацыяй, выканаўцам і слухачом завяршэння. Пачынайце залежную навігацыю з шляху завяршэння.
4. Калі часовае пераазначэнне скончыцца, ачысціце яго праз clearProxyOverride() і таксама апрацуйце яго асінхроннае завяршэнне.

Дайце гэтаму жыццёваму цыклу аднаго ўладальніка. Налада дзейнічае для ўсіх WebView у працэсе праграмы; паўторнае яе змяненне не можа даць двум адначасовым прадстаўленням незалежныя выхады. Іншыя працэсы і бібліятэкі HTTP маюць свае маршруты.

Гэты падтрыманы інтэрфейс пазбягае залежнасці ад прыватных слухачоў змены проксі, якія адрозніваюцца паміж выпускамі Android. Ён выбірае маршрутызацыю; уліковыя даныя проксі і давер да сертыфікатаў па-ранейшаму выкарыстоўваюць свае падтрыманыя механізмы. Збой аўтэнтыфікацыі або TLS пасля выбару трэба дыягнаставаць на гэтым этапе.