Le logiciel pouvant être mis à jour dans le document de définition de compatibilité Android (CDD) nécessite que les appareils implémentent la classe SystemUpdatePolicy . SystemUpdatePolicy permet à l'application du propriétaire de l'appareil (DO), si elle est présente, de contrôler l'installation des mises à jour du système.
Notifier les propriétaires d'appareils
Le client OTA (Over-the-Air) doit informer les applications du propriétaire de l'appareil des mises à jour OTA entrantes à l'aide d'une API système. Le client OTA doit également inclure un enregistrement d'horodatage lorsque la mise à jour OTA est devenue disponible pour la première fois. Les clients OTA peuvent appeler DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime, boolean isSecurityPatch) pour avertir les applications du propriétaire de l'appareil. Si le client OTA ne sait pas si une mise à jour est un correctif de sécurité, il peut recourir à DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime) .
Si une mise à jour n'est pas actuellement disponible, le client OTA le signale en définissant l'argument updateReceivedTime sur -1 . Nous vous recommandons d'envoyer des notifications chaque fois que le client OTA interroge le serveur OTA ou lorsqu'un OTA est transmis au client. Vous pouvez également envoyer des notifications plus fréquemment.
Politique de mise à jour du système
Android 9 améliore la capacité des propriétaires d'appareils à contrôler les mises à jour en permettant aux propriétaires d'appareils de reporter les mises à jour OTA jusqu'à 90 jours. En se concentrant sur les solutions dédiées aux appareils (anciennement appelées COSU), cette fonctionnalité permet aux propriétaires de suspendre la version du système d'exploitation exécutée sur les appareils pendant les périodes critiques, telles que les vacances.
Pour se conformer au CDD, le client OTA doit mettre en œuvre des politiques comportementales. Le DO peut définir les politiques suivantes, qui doivent être respectées par les sous-systèmes de mise à jour du système de l'appareil :
Les propriétaires d'appareils peuvent également définir des périodes de gel (sous Android 9 ou version ultérieure) qui gèlent la version du système d'exploitation pendant les périodes critiques, telles que les vacances ou d'autres périodes de pointe. Le système n'installe pas les mises à jour OTA pendant une période de gel. Nous vous recommandons d'utiliser SystemUpdatePolicy.InstallationOption (voir la section suivante), mais le client OTA peut également appeler SystemUpdatePolicy.getFreezePeriods() pour vérifier si l'appareil est en période de gel.
Implémentation des options d'installation
Android 9 introduit un @SystemApi, SystemUpdatePolicy.InstallationOption , conçu pour les clients de mise à jour du système. SystemUpdatePolicy.InstallationOption sert de classe wrapper pour les stratégies et les périodes de gel. Une option d'installation indique aux clients comment agir sur les mises à jour système entrantes et combien de temps cette action est valide, compte tenu de la politique actuelle de mise à jour du système ou de toute période de gel qui pourrait être définie. Une option d'installation peut être l'une des suivantes :
-
TYPE_INSTALL_AUTOMATIC- Les mises à jour système entrantes s'installent immédiatement et sans intervention de l'utilisateur dès qu'elles sont disponibles. L'appareil redémarre automatiquement. -
TYPE_POSTPONE- Les mises à jour système entrantes peuvent être retardées d'un maximum de 30 jours. Les utilisateurs ne peuvent pas installer une mise à jour manuellement. Les fabricants d'appareils peuvent choisir de bloquer ou non les correctifs de sécurité. -
TYPE_PAUSE- Les mises à jour système entrantes peuvent être retardées indéfiniment jusqu'à nouvel ordre. Les utilisateurs ne peuvent pas installer une mise à jour manuellement.TYPE_PAUSEretarde toutes les mises à jour, y compris les correctifs de sécurité.
Les clients de mise à jour du système peuvent interroger SystemUpdatePolicy.InstallationOption à l'aide de SystemUpdatePolicy.getInstallationOptionAt(long when ) , où when représente l'heure à laquelle l'option d'installation est interrogée en nombre de millisecondes depuis Epoch. À l’aide de la méthode SystemUpdatePolicy.getInstallationOptionAt(long when ) , les clients de mise à jour du système peuvent agir sur l’option renvoyée jusqu’à l’expiration du délai effectif. Une fois l'option renvoyée expirée, le client peut effectuer une autre requête, en utilisant un nouvel horodatage, pour l'option la plus récente.
Le client de mise à jour du système doit écouter les diffusions DevicePolicyManager.ACTION_SYSTEM_UPDATE_POLICY_CHANGED au cas où l'ensemble de la stratégie serait mis à jour.
Validation de la stratégie TYPE_PAUSE
Vous pouvez valider manuellement le fonctionnement de l'option TYPE_PAUSE sur un système OTA.
La règle TYPE_PAUSE est en vigueur
Pour valider qu'une stratégie TYPE_PAUSE fonctionne :
- Définissez une stratégie automatique et spécifiez
TYPE_PAUSE. - Pendant que l'horloge système est en période de pause, effectuez une mise à jour OTA.
- Vérifiez que l'appareil ne prend pas la mise à jour OTA et que l'utilisateur ne peut pas installer manuellement la mise à jour.
- Si l'appareil est un appareil A/B, redémarrez l'appareil et vérifiez que le redémarrage n'a pas déclenché une installation automatique de la mise à jour.
La règle TYPE_PAUSE a expiré
Pour valider qu'une stratégie TYPE_PAUSE expirée fonctionne :
- Définissez une stratégie automatique et spécifiez
TYPE_PAUSE. - Pendant que l'horloge système est en période de pause, effectuez une mise à jour OTA.
- Attendez que la période de pause expire.
- Vérifiez que l'appareil redémarre automatiquement et que la mise à jour OTA est effectuée après le redémarrage.