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 du logiciel 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. Les DPC peuvent posséder un appareil entièrement géré (appelé "propriétaire de l'appareil") ou un profil professionnel (appelé "propriétaire du profil"). Le tableau 1 montre comment les propriétaires d'appareils peuvent gérer les mises à jour du système, tandis que les propriétaires de profils ne peuvent signaler 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. L'exemple suivant montre comment savoir quand une mise à jour en attente a été disponible pour la première fois sur 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 la mise à jour 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 peuvent être reportées ou qui attendent une fenêtre 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. À l'issue de la période de 30 jours, 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 stratégie, le propriétaire de l'appareil appelle la méthode DevicePolicyManager setSystemUpdatePolicy(). L'exemple de 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 tampon obligatoire de 60 jours après toute période de blocage définie pour éviter de bloquer l'appareil indéfiniment. N'oubliez pas que le système gele peuvent empêcher les appareils de recevoir les mises à jour critiques.
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 de la règle (aucune, automatique, programmée ou reporté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()
Étant donné que la période de blocage se répète chaque année, les dates de début et de fin de la période sont représentées par des valeurs de mois et de jour. 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.
Lorsque vous définissez des périodes de blocage sur une stratégie de mise à jour du système, Android vérifie 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ériodes 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 reconnu comme une date valide et est traité comme s'il s'agissait du 28 février. Par conséquent, le 29 février n'est pas comptabilisé lors du calcul de la durée d'une période de blocage.
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.
Effectuer le rollback d'une mise à jour
Dans certains cas, l'outil GPSUR (Google Play System Update Rollbacks) peut être utilisé pour récupérer l'état de l'appareil en raison d'une installation problématique de la mise à jour du système Google Play. Cet outil doit être utilisé par des utilisateurs expérimentés ou sur demande du personnel d'assistance, car il peut entraîner une perte de données. Pour utiliser le GPSUR, procédez comme suit : outil:
- Si Android Debug Bridge (adb) est en cours d'exécution sur votre ordinateur, arrêtez
le service adb avant de continuer, afin qu'il n'interfère pas avec
processus de rollback. Pour arrêter adb, exécutez
adb kill-server. - Ouvrez l'outil GPSUR.
- Cliquez sur Autoriser l'accès à ADB pour permettre à l'outil de communiquer avec votre test. appareil via adb.
- Cliquez sur Ajouter un appareil.
- Sélectionnez votre appareil dans la liste, puis cliquez sur Connecter. Il est possible que cette liste ne soit pas contiennent le nom complet de l'appareil.
- Sur l'écran de votre appareil, sélectionnez Toujours autoriser sur cet ordinateur, puis cliquez sur OK pour accepter la connexion de débogage USB.
- Sélectionnez l'appareil connecté dans votre navigateur.
- Le texte du bouton sur la page doit passer de Aucun rollback disponible à Rollback des mises à jour récentes si des rollbacks sont disponibles sur votre appareil. Cliquez sur Effectuer le rollback des mises à jour récentes.
- Lisez les avertissements dans la fenêtre modale Confirmer le rollback, puis cliquez sur Confirmer.
- Attendez la fin du rollback. Une fois l'opération terminée, un Rollback réussi s'affiche et l'appareil redémarre. Vous pouvez à présent débrancher votre appareil.
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.