Unternehmens-OTA-Updates

Gemäß dem Android Compatibility Definition Document (CDD) für aktualisierbare Software müssen Geräte die Klasse SystemUpdatePolicy implementieren. Mit SystemUpdatePolicy kann die App des Geräteeigentümers (Device Owner, DO), falls vorhanden, die Installation von Systemupdates steuern.

Geräteeigentümer benachrichtigen

Der Over-the-Air-Client (OTA-Client) muss Geräteeigentümer-Apps über eingehende OTA-Updates mithilfe einer System-API benachrichtigen. Der OTA-Client muss außerdem einen Zeitstempel enthalten, der aufgezeichnet wird, wann das OTA-Update zum ersten Mal verfügbar war. OTA-Clients können DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime, boolean isSecurityPatch) aufrufen, um Geräteeigentümer-Apps zu benachrichtigen. Wenn der OTA-Client nicht weiß, ob ein Update ein Sicherheitspatch ist, kann er auf DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime) zurückgreifen.

Wenn derzeit kein Update verfügbar ist, meldet der OTA-Client dies, indem er das Argument updateReceivedTime auf -1 setzt. Wir empfehlen, Benachrichtigungen zu senden, wenn der OTA-Client den OTA-Server abfragt oder wenn ein OTA an den Client gesendet wird. Sie können Benachrichtigungen auch häufiger senden.

Richtlinie für Systemupdates

Unter Android 9 können Geräteeigentümer Updates steuern, indem sie OTA-Updates bis zu 90 Tage lang verschieben. Diese Funktion ist auf Lösungen für zweckbestimmte Geräte (früher „unternehmenseigene, zweckgebundene Geräte“ (COSU)) ausgerichtet. Mit ihr können Eigentümer die auf Geräten ausgeführte Betriebssystemversion während kritischer Zeiträume wie Feiertagen pausieren.

Um die CDD einzuhalten, muss der OTA-Client Verhaltensrichtlinien implementieren. Der Dienstanbieter kann die folgenden Richtlinien festlegen, die von den Subsystemen für die Gerätesystemupdates eingehalten werden müssen:

Geräteeigentümer können auch Zeiträume festlegen (unter Android 9 und höher), in denen die Betriebssystemversion über wichtige Zeiten hinweg eingefroren wird, z. B. zu Feiertagen oder zu anderen Zeiten mit hohen Zugriffszahlen. Während einer Sperrzeit werden keine OTA-Updates installiert. Wir empfehlen die Verwendung von SystemUpdatePolicy.InstallationOption (siehe folgender Abschnitt). Der OTA-Client kann jedoch auch SystemUpdatePolicy.getFreezePeriods() aufrufen, um zu prüfen, ob sich das Gerät in einer Sperrzeit befindet.

Installationsoptionen implementieren

In Android 9 wird die @SystemApi SystemUpdatePolicy.InstallationOption eingeführt, die für die Systemupdate-Clients entwickelt wurde. SystemUpdatePolicy.InstallationOption dient als Wrapper-Klasse für die Richtlinien und Fixierungszeiträume. Eine Installationsoption gibt Clients an, wie sie auf eingehende Systemupdates reagieren sollen und wie lange diese Aktion gültig ist, unter Berücksichtigung der aktuellen Systemupdate-Richtlinie oder eines möglicherweise festgelegten Sperrzeitraums. Folgende Installationsoptionen sind möglich:

  • TYPE_INSTALL_AUTOMATIC – Eingehende Systemupdates werden sofort und ohne Nutzereingriff installiert, sobald sie verfügbar sind. Das Gerät wird automatisch neu gestartet.
  • TYPE_POSTPONE – Eingehende Systemupdates können um maximal 30 Tage verzögert werden. Nutzer können Updates nicht manuell installieren. Gerätehersteller können entscheiden, ob Sicherheitspatches blockiert werden sollen oder nicht.
  • TYPE_PAUSE: Eingehende Systemupdates können sich bis auf Weiteres auf unbestimmte Zeit verzögern. Nutzer können Updates nicht manuell installieren. TYPE_PAUSE verzögert alle Updates, einschließlich Sicherheitspatches.

Systemaktualisierungsclients können SystemUpdatePolicy.InstallationOption mit SystemUpdatePolicy.getInstallationOptionAt(long when) abfragen. Dabei steht when für die Zeit, zu der die Installationsoption in Millisekunden seit der Epoche abgefragt wird. Mit der Methode SystemUpdatePolicy.getInstallationOptionAt(long when) können Systemupdate-Clients auf die zurückgegebene Option reagieren, bis die effektive Zeit abgelaufen ist. Nach Ablauf der zurückgegebenen Option kann der Client mit einem neuen Zeitstempel eine weitere Abfrage für die neueste Option stellen.

Der Systemupdate-Client muss auf DevicePolicyManager.ACTION_SYSTEM_UPDATE_POLICY_CHANGED-Broadcasts warten, falls die gesamte Richtlinie aktualisiert wird.

TYPE_PAUSE-Richtlinie prüfen

Sie können manuell prüfen, ob die Option TYPE_PAUSE in einem OTA-System funktioniert.

Die Richtlinie TYPE_PAUSE ist in Kraft

So prüfen Sie, ob eine TYPE_PAUSE-Richtlinie funktioniert:

  1. Legen Sie eine automatische Richtlinie fest und geben Sie TYPE_PAUSE an.
  2. Führe ein OTA-Update durch, während sich die Systemuhr in der Pause befindet.
  3. Achte darauf, dass das OTA-Update nicht auf dem Gerät ausgeführt wird und Nutzer es nicht manuell installieren können.
  4. Wenn es sich um ein A/B-Gerät handelt, starten Sie es neu und prüfen Sie, ob durch den Neustart keine automatische Installation des Updates ausgelöst wurde.

Richtlinie TYPE_PAUSE ist abgelaufen

So prüfen Sie, ob eine abgelaufene TYPE_PAUSE-Richtlinie funktioniert:

  1. Legen Sie eine automatische Richtlinie fest und geben Sie TYPE_PAUSE an.
  2. Führe ein OTA-Update durch, während sich die Systemuhr in der Pause befindet.
  3. Warten Sie, bis die Pause abgelaufen ist.
  4. Prüfe, ob das Gerät nach dem Neustart automatisch neu gestartet wird und das OTA-Update übernommen wird.