Le Google Pixel 2 prend en charge le déchargement de connexion, également appelé partage de connexion accéléré par le matériel, ce qui contribue à améliorer la durée de vie de la batterie tout en connectant votre Internet.
Il y a beaucoup de choses à découvrir sur les nouveaux Google Pixel 2/Pixel 2 XL. Google s'en est pris rapidement au monde de la technologie en révélant soudainement que les nouveaux smartphones étaient équipés d'un processeur d'image personnalisé intégré appelé le Noyau visuel Pixel, même si cela a pas encore activé. Nous avons trouvé une autre chose intéressante sur le Pixel 2, même si nous ne sommes pas sûrs à 100 % de toutes les implications de cette nouvelle fonctionnalité. La fonctionnalité, appelée partage de connexion accéléré par le matériel, améliorera probablement la durée de vie de la batterie pendant le partage de connexion de données mobiles en déchargeant toute la logique liée au transfert de paquets et à d'autres tâches liées au partage de connexion sur le matériel.
Les propriétaires existants du Google Pixel 2 ou du Pixel 2 XL peuvent trouver cette fonctionnalité dans les options du développeur dans la catégorie Réseau. Il est activé par défaut, il est donc probablement déjà fonctionnel sur ces appareils. Dans le projet Android Open Source (AOSP), nous pouvons voir plusieurs commits liés à la fonctionnalité sous le "déchargement d'attache" étiqueter. Nous pouvons voir qu'il y a une logique pour transmettre la limite de données de votre smartphone au code de déchargement afin que votre limite de données n'est pas dépassé.
Plus important encore, nous pouvons voir une implémentation pour le "déchargement d'attache HAL" Les couches d'abstraction matérielle (HAL) permettent au système Android de s'interfacer avec la puce WiFi du SoC qui gérera le partage de connexion accéléré par le matériel. Ce HAL est utilisé par Android pour décharger tout le fardeau du transfert de paquets d'Android sur le matériel qui lui est dédié.
Le résultat final est que les ressources système dédiées au partage de données mobiles seront libérées à d’autres fins. Moins le processeur de l'appareil est responsable des opérations liées au partage de connexion, plus l'énergie est conservée. Cela peut être particulièrement utile lorsque l'appareil entre en veille, car actuellement, le partage de connexion basé sur un logiciel sur Android nécessite que le processeur reste éveillé avec un wakelock. En déchargeant la responsabilité du partage de connexion sur le matériel, le processeur pourra peut-être véritablement entrer en état de veille :améliorer la durée de vie de la batterie plus vous êtes connecté longtemps.
Alors, quels appareils prennent en charge le partage de connexion accéléré par le matériel? Eh bien, nous n'avons trouvé la bascule que sur le Google Pixel 2/Pixel 2 XL jusqu'à présent, nous supposons donc que seuls ces appareils la prennent en charge. Selon les engagements de déchargement de connexion HAL, il semble que Google teste la prise en charge sur le Google Nexus 5X (bullhead). De plus, selon quelques commentaires de Googleurs, il semble que le déchargement de connexion HAL soit plutôt neutre en termes de fournisseur :
Dans un autre commentaire, un Googleur mentionne comment les appareils peuvent mélanger et assortir les chipsets WiFi et décharger les HAL, mais cela l'API qu'ils ont créée est toujours conçue pour fonctionner afin d'optimiser la durée de vie de la batterie de votre appareil tout en attachement.Bien que ce HAL présente quelques bizarreries pour la configuration de Qualcomm, la grande majorité d'entre elles sont neutres en matière de fournisseur. Tout fournisseur disposant d'un SoC suffisamment performant pourrait prendre en charge le déchargement du matériel de partage de connexion avec cela, en théorie (il pourrait ignorer le transfert de fd supplémentaire lors de la configuration, qui sait).
Tout en haut, nous définissons que cette API renverra une configuration statique. En fonction de l'implémentation du fournisseur/matériel, ces fonctionnalités peuvent changer. Par ex. un appareil peut bénéficier du wifi du fournisseur A et décharger HAL du fournisseur B. alors qu'un autre appareil peut avoir un chipset Wifi du fournisseur B et décharger HAL du fournisseur B. Dans ce cas, les capacités de déchargement peuvent être différentes. Même avec des capacités limitées, le framework/client peut vouloir profiter du déchargement matériel pour un ensemble limité. Par conséquent, l'API est conçue pour tirer le meilleur parti du matériel, étant donné qu'il peut y avoir des variations d'une implémentation à l'autre.
Si vous possédez un Google Pixel 2/Pixel 2 XL et que vous souhaitez connaître l'état du partage de connexion accéléré matériellement, vous pouvez saisir ce qui suit: Commande shell ADB et recherchez les chaînes liées au « déchargement matériel: »
adb shell dumpsys connectivity tetheringNous devrons faire des tests pour voir dans quelle mesure le partage de connexion accéléré par le matériel est efficace pour améliorer la durée de vie de la batterie pendant le partage de connexion. Le partage de connexion entraînait également une baisse considérable des performances, mais les améliorations massives de la vitesse du processeur et les optimisations dans Android ont largement résolu ce problème. Ainsi, nous ne nous attendons pas à ce que le déchargement de la logique de partage de connexion via le HAL de déchargement vers le chipset WiFi entraîne une amélioration notable des performances.