Article original : How Bluetooth Socket Settings Power Android’s Low Power Island: A Friendly Deep Dive into AOSP’s Hidden Energy Saver

Imaginez la scène : vous êtes assis dans un café avec votre ordinateur portable ouvert, votre téléphone sur la table, votre montre connectée qui vibre toutes les quelques minutes et vos écouteurs Bluetooth diffusant de la musique. De votre point de vue, la vie est paisible. Du point de vue de votre téléphone, il jongle en permanence avec un nombre impressionnant de minuscules paquets Bluetooth.

Chaque fois que votre montre synchronise vos pas, chaque fois que vos écouteurs reçoivent un nouveau flux audio, chaque fois qu'un appareil en arrière-plan se manifeste, le processeur d'application principal de votre téléphone est forcé de se réveiller, d'analyser les données, de décider quoi en faire, puis de se rendormir. Faites cela quelques milliers de fois, et soudain, cette belle batterie de 5000 mAh commence à paraître étrangement petite.

Les ingénieurs d'Android ont observé ce schéma et se sont dit : et si nous ne réveillions pas le gros CPU pour chaque petite interaction Bluetooth ? Et si nous avions un petit cerveau auxiliaire dont le seul rôle serait de gérer le trafic Bluetooth répétitif et ennuyeux pendant que le CPU principal se repose ? C'est précisément là qu'intervient le concept de « Low Power Island », généralement abrégé en LPI.

Dans l'architecture Bluetooth moderne d'Android, particulièrement à partir de la génération AOSP 16, une bonne partie du travail Bluetooth peut être déchargée vers un processeur basse consommation dédié, situé plus près de la radio Bluetooth. Ce petit processeur est intégré au contrôleur Bluetooth ou au SoC et est conçu pour fonctionner de manière très efficace. Il consomme beaucoup moins d'énergie que le CPU principal et peut rester actif sans vider votre batterie comme le ferait un processeur d'application complet. Le rôle d'Android est de décider quel trafic peut résider sur cette « île » et quel trafic nécessite encore le CPU principal.

Mais comment Android prend-il cette décision en pratique ? C'est ici que les sockets Bluetooth et un élément appelé BluetoothSocketSettings entrent en scène.

Dans une application classique, lorsque vous ouvrez un BluetoothSocket, vous avez l'impression d'ouvrir simplement un tuyau pour envoyer et recevoir des octets. Sous le capot, cependant, le Framework pose une question beaucoup plus profonde : ce tuyau doit-il passer par la grande autoroute qui réveille le CPU principal, ou peut-il être connecté directement au réseau routier privé de la Low Power Island ?

Dans la dernière pile Bluetooth d'AOSP, la réponse à cette question est exprimée via un petit objet de configuration : BluetoothSocketSettings. Cette classe permet au code de niveau système de décrire comment un socket doit se comporter. Elle peut spécifier si les données doivent rester sur le chemin normal de l'hôte ou être déchargées (offload) vers un chemin de données matériel qui aboutit sur le processeur basse consommation.

À l'intérieur, on trouve des champs comme DATA_PATH_NO_OFFLOAD et DATA_PATH_HARDWARE_OFFLOAD, ainsi que des informations supplémentaires comme hubId, endpointId, et requestedMaximumPacketSize qui aident le contrôleur à comprendre comment router les paquets dans le monde de la LPI.

De l'extérieur, vous avez toujours l'impression de manipuler un BluetoothSocket normal. Pourtant, à l'intérieur du Framework Bluetooth, ce socket est désormais marqué avec des métadonnées supplémentaires qui indiquent discrètement à la pile Bluetooth : celui-ci est spécial, envoyez-le sur l'île.

La pile hôte communique ensuite avec une nouvelle couche de code dans le système Bluetooth appelée le gestionnaire d'offload LPP et une HAL (Hardware Abstraction Layer) spécifique au socket, afin que le processeur basse consommation puisse être informé de l'ouverture ou de la fermeture d'un socket et puisse prendre la responsabilité de la gestion des données.

