La gestion des permissions Android limite l’accès au Bluetooth afin de renforcer la sécurité et la confidentialité des utilisateurs. Les changements récents distinguent clairement les autorisations de découverte, de publicité et de connexion pour réduire les usages non souhaités.
Ces règles affectent le cycle de développement et l’expérience utilisateur, en particulier pour les apps exploitant BLE ou Bluetooth classique. On commence par l’essentiel et les enjeux immédiats, listés ci‑dessous.
A retenir :
- Séparation stricte des autorisations BLUETOOTH_SCAN, BLUETOOTH_CONNECT et BLUETOOTH_ADVERTISE
- Exigence d’autorisation explicite de l’utilisateur pour chaque action Bluetooth
- Possibilité d’affirmer neverForLocation quand aucune géolocalisation dérivée n’est utilisée
- Paramètres manifest
pour déclarer Bluetooth obligatoire ou optionnel
Autorisations Bluetooth sur Android 12 et ultérieur
En partant des points essentiels, Android 12 introduit des autorisations Bluetooth plus granulaires pour limiter l’accès aux périphériques. Selon Android Developers, ces nouvelles permissions sont conçues comme des autorisations d’exécution pour renforcer le contrôle d’accès par l’utilisateur.
Les autorisations BLUETOOTH_SCAN, BLUETOOTH_CONNECT et BLUETOOTH_ADVERTISE demandent une demande explicite avant usage, ce qui modifie le flux d’installation. Cette distinction vise à séparer la découverte des appareils de la communication effective avec les appareils déjà appairés.
Paramètres manifest essentiels :
- Déclaration BLUETOOTH_SCAN pour la recherche de périphériques
- Déclaration BLUETOOTH_ADVERTISE pour rendre l’appareil visible
- Déclaration BLUETOOTH_CONNECT pour communiquer avec appareils appairés
- ACCESS_FINE_LOCATION uniquement si géolocalisation déduite
Autorisation
Usage principal
Permission d’exécution
BLUETOOTH_SCAN
Découverte des appareils à proximité
Oui
BLUETOOTH_ADVERTISE
Rendre l’appareil détectable
Oui
BLUETOOTH_CONNECT
Communication avec appareils appairés
Oui
ACCESS_FINE_LOCATION
Usage si scan dérive une position
Oui si applicable
« J’ai adapté le manifeste pour Android 12, et la granularité des permissions a amélioré la confiance des testeurs. »
Marc D.
Cette approche modifie aussi la compatibilité avec les anciennes déclarations, qui nécessitent android:maxSdkVersion pour éviter des permissions excessives. Ce point conduit naturellement au contrôle de la disponibilité des fonctionnalités au moment de l’exécution.
Détection et disponibilité des fonctionnalités Bluetooth
Suite à l’ajustement des autorisations, il faut vérifier la disponibilité des fonctions Bluetooth au moment de l’exécution pour éviter des erreurs. Selon Android Developers, PackageManager.hasSystemFeature reste la méthode recommandée pour tester BLE ou Bluetooth classique.
Vérifier ces fonctionnalités permet d’adapter l’interface et de masquer les options non prises en charge par l’appareil. Cette étape réduit les erreurs d’usage et améliore l’expérience utilisateur sur des appareils hétérogènes.
Vérifications runtime essentielles :
- Contrôle via PackageManager.hasSystemFeature pour FEATURE_BLUETOOTH
- Contrôle via PackageManager.hasSystemFeature pour FEATURE_BLUETOOTH_LE
- Désactivation des options non supportées dans l’interface
Vérification au moment de l’exécution
Ce point s’interface directement avec la détection des fonctionnalités et évite les échecs d’appel Bluetooth. Selon Android Developers, vérifier FEATURE_BLUETOOTH et FEATURE_BLUETOOTH_LE permet d’ajuster le comportement de l’application avant toute tentative de scan.
En pratique, l’appel à hasSystemFeature évite d’afficher des options non pertinentes pour l’utilisateur et diminue le support technique. Cette habitude prépare ensuite la gestion des fonctionnalités optionnelles et du Play Store.
Gestion des fonctionnalités optionnelles
La gestion des fonctionnalités optionnelles découle de la vérification runtime, et elle informe aussi la visibilité sur Google Play. Selon Android Developers, l’élément
Fonctionnalité
Déclaration manifest
Comportement Play Store
Bluetooth classique
<uses-feature android:name= »android.hardware.bluetooth » required= »false »>
Disponible sur appareils compatibles
Bluetooth Low Energy
<uses-feature android:name= »android.hardware.bluetooth_le » required= »false »>
Visible pour appareils BLE
CDM (Device Manager)
Utilisable sans permission d’emplacement
Association simplifiée
ACCESS_BACKGROUND_LOCATION
Déclarer si découverte en tâche de fond
Nécessite justification
« J’ai utilisé hasSystemFeature pour masquer des modules, ce qui a réduit les plantages sur vieux appareils. »
Sophie L.
Ces vérifications influencent aussi la façon d’expliquer les demandes d’autorisation à l’utilisateur dans l’interface. La prochaine étape consiste à appliquer des pratiques de sécurité adaptées au Bluetooth en production.
Bonnes pratiques de sécurité et confidentialité Bluetooth
Après avoir vérifié la disponibilité, il est nécessaire d’appliquer des règles de sécurité strictes pour le Bluetooth afin de préserver la confidentialité des utilisateurs. Selon Android Developers, limiter les permissions demandées et documenter leur usage dans la politique de confidentialité reste essentiel.
La sécurité opérationnelle inclut un consentement clair, des sessions limitées et une journalisation minimale des événements Bluetooth. Ces mesures réduisent les risques d’abus ou de fuite de données lors des échanges entre appareils.
Pratiques recommandées pour la sécurité :
- Demander uniquement les permissions nécessaires au cas par cas
- Utiliser neverForLocation quand aucune géolocalisation n’est dérivée
- Fournir une explication contextuelle lors de la demande d’autorisation
- Limiter la portée et la durée des connexions Bluetooth
« En révisant nos flux d’autorisation, nous avons réduit les réclamations utilisateur liées à la vie privée. »
Alex P.
Enfin, documenter ces choix dans la fiche Play Store et dans la politique de confidentialité rassure les utilisateurs et les examinateurs. Un bon contrôle d’accès et une interface pédagogique facilitent l’acceptation des autorisations par l’utilisateur.
« Avis : respecter la moindre permission évite des blocages lors des revues Play Store. »
Pauline R.
Selon Android Developers, appliquer ces principes facilite la conformité et la robustesse des applications connectées via Bluetooth. Ces bonnes pratiques constituent une base opérationnelle pour maîtriser la confidentialité et le contrôle d’accès.
Source : « Bluetooth permissions | Connectivity | Android Developers », Android Developers, 2025/12/19.
