Le champ d'hôte proxy de sdkmanager n'est pas un champ de connexion
Les options documentées d'hôte et de port identifient un point de terminaison. Elles ne transforment pas une chaîne contenant un nom d'utilisateur en un échange d'authentification pris en charge.
--proxy_host attend un nom d'hôte ou une adresse de proxy. Y placer username:password@host n'équivaut pas à fournir un nom d'hôte accompagné d'une méthode d'authentification prise en charge.
La référence de sdkmanager documente les options de type de proxy, d'hôte et de port. Vérifiez séparément la prise en charge de l'authentification documentée de l'outil installé. Un indicateur accepté par un autre programme Java n'est pas automatiquement une fonction de SDK Manager.
En particulier, définir des propriétés arbitraires nommées http.proxyUser ou http.proxyPassword ne prouve pas que le téléchargeur les lit. Un mécanisme d'authentification doit réellement utiliser le compte et effectuer l'échange requis.
Gardez aussi --no_https hors d'une réparation de connexion. Changer la manière dont un téléchargement est demandé ne fournit pas les identifiants de proxy manquants.
Si le client pris en charge ne peut pas satisfaire l'exigence d'authentification du proxy, utilisez la disposition d'accès compatible approuvée par l'organisation. Gardez le point de terminaison du service, le mécanisme de compte et la politique TLS de téléchargement comme des décisions de configuration distinctes. Une route approuvée non authentifiée vers les téléchargements publics de SDK peut prendre son hôte et son port HTTP dans la liste de proxys HTTP ; elle n'ajoute pas de prise en charge de l'authentification pour le service d'origine.