Pour reprendre l'analogie du café, auparavant, chaque client Bluetooth criait sa commande directement au barista principal. Avec la Low Power Island et BluetoothSocketSettings, Android peut dire : « ces commandes d'expresso classiques peuvent passer par le barista junior au comptoir latéral. Seules les boissons personnalisées bizarres vont encore au barista principal ». L'expérience Bluetooth reste la même pour l'utilisateur, mais il y a beaucoup moins de chaos et d'énergie gaspillée derrière le comptoir.

Dans cet article, nous allons passer de cette vue d'ensemble aux API Android réelles. Nous verrons comment BluetoothSocketSettings est défini dans le Framework, comment demander l'offload matériel, et ce que signifient réellement ces champs aux noms complexes comme hubId et endpointId en langage clair.

Table des matières

  1. L'anatomie de BluetoothSocketSettings

  2. Au cœur de la HAL : comment l'offload Bluetooth fonctionne réellement

  3. Quand le CPU dort mais pas le Bluetooth : la gestion de l'énergie en action

  4. Comment les développeurs peuvent exploiter BluetoothSocketSettings

  5. Le grand final : l'élégance d'une mise en veille intelligente

L'anatomie de BluetoothSocketSettings

Jusqu'à présent, nous avons parlé de BluetoothSocketSettings comme d'un ticket magique qui envoie vos paquets vers une île ensoleillée à basse consommation quelque part dans votre téléphone. Regardons maintenant à quoi ressemble réellement ce ticket dans le code.

Si vous ouvrez l'arborescence de l'Android Open Source Project et naviguez vers la couche Framework, vous trouverez une définition de classe cachée sous frameworks/base/core/java/android/bluetooth/BluetoothSocketSettings.java. À première vue, elle semble petite, presque trop simple pour quelque chose qui économise autant de batterie. Mais cette petite classe contient les instructions secrètes qui indiquent à la pile Bluetooth où les données de votre socket doivent circuler.

Voici à quoi ressemble une version simplifiée :

public final class BluetoothSocketSettings implements Parcelable {
    public static final int DATA_PATH_NO_OFFLOAD = 0;
    public static final int DATA_PATH_HARDWARE_OFFLOAD = 1;

    private int mDataPath;
    private int mHubId;
    private int mEndpointId;
    private int mRequestedMaxPacketSize;

    public BluetoothSocketSettings(int dataPath, int hubId, int endpointId,
                                   int requestedMaxPacketSize) {
        mDataPath = dataPath;
        mHubId = hubId;
        mEndpointId = endpointId;
        mRequestedMaxPacketSize = requestedMaxPacketSize;
    }

    public int getDataPath() { return mDataPath; }
    public int getHubId() { return mHubId; }
    public int getEndpointId() { return mEndpointId; }
    public int getRequestedMaxPacketSize() { return mRequestedMaxPacketSize; }
}

Lorsqu'un nouveau socket est créé dans le Bluetooth Android, le système ou un service privilégié peut transmettre l'un de ces objets de paramètres à la pile. La ligne clé est DATA_PATH_HARDWARE_OFFLOAD. C'est l'interrupteur qui dit au système Bluetooth : hé, essaie de garder ce trafic sur le microprocesseur du contrôleur plutôt que de réveiller le CPU principal.

hubId et endpointId sont comme des adresses sur l'île. Ils indiquent au firmware quel port logique ou quelle file d'attente utiliser pour ce socket particulier. Le requestedMaxPacketSize aide à ajuster l'allocation de la mémoire tampon, afin de trouver l'équilibre entre débit et efficacité énergétique.

À ce stade, vous vous demandez peut-être comment ce minuscule objet Java parvient réellement jusqu'au matériel. La réponse se trouve dans la HAL (Hardware Abstraction Layer). Lorsque vous appelez quelque chose comme BluetoothSocket.connect(), cela finit par descendre via du code natif dans des fichiers tels que btif_sock.cc et btif_core.cc. Là, vous verrez des traces comme :

bt_status_t status = BTA_SockConnect(type, addr, channel, flags);
if (settings.data_path == DATA_PATH_HARDWARE_OFFLOAD) {
    BTIF_TRACE_DEBUG("Configuring socket for hardware offload path");
    BTA_SockSetOffloadParams(settings.hub_id, settings.endpoint_id);
}

