À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Tester la gestion des appareils
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Pour garantir une compatibilité minimale avec les profils gérés, les appareils OEM doivent contenir les éléments essentiels suivants:
Pour obtenir la liste complète des conditions requises, consultez la page Implémenter la gestion des appareils. Pour tester les fonctionnalités de gestion des appareils, les propriétaires d'appareils peuvent utiliser l'application TestDPC décrite ci-dessous.
Configurer le propriétaire de l'appareil pour les tests
Suivez les instructions ci-dessous pour configurer un environnement de test pour les propriétaires d'appareils.
- Rétablissez la configuration d'usine de l'appareil cible.
- Assurez-vous que l'appareil ne contient aucun compte utilisateur (par exemple, ceux utilisés pour se connecter aux services en ligne). Pour vérifier, accédez à Paramètres > Comptes.
- Configurez l'application de test à l'aide de l'une des méthodes suivantes :
- Définissez l'application TestDPC comme propriétaire de l'appareil à l'aide de la commande suivante:
adb shell dpm set-device-owner "com.afwsamples.testdpc/.DeviceAdminReceiver"
- Suivez la procédure de configuration du propriétaire de l'appareil sur l'appareil (chiffrement, sélection du Wi-Fi).
Vérifier la configuration du propriétaire de l'appareil
Pour vérifier que le propriétaire de l'appareil a été correctement configuré, accédez à Settings > Security > Device Administrators (Paramètres > Sécurité > Administrateurs de l'appareil) et vérifiez que TestDPC figure dans la liste. Vérifiez qu'il ne peut pas être désactivé (ce qui signifie qu'il est le propriétaire de l'appareil).
Rapports de bugs et journaux
À partir d'Android 7.0, le client Device Policy (DPC) du propriétaire de l'appareil peut obtenir des rapports de bugs et afficher les journaux des processus d'entreprise sur un appareil géré.
Pour déclencher un rapport de bug (c'est-à-dire les données équivalentes collectées par adb bugreport contenant des données dumpsys, dumpstate et logcat), utilisez DevicePolicyController.requestBugReport. Une fois le rapport de bug collecté, l'utilisateur est invité à donner son autorisation pour envoyer les données du rapport de bug. Les résultats sont reçus par DeviceAdminReceiver.onBugreport[Failed|Shared|SharingDeclined]. Pour en savoir plus sur le contenu des rapports de bugs, consultez Lire des rapports de bugs.
De plus, les outils de contrôle des règles relatives aux appareils du propriétaire de l'appareil peuvent également collecter des journaux liés aux actions effectuées par un utilisateur sur un appareil géré. La journalisation des processus d'entreprise est requise pour tous les appareils qui signalent device_admin et est activée par un nouveau tampon de sécurité de journalisation lisible uniquement par le serveur système (c'est-à-dire que $ adb logcat -b security ne peut pas lire le tampon). Le service ActivityManager et les composants Keyguard journalisent les événements suivants dans le tampon de sécurité:
- Démarrage des processus d'application
- Actions du verrouillage de l'écran (par exemple, échec et réussite du déverrouillage)
- Commandes
adb envoyées à l'appareil
Pour conserver les journaux lors des redémarrages (pas du démarrage à froid) et les mettre à la disposition des DPC du propriétaire de l'appareil, un appareil doit disposer d'un noyau avec pstore et pmsg activés, et la DRAM doit être alimentée et actualisée à toutes les étapes du redémarrage pour éviter la corruption des journaux conservés en mémoire. Pour activer la prise en charge, utilisez le paramètre config_supportPreRebootSecurityLogs dans frameworks/base/core/res/res/values/config.xml.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Test device management\n\nTo ensure minimal support for managed profiles, OEM devices must contain the\nfollowing essential elements:\n\n- Profile owner (as described in [Ensuring\n Compatibility with Managed Profiles](https://developer.android.com/training/enterprise/app-compatibility.html))\n- Device owner\n\nFor a complete list of requirements, see\n[Implement device\nmanagement](/docs/devices/admin/implement). To test device management features, device owners can\nuse the TestDPC application described below.\n\nSet up device owner for testing\n-------------------------------\n\nUse the following instructions to set up a device owner testing environment.\n\n1. Factory reset the target device.\n2. Ensure the device does not contain any user accounts (for example, those used to log into online services). To verify, check *Settings \\\u003e Accounts*.\n3. Set up the testing application using one of the following methods:\n - [Download\n the TestDPC application](https://play.google.com/store/apps/details?id=com.afwsamples.testdpc&hl=en) (available from Google Play).\n - [Build\n the TestDPC application](https://github.com/googlesamples/android-testdpc/) (available from github.com).\n4. Set the TestDPC app as the device owner using the following command: \n\n ```\n adb shell dpm set-device-owner \"com.afwsamples.testdpc/.DeviceAdminReceiver\"\n ```\n5. Go through device owner setup on the device (encrypt, select Wi-Fi).\n\nVerify device owner setup\n-------------------------\n\nTo verify the device owner was correctly setup, go to *Settings \\\u003e\nSecurity \\\u003e Device Administrators* and confirm TestDPC is in the\nlist. Verify it cannot be disabled (this signifies it is a device owner).\n\nBug reports and logs\n--------------------\n\nAs of Android 7.0, device owner Device Policy Client (DPCs) can get bug\nreports and view logs for enterprise processes on a managed device.\n\nTo trigger a bug report (that is, the equivalent data collected by\n`adb bugreport` containing `dumpsys`, dumpstate, and\nlogcat data), use `DevicePolicyController.requestBugReport`. After\nthe bug report is collected, the user is prompted to give consent to send the\nbug report data. Results are received by\n`DeviceAdminReceiver.onBugreport[Failed|Shared|SharingDeclined]`. For\ndetails on bug report contents, see\n[Reading bug reports](/docs/setup/read-bug-reports).\n\nIn addition, device owner DPCs can also collect logs related to actions a\nuser has taken on a managed device. Enterprise process logging is required for\nall devices that report device_admin and enabled by a new log security buffer\nreadable only by the system server (that is, `$ adb logcat -b security`\ncannot read the buffer). ActivityManager service and Keyguard components log the\nfollowing events to the security buffer:\n\n- Application processes starting\n- Keyguard actions (for example, unlock failure and success)\n- `adb` commands issued to the device\n\nTo optionally retain logs across reboots (not cold boot) and make these logs\navailable to device owner DPCs, a device must have a kernel with\n`pstore` and `pmsg` enabled, and DRAM powered and\nrefreshed through all stages of reboot to avoid corruption to the logs retained\nin memory. To enable support, use the\n`config_supportPreRebootSecurityLogs` setting in\n`frameworks/base/core/res/res/values/config.xml`."]]
