Android-APN-legitimoj kaj Network ProxyInfo servas malsamajn celojn
Legu la retan prokuran agordon per la subtenataj interfacoj de Android kaj tenu la alirpermesilojn de la operatoro aparte de HTTP-prokura konto.
Android-a aplikaĵo povas bezoni la nunan prokuran adreson sen posedi la konektajn agordojn. Komencu per la reta prokura interfaco anstataŭ serĉi datum-bazan kolumnon nomatan user aŭ password.
La telefonia APN-agordo priskribas la aliron de la operatoro. Ĝiaj kontaj kampoj apartenas al tiu agordo. Ili ne estas ĝenerala konservejo de legitimoj por la HTTP-prokuro elektita en Wi-Fi, administrata reto aŭ privata konekto de aplikaĵo.
| Bezonata informo | Koncerna agordo |
|---|---|
| Datumalira konto de la operatoro | APN-agordoj, kun la alirlimigoj de la platformo |
| Nuna reta HTTP-prokuro | ConnectivityManager kaj ProxyInfo |
| Saluto postulata de elektita prokuro | La klient-subtenata aŭtentiga fluo kaj aprobita kontfonto |
Sur subtenata Android-versio, ConnectivityManager.getDefaultProxy() redonas la aplikeblan prokuran informon. La rezulto povas foresti. ProxyInfo povas priskribi rektan finpunkton aŭ PAC-agordon, do inspektu ĝian formon antaŭ ol trakti ĉiun rezulton kiel paron de gastiganto kaj pordo.
ProxyInfo ne elmetas universalan paron de uzantnomo kaj pasvorto. Se la elektita servo postulas aŭtentigon, akiru la celatan konton per la aplikaĵ-subtenata legitim-aranĝo. Prokura defio kaj operatora saluto povas uzi tute malsamajn identecojn.
Tio ankaŭ apartigas malkovron de uzo. Indiĝena ingo aŭ SDK kun propra transporto ne iĝas prokurkonscia nur ĉar la aplikaĵo povas legi ProxyInfo. Donu la elektitan vojon al kliento, kiu subtenas ĝian protokolon kaj aŭtentigan metodon.
Pli malnovaj ekzemploj, kiuj pridemandas telefonian enhavprovizanton, priskribas apartajn Android-eldonojn kaj permesojn. Ili estas utila historia kunteksto, sed ili ne povas igi APN-konton la mankanta pasvorto por ne rilata prokuro.