Ce fragment peut sembler simple, mais il représente un changement majeur de responsabilité. Au lieu d'envoyer chaque paquet à la pile hôte, le contrôleur Bluetooth peut désormais revendiquer la propriété du chemin de données. Le firmware Bluetooth à l'intérieur du SoC prend alors le relais, gérant les retransmissions de paquets, les accusés de réception et le contrôle de flux sans réveiller constamment le CPU principal.

Si vous surveillez le journal du noyau (kernel log) de votre appareil pendant une telle connexion, vous pourriez même repérer quelque chose comme :

bt_vendor: enabling LPI offload for handle 0x0041
bt_controller: lpi path active, cpu wakelocks released

Cette ligne de log est la confirmation discrète que le chemin de données a migré avec succès vers la Low Power Island.

En termes humains, le téléphone vient de décider que cette conversation Bluetooth est suffisamment prévisible pour être gérée par le mini-processeur, et il a poliment dit au gros CPU : « Tu peux faire une sieste maintenant. Je m'en occupe. »

Dans la section suivante, nous suivrons ce voyage un niveau plus bas, directement dans la HAL et la frontière du firmware, pour voir comment ces paramètres de socket se transforment en un routage de données réel à basse consommation à l'intérieur de la puce du contrôleur.

Au cœur de la HAL : comment l'offload Bluetooth fonctionne réellement

Jusqu'à présent, nous sommes restés principalement dans les couches Java et natives d'Android, l'appartement confortable où vivent les Frameworks et les services système. Mais en dessous se trouve un sous-sol rempli de machines ingénieuses : la Hardware Abstraction Layer, ou HAL. C'est là qu'Android cesse de parler en « objets » et commence à parler en opcodes et en buffers ; c'est le pont entre le logiciel et le silicium.

Lorsque le flag BluetoothSocketSettings indique au système « veuillez utiliser l'offload matériel », cette requête ne se téléporte pas magiquement vers la puce. Elle descend étape par étape la pile Bluetooth, traversant le JNI (Java Native Interface) vers le C++, puis vers la HAL, qui est définie dans hardware/interfaces/bluetooth/.

À partir d'Android 14 et surtout dans AOSP 16, la HAL est devenue plus intelligente : elle comprend désormais les capacités LPI et peut y diriger certains trafics de socket.

Jetons un coup d'œil à une fonction HAL simplifiée. Ce n'est pas un fragment fictif. C'est proche de ce que vous pourriez trouver dans bluetooth_audio_hw.cc ou bluetooth_socket_hal.cc :

Return<void> BluetoothHci::createSocketChannel(
        const hidl_string& device, const BluetoothSocketSettings& settings,
        createSocketChannel_cb _hidl_cb) {
    int fd = -1;
    if (settings.data_path == DATA_PATH_HARDWARE_OFFLOAD) {
        ALOGI("LPI offload requested for socket on hub %d endpoint %d",
              settings.hub_id, settings.endpoint_id);
        fd = controller->allocateLpiChannel(settings.hub_id, settings.endpoint_id);
    } else {
        fd = controller->allocateHostChannel();
    }
    _hidl_cb(Status::SUCCESS, fd);
    return void();
}

En clair, cette méthode est comme l'agent de circulation au carrefour Bluetooth. Elle examine vos paramètres de socket et décide sur quelle route envoyer vos données. Si DATA_PATH_HARDWARE_OFFLOAD est défini, le chemin de données est câblé vers le MCU interne du contrôleur au lieu du tampon habituel côté hôte.

L'appel à controller->allocateLpiChannel() est le moment où la HAL dit : « D'accord la puce, s'il te plaît, crée une file d'attente qui réside entièrement dans ton processeur basse consommation. » Ce microcontrôleur est physiquement plus proche de la radio Bluetooth. Il peut gérer les accusés de réception, les petites rafales de données et même certains timings de protocole par lui-même, des tâches qui nécessiteraient normalement de réveiller le CPU principal.

