Ce guide du développeur explique comment votre outil de contrôle des règles relatives aux appareils (DPC) peut gérer les mises à jour du système Android pour le compte de l'utilisateur de l'appareil.
Introduction
Les appareils Android peuvent recevoir et installer des mises à jour OTA (Over The Air) du système. et des logiciels d'application. Android informe l'utilisateur de l'appareil qu'une mise à jour du système est disponible et l'utilisateur de l'appareil peut installer la mise à jour immédiatement ou plus tard.
À l'aide de votre DPC, un administrateur informatique peut gérer les mises à jour du système pour l'utilisateur de l'appareil. DPC peuvent posséder un appareil entièrement géré (appelé propriétaire de l'appareil) ou posséder un profil professionnel. (appelée propriétaire de la fiche). Le tableau 1 montre comment les propriétaires d'appareils peuvent gérer le système mises à jour, tandis que le propriétaire d'un profil ne peut transmettre que des informations sur les mises à jour du système.
Tableau 1: les tâches disponibles pour les DPC dépendent du mode propriétaire
Rechercher des mises à jour en attente
Une mise à jour en attente est une mise à jour du système qui n'a pas encore été installée sur un appareil. Votre DPC peut aider les administrateurs informatiques à vérifier quels appareils ont des mises à jour du système en attente et peut-être demander aux utilisateurs de l’appareil d’installer rapidement les mises à jour critiques.
Propriétaires d'appareils et propriétaires de profils exécutant Android 8.0 (niveau d'API 26) ou version ultérieure
peuvent vérifier si un appareil doit
être mis à jour du système. Appeler
DevicePolicyManager.getPendingSystemUpdate()
qui renvoie null si l'appareil est à jour. Si une mise à jour
du système est en attente,
La méthode renvoie des informations sur la mise à jour.
En savoir plus sur une mise à jour en attente
Après avoir appelé getPendingSystemUpdate(), vous pouvez inspecter les
SystemUpdateInfo pour en savoir plus sur la mise à jour en attente. La
L'exemple suivant montre comment déterminer à quel moment une mise à jour en attente
disponibles pour l'appareil:
Kotlin
val firstAvailable = dpm.getPendingSystemUpdate(adminName)?.receivedTime firstAvailable?.let { Log.i(TAG, "Update first available: ${Date(firstAvailable)}") }
Java
SystemUpdateInfo updateInfo = dpm.getPendingSystemUpdate(adminName); if (updateInfo != null) { Long firstAvailable = updateInfo.getReceivedTime(); Log.i(TAG, "Update first available: " + new Date(firstAvailable)); }
Rappels système
Lorsqu'une mise à jour est disponible, le système Android informe les propriétaires de l'appareil la nouvelle mise à jour. Dans Android 8.0 ou version ultérieure, le système avertit également les propriétaires de la fiche.
Dans votre sous-classe DeviceAdminReceiver, remplacez la
Rappel onSystemUpdatePending(). Vous n'avez pas besoin
d'enregistrer ou d'annoncer votre DPC afin de recevoir le rappel. Il se peut que le système
appelez cette méthode plusieurs fois pour une seule mise à jour. Vérifiez donc l'état de la mise à jour.
avant de répondre. Appelez getPendingSystemUpdate() pour en savoir plus sur le
du système dans le rappel. L'exemple suivant montre comment procéder:
Kotlin
/** * Called when a new update is available. */ override fun onSystemUpdatePending(context: Context?, intent: Intent?, receivedTime: Long) { // System update information is supported in API level 26 or higher. if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) { return } val updateInfo = getManager(context) .getPendingSystemUpdate(getWho(context)) ?: return if (updateInfo.securityPatchState == SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) { // Perhaps install because this is a security patch. // ... } }
Java
/** * Called when a new update is available. */ public void onSystemUpdatePending (Context context, Intent intent, long receivedTime) { // System update information is supported in API level 26 or higher. if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) { return; } SystemUpdateInfo updateInfo = getManager(context) .getPendingSystemUpdate(getWho(context)); if (updateInfo == null) { return; } if (updateInfo.getSecurityPatchState() == SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) { // Perhaps install because this is a security patch. // ... } }
Lorsqu'un système comporte plusieurs DPC, par exemple des profils professionnels sur des ressources entièrement gérées appareils, le propriétaire de l'appareil et le propriétaire du profil reçoivent tous deux le rappel.
Mettre à jour les règles
Le propriétaire d'un appareil peut contrôler à quel moment les mises à jour sont installées en définissant un système local de mise à jour d'un appareil. Il existe trois types de règles de mise à jour du système:
- Automatique
- Il installe les mises à jour du système dès qu'elles disponibles (sans intervention de l'utilisateur). Définir ce type de règle installe immédiatement toutes les mises à jour en attente qui pourraient être reportés ou en attente d'un intervalle de maintenance.
- Avec fenêtre
- Il installe les mises à jour du système lors d'une maintenance quotidienne (sans intervention de l'utilisateur). Définissez le début et la fin de l'intervalle de maintenance quotidien, en minutes le jour, lors de la création d'une nouvelle règle par période.
- Reporté
- Diffère l'installation des mises à jour du système de 30 jours. Après le délai de 30 jours terminée, le système invite l'utilisateur de l'appareil à installer la mise à jour.
Périodes de report
Le système limite chaque mise à jour à un report de 30 jours. La période commence au moment où le système reporte d'abord la mise à jour et la définition de nouvelles stratégies de report prolonger la période.
Outre le report, Android pourrait ne pas être en mesure d’installer une mise à jour pour d’autres raisons telles que l'absence de connexion, l'espace disque insuffisant ou le niveau de batterie faible.
Le système réinitialise le délai de 30 jours si une autre mise à jour pendant cette période, ce qui permettra aux administrateurs informatiques d'essayer le système combiné mises à jour. Une fois les 30 jours écoulés sans nouvelle mise à jour, le système envoie une invite d'installer toutes les mises à jour en attente. Plus tard, lorsqu'une nouvelle mise à jour du système disponible, la période de 30 jours reprend.
Définir une règle
Vous pouvez définir des règles de mise à jour sous Android 8.0 (niveau d'API 26) ou version ultérieure. Pour spécifier
quand l'appareil doit installer les mises à jour du système, créez une instance
SystemUpdatePolicy à l'aide de l'un des trois types décrits
ci-dessus. Pour définir une règle, le propriétaire de l'appareil appelle la méthode DevicePolicyManager
setSystemUpdatePolicy() Le code suivant
montre comment procéder. Pour voir un exemple de règle sur fenêtre, consultez
la documentation SystemUpdatePolicy.
Kotlin
// Create the system update policy to postpone installation for 30 days. val policy = SystemUpdatePolicy.createPostponeInstallPolicy() // Get a DevicePolicyManager instance to set the policy on the device. val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager val adminName = getComponentName(context) // Set the policy. dpm.setSystemUpdatePolicy(adminName, policy)
Java
// Create the system update policy to postpone installation for 30 days. SystemUpdatePolicy policy = SystemUpdatePolicy.createPostponeInstallPolicy(); // Get a DevicePolicyManager instance to set the policy on the device. DevicePolicyManager dpm = (DevicePolicyManager) context .getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName adminName = getComponentName(context); // Set the policy. dpm.setSystemUpdatePolicy(adminName, policy);
Une fois créées, les instances de stratégie ne peuvent plus être modifiées. Pour modifier le moment où un appareil
installe les mises à jour, vous pouvez créer et définir une nouvelle règle. Pour supprimer une stratégie d'un
appareil, appelez setSystemUpdatePolicy() en transmettant null comme argument policy.
Une fois que votre DPC a supprimé une stratégie, l'utilisateur de l'appareil voit les notifications pour toute
les mises à jour du système disponibles.
Les applications peuvent appeler getSystemUpdatePolicy() pour obtenir
la règle actuelle de l'appareil. Si cette méthode renvoie null, cela signifie qu'un
la règle n'est pas définie actuellement.
Périodes de blocage
Pour figer la version du système d'exploitation pendant les périodes critiques, telles que les jours fériés ou d'autres périodes le propriétaire d'un appareil peut suspendre les mises à jour du système pour une durée maximale de 90 jours. Lorsqu'un pendant une période de blocage, il se comporte comme suit:
- L'appareil ne reçoit aucune notification concernant les mises à jour du système en attente.
- Les mises à jour du système d'exploitation ne sont pas installées.
- Les utilisateurs d'appareils ne peuvent pas rechercher manuellement les mises à jour du système dans les paramètres.
Le système applique une période de tampon obligatoire de 60 jours après un gel défini afin d'éviter que l'appareil soit gelé indéfiniment. N'oubliez pas que le système gele peuvent empêcher les appareils de recevoir les mises à jour critiques.
<ph type="x-smartling-placeholder">
Vous définissez des périodes de blocage pour une règle de mise à jour. Vous ne pouvez pas définir de périodes de blocage sans définir une règle. Lorsque l'appareil se trouve en dehors des périodes de blocage que vous avez définies, le comportement normal des règles (automatique, fenêtré ou différée) s'applique.
Définir une période de blocage
Vous pouvez définir des périodes de blocage dans Android 9 (niveau d'API 28) ou version ultérieure. Un appareil Le propriétaire définit une période de blocage pour une règle de mise à jour du système avant de la définir pour l'appareil. Les étapes sont les suivantes:
- Créez une règle de mise à jour du système (ou obtenez la règle actuelle).
- Définissez les périodes de blocage de la règle en appelant
setFreezePeriods() - Définissez la règle et les périodes de blocage de l'appareil en appelant
setSystemUpdatePolicy()
Comme la période de gel se répète chaque année, les dates de début et de fin sont représentées par des valeurs de jour et de mois. La date de début doit commencer à au moins 60 jours après la fin de toute période de blocage précédente. L'exemple suivant montre comment définir deux périodes de blocage pour une règle de mise à jour du système existante:
Kotlin
// Get the existing policy from the DevicePolicyController instance. val policy = dpm.systemUpdatePolicy ?: return try { // Set the two annual freeze periods on the policy for our retail // point-of-sale devices. val summerSale = FreezePeriod( MonthDay.of(6, 1), MonthDay.of(7, 31)) // Jun 1 - Jul 31 inclusive val winterSale = FreezePeriod( MonthDay.of(11, 20), MonthDay.of(1, 12)) // Nov 20 - Jan 12 inclusive policy.freezePeriods = Arrays.asList(summerSale, winterSale) // Set the policy again to activate the freeze periods. dpm.setSystemUpdatePolicy(adminName, policy) } catch (e: SystemUpdatePolicy.ValidationFailedException) { // There must be previous periods recorded on the device because // summerSale and winterSale don’t overlap and are separated by more // than 60 days. Report the overlap ... }
Java
// Get the existing policy from the DevicePolicyController instance. SystemUpdatePolicy policy = dpm.getSystemUpdatePolicy(); try { // Set the two annual freeze periods on the policy for our // retail point-of-sale devices. FreezePeriod summerSale = new FreezePeriod( MonthDay.of(6, 1), MonthDay.of(7, 31)); // Jun 1 - Jul 31 inclusive FreezePeriod winterSale = new FreezePeriod( MonthDay.of(11, 20), MonthDay.of(1, 12)); // Nov 20 - Jan 12 inclusive policy.setFreezePeriods(Arrays.asList(summerSale, winterSale)); // Don’t forget to set the policy again to activate the freeze periods. dpm.setSystemUpdatePolicy(adminName, policy); } catch (SystemUpdatePolicy.ValidationFailedException e) { // There must be previous periods recorded on the device because summerSale // and winterSale don’t overlap and are separated by more than 60 days. // Report the overlap ... }
Les dates de début et de fin sont incluses. Si la date de début est postérieure
que le jour de fin (comme winterSale dans l'exemple précédent), le blocage
s'étend jusqu'à l'année suivante.
Lors du blocage sur une règle de mise à jour du système, Android teste les exigences suivantes:
- Aucune période de blocage ne doit être supérieure à 90 jours.
- L'intervalle entre les périodes de gel est d'au moins 60 jours.
- Les périodes de gel ne se chevauchent pas.
- Il n'y a pas de période de blocage en double.
Lorsque vous définissez la règle de mise à jour du système pour un appareil, Android répète ces tests et inclut toutes les périodes de blocage actuelles ou passées de l'appareil.
Android génère une exception SystemUpdatePolicy.ValidationFailedException lorsque
aucun de ces tests échoue.
Pour obtenir la liste des périodes de blocage précédemment définies sur un objet de règle de mise à jour du système,
toutes les applis installées peuvent appeler
SystemUpdatePolicy.getFreezePeriods() Les éléments suivants :
exemple appelle cette méthode pour consigner les périodes de blocage d'un appareil:
Kotlin
// Log any freeze periods that might be set on a system update policy. dpm.systemUpdatePolicy?.freezePeriods?.forEach { Log.i(TAG, "Freeze period: $it") }
Java
// Log any freeze periods that might be set on a system update policy. SystemUpdatePolicy currentPolicy = dpm.getSystemUpdatePolicy(); if (currentPolicy != null) { // A policy might not be set. for (FreezePeriod freezePeriod : currentPolicy.getFreezePeriods()) { Log.i(TAG, "Freeze period: " + freezePeriod.toString()); } }
Années bissextiles
Android utilise le calendrier ISO 8601 (également appelé calendrier grégorien) pour calcule les périodes de gel et ignore les années bissextiles. Cela signifie que le 29 février n'est pas reconnue comme une date valide et est traitée comme si elle était le 28 février. Par conséquent, le 29 février n'est pas pris en compte dans le calcul de la durée d'un blocage. période.
Développement et tests
Pendant que vous développez et testez la fonctionnalité de mise à jour du système de votre DPC, vous pouvez il faut créer de nombreuses périodes de blocage. Android vérifie un intervalle de 60 jours entre les périodes de blocage précédentes, vous ne pourrez peut-être pas définir de nouvelle période de blocage sans effacer au préalable l'enregistrement des règles passées. Pour éviter le blocage de l'appareil période, exécutez la commande suivante dans Android Debug Bridge. (adb) :
adb shell dpm clear-freeze-period-record
Vous pouvez confirmer qu'un appareil est en période de blocage en vérifiant que l'utilisateur de mise à jour du système est désactivée.
Mises à jour du système Google Play (Mainline)
Les mises à jour du système Google Play (également appelées mises à jour Mainline) sont téléchargée automatiquement, mais qui nécessite un redémarrage de l'appareil pour être installé. Ces les mises à jour ne déclenchent pas de redémarrage automatique et sont installées le prochain redémarrage initié par l'utilisateur, l'administrateur ou la règle. Redémarrages déclenchés par le système la règle de mise à jour du système installe la mise à jour du système Google/OEM associé des mises à jour du système Google Play.
Vous pouvez également installer manuellement les mises à jour du système Google Play en accédant à Paramètres > À propos > Version d'Android > mise à jour du système Google Play.
Ressources supplémentaires
Pour en savoir plus sur les mises à jour du système, consultez la mise à jour OTA du projet Android Open Source. Mises à jour de la documentation.