Une fois ce canal créé, le Framework Android et les applications voient toujours un descripteur de fichier normal, comme si le socket était entièrement local. La magie réside dans le fait que ce descripteur est soutenu par une mémoire gérée par le firmware et des chemins DMA plutôt que par des tampons du noyau Linux.

Si vous deviez attacher un débogueur ou extraire les logs du contrôleur, vous pourriez voir quelque chose comme :

bt_lpi_mcu: channel 0x03 opened for handle 0x0041
bt_hci: diverting ACL packets to LPI path
bt_lpi_mcu: sleeping host processor

Cette troisième ligne, sleeping host processor, est le rêve devenu réalité pour tout ingénieur en efficacité énergétique. Le téléphone éteint littéralement de grandes parties du sous-système CPU tout en maintenant le Bluetooth actif.

C'est aussi là que des constructeurs comme Qualcomm ou Broadcom ajoutent leur touche personnelle. Leurs HAL incluent souvent des hooks supplémentaires pour des temporisateurs de maintien de connexion (« keep-alive »), des intervalles de regroupement (« coalescing ») et des retransmissions pilotées par le firmware. Cela garantit que la connexion reste fluide même si le processeur principal est au repos.

D'un point de vue de haut niveau, le pipeline ressemble maintenant à ceci :

App -> Bluetooth Framework -> JNI -> btif_sock -> HAL -> Controller MCU (LPI)

Chaque couche en comprend juste assez pour passer proprement le relais à la suivante. La HAL agit comme le traducteur, prenant des paramètres de haut niveau et les transformant en commandes de bas niveau que le firmware de la puce peut exécuter.

Au moment où votre montre connectée envoie un paquet ou que vos écouteurs demandent un morceau audio, le CPU principal ne sourcille même pas. Toute la transaction vit et meurt dans le minuscule domaine du contrôleur Bluetooth, sirotant l'énergie plutôt que de l'engloutir.

Quand le CPU dort mais pas le Bluetooth : la gestion de l'énergie en action

Très bien, nous avons vu comment l'offload du socket voyage de la couche application jusqu'à la HAL pour finalement atterrir sur ce minuscule MCU à l'intérieur de la puce Bluetooth. Mais que se passe-t-il ensuite ? Et si le CPU principal de votre téléphone décide de faire une sieste alors qu'un transfert de fichier ou un flux audio est toujours en cours ? Cela ne risque-t-il pas de rompre la connexion Bluetooth ?

C'est ici que la chorégraphie de gestion de l'énergie d'Android entre en jeu. C'est une danse entre trois interprètes : la Power HAL, la pile Bluetooth et le système de wakelock du noyau.

Lorsqu'un socket Bluetooth est configuré pour la Low Power Island, la pile Bluetooth d'Android signale au noyau que cette connexion peut être maintenue sans l'aide du CPU principal. En interne, elle efface ou réduit les temporisateurs de wakelock qui maintiendraient normalement le processeur éveillé pendant le trafic Bluetooth. Dans les logs du noyau, vous pourriez voir ceci :

wakelock: release "bt_wake" (LPI mode active)
bt_controller: firmware handling link supervision locally

Ce message est de l'or pour les ingénieurs système. Il indique que le contrôleur a pris la pleine propriété de la connexion. Le firmware Bluetooth surveille désormais les délais de supervision, gère les retransmissions et maintient les compteurs de chiffrement.

Du point de vue du gestionnaire d'énergie, l'appareil Bluetooth semble « inactif » car aucune interruption n'est générée vers le CPU principal. Pendant ce temps, le MCU du contrôleur échange discrètement des paquets avec vos écouteurs ou votre montre en utilisant son propre domaine d'horloge basse consommation.

Pour coordonner cela, la HAL Bluetooth expose de petits rappels (callbacks) qui informent la Power HAL chaque fois que les niveaux de trafic changent. Vous pourriez trouver un fragment comme celui-ci dans bt_vendor_qcom.cc :

void bt_lpi_activity_update(bool active) {
    if (active)
        power_hint(POWER_HINT_LPI_ACTIVITY, 1);
    else
        power_hint(POWER_HINT_LPI_ACTIVITY, 0);
}

Lorsque active passe à zéro, la Power HAL sait qu'elle peut autoriser des états de veille système plus profonds (comme le suspend-to-RAM), car le Bluetooth maintiendra les choses en vie par lui-même.

La vraie magie est que l'utilisateur ne remarque jamais rien de tout cela. Le téléphone peut sembler « endormi », écran éteint, cœurs du CPU désactivés, et pourtant votre audio Bluetooth continue de jouer, votre montre se synchronise toujours et votre téléphone reste détectable.

C'est presque poétique. Le processeur principal rêve, le contrôleur ronronne doucement, et votre playlist continue de défiler comme si de rien n'était.

Si vous voulez vérifier cela sur un véritable appareil Android, vous pouvez utiliser la commande :

adb shell cat /sys/kernel/debug/wakeup_sources | grep bt

Si vous voyez que le compteur bt_wake reste bas même pendant le streaming, félicitations ! L'offload Low Power Island fait magnifiquement son travail.

Comment les développeurs peuvent exploiter BluetoothSocketSettings

Maintenant que nous avons plongé au cœur de la pile Bluetooth, remontons là où vous et moi vivons réellement : la couche développeur. Vous vous demandez peut-être : « D'accord, toute cette sorcellerie matérielle est cool, mais que puis-je réellement en faire ? »

Voici la partie intéressante : même si la Low Power Island est principalement une fonctionnalité de niveau système, comprendre son fonctionnement peut vous aider à concevoir des applications Bluetooth plus économes en énergie et plus prévisibles.

Au niveau du Framework, vous ne pouvez pas activer ou désactiver directement la LPI depuis votre application. Ces commutateurs se trouvent profondément dans les composants système comme BluetoothService et BluetoothSocketManagerService. Mais chaque fois que vous utilisez un BluetoothSocket ou un BluetoothServerSocket, vos données circulent silencieusement à travers ces couches qui vérifient si l'offload LPI est disponible.

Cela signifie que votre application en bénéficie automatiquement, tant que vous ne faites rien qui force le CPU à rester éveillé inutilement. Par exemple, utiliser des pauses de thread appropriées, éviter les boucles d'attente active et laisser les flux d'E/S Bluetooth d'Android gérer la mise en mémoire tampon vous permettra de rester dans les bonnes grâces de la logique d'offload.

Si vous plongez dans les logs du serveur système d'AOSP lors de la connexion d'un socket Bluetooth, vous pourriez remarquer quelque chose comme ceci :

BluetoothSocketManager: Offload eligible socket detected, enabling LPI mode
Bluetooth HAL: LPI channel activated for fd=42

Cette petite ligne vous indique que votre socket a été discrètement dérouté vers l'île, sans que vous ayez à lever le petit doigt.

Sous le capot, le Framework a créé un objet BluetoothSocketSettings et l'a transmis le long de la chaîne lors de l'ouverture du socket. En pseudo-Java, cela ressemble à ceci :

BluetoothSocketSettings settings =
    new BluetoothSocketSettings(
        BluetoothSocketSettings.DATA_PATH_HARDWARE_OFFLOAD,
        /* hubId */ 1,
        /* endpointId */ 2,
        /* maxPacketSize */ 512);

BluetoothSocket socket = adapter.createSocket(device, settings);
socket.connect();

Bien sûr, cela ne fait pas encore partie du SDK public, mais les applications système ou les Frameworks privilégiés utilisent des appels similaires pour décrire comment le trafic doit être géré.

Alors, pourquoi vous, le développeur, devriez-vous vous en soucier ? Parce que savoir qu'un tel chemin existe signifie que vous pouvez concevoir en l'ayant à l'esprit. Par exemple, vous pouvez :

  • Regrouper (batch) les petites écritures BLE au lieu de les envoyer une par une, permettant au contrôleur de les traiter efficacement dans le tampon d'offload.

  • Éviter les cycles fréquents de connexion/déconnexion, qui forceraient la pile à réveiller le CPU principal de manière répétée.

  • Structurer vos transferts en arrière-plan pour qu'ils s'insèrent proprement dans les limites des tampons basse consommation (pensez à des morceaux plus petits et des intervalles plus longs).

Essentiellement, plus votre schéma de données est prévisible, plus il est probable qu'il reste sur l'île sans réveiller l'hôte.

Si vous construisez un logiciel système, par exemple pour un appareil Android personnalisé ou un produit embarqué, vous pouvez aller encore plus loin. Vous pouvez ajuster le comportement de la HAL, attribuer des ID de hub ou d'endpoint personnalisés, et même régler la taille maximale des paquets que le firmware utilise pour les transferts DMA. Cela vous permet de créer des fonctionnalités Bluetooth, telles que le streaming de télémétrie à basse consommation ou la synchronisation de capteurs portables, qui fonctionnent presque entièrement en mode offload.

À ce stade, votre puce Bluetooth devient un mini-serveur qui continue de travailler pendant que l'OS principal dort, offrant une autonomie de batterie remarquable et des reconnexions instantanées.

Le grand final : l'élégance d'une mise en veille intelligente

Prenons un peu de recul. Nous avons commencé dans un café avec un barista surchargé. Puis nous avons découvert un assistant caché, la Low Power Island, qui fait tourner discrètement le café même lorsque le barista principal s'absente.

Nous avons suivi le chemin d'un humble socket Bluetooth, nous l'avons vu enveloppé dans BluetoothSocketSettings, nous avons voyagé à travers la HAL, pour finalement atterrir sur un processeur miniature à l'intérieur du contrôleur qui s'active pendant que le gros CPU rêve.

Et c'est là toute la beauté de la chose : le mécanisme d'offload Bluetooth d'Android est l'un des exemples les plus élégants d'ingénierie invisible. Il ne s'annonce pas avec une nouvelle API ou une animation sophistiquée. Il fait simplement durer votre batterie plus longtemps, rend votre Bluetooth plus fiable et votre téléphone plus fluide, sans même que vous sachiez qu'il est là.

D'un point de vue technique, le génie réside dans l'équilibre. Le système autorise toujours des sockets complets et une gestion de protocole riche quand vous en avez besoin, mais pour les flux de données courants — audio, télémétrie, notifications ou flux de fréquence cardiaque — il laisse le contrôleur basse consommation prendre le volant. C'est comme si Android avait appris à déléguer.

Chaque fois que votre montre se synchronise alors que l'écran de votre téléphone est éteint, ou que vos écouteurs restent connectés pendant un long vol sans vider votre batterie, vous voyez BluetoothSocketSettings et le Framework Low Power Island à l'œuvre. Ils font partie d'une philosophie plus large dans la conception moderne d'Android : rapprocher l'intelligence du matériel. Plus nous apprenons à nos puces à gérer des tâches autonomes, plus nous pouvons laisser le processeur principal se reposer.

Si vous êtes un développeur ou un ingénieur système, comprendre cette architecture n'est pas seulement académique. Cela peut inspirer la façon dont vous concevez vos propres fonctionnalités. Que vous construisiez une ROM Android personnalisée, que vous optimisiez le firmware pour des wearables ou que vous créiez des appareils IoT avec une puce Bluetooth, la leçon est claire : ne forcez pas votre CPU principal à surveiller chaque paquet. Déchargez quand vous le pouvez, dormez quand vous le devez, et vos appareils vous remercieront avec des heures d'autonomie supplémentaire.

Ainsi, la prochaine fois que vous brancherez vos écouteurs et que vous remarquerez que votre téléphone reste frais et que le pourcentage de votre batterie bouge à peine, souvenez-vous : quelque part, au plus profond, un minuscule MCU Bluetooth fait tout le travail difficile pendant que le CPU principal profite d'une sieste dans son hamac basse consommation.

C'est le génie discret de la Low Power Island et de BluetoothSocketSettings d'Android. Il ne s'agit pas seulement de Bluetooth. Il s'agit d'apprendre à nos appareils à être plus intelligents, et non plus occupés. Et peut-être, juste peut-être, est-ce une leçon qui vaut la peine d'être retenue pour nous-mêmes aussi.