OTA-Updates für Unternehmen

Die aktualisierbare Software des Android Compatibility Definition Document (CDD) erfordert, dass Geräte die SystemUpdatePolicy Klasse implementieren. SystemUpdatePolicy kann die Gerätebesitzer-App (DO), sofern vorhanden, die Installation von Systemupdates steuern.

Gerätebesitzer benachrichtigen

Der Over-the-Air-Client (OTA) muss Gerätebesitzer-Apps mithilfe einer System-API über eingehende OTA-Updates informieren. Der OTA-Client muss außerdem eine Zeitstempelaufzeichnung enthalten, wann das OTA-Update zum ersten Mal verfügbar wurde. OTA-Clients können DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime, boolean isSecurityPatch) aufrufen, um Gerätebesitzer-Apps zu benachrichtigen. Wenn der OTA-Client nicht weiß, ob es sich bei einem Update um einen Sicherheitspatch handelt, kann der OTA-Client 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 übertragen wird. Sie können Benachrichtigungen auch häufiger versenden.

Systemaktualisierungsrichtlinie

Android 9 verbessert die Möglichkeit für Gerätebesitzer, Updates zu steuern , indem es Gerätebesitzern ermöglicht, OTA-Updates um bis zu 90 Tage zu verschieben. Diese Funktion konzentriert sich auf Lösungen für dedizierte Geräte (früher COSU genannt) und ermöglicht es Besitzern, die Ausführung der Betriebssystemversion auf Geräten in kritischen Zeiträumen, wie z. B. Feiertagen, anzuhalten.

Um die CDD einzuhalten, muss der OTA-Client Verhaltensrichtlinien implementieren. Der DO kann die folgenden Richtlinien festlegen, die von den Aktualisierungssubsystemen des Gerätesystems beachtet werden müssen:

Gerätebesitzer können auch Einfrierzeiträume festlegen (in Android 9 oder höher), die die Betriebssystemversion in kritischen Zeiträumen wie Feiertagen oder anderen Stoßzeiten einfrieren. Das System installiert während eines Einfrierzeitraums keine OTA-Updates. Wir empfehlen die Verwendung von SystemUpdatePolicy.InstallationOption (siehe folgenden Abschnitt). Der OTA-Client kann jedoch auch SystemUpdatePolicy.getFreezePeriods() aufrufen, um zu überprüfen, ob sich das Gerät in einem Einfrierzeitraum befindet.

Installationsoptionen implementieren

Android 9 führt eine @SystemApi ein, SystemUpdatePolicy.InstallationOption , die für die Systemupdate-Clients entwickelt wurde. SystemUpdatePolicy.InstallationOption dient als Wrapper-Klasse für die Richtlinien und Sperrfristen. Eine Installationsoption teilt Clients mit, wie sie auf eingehende Systemaktualisierungen reagieren sollen und wie lange diese Aktion gültig ist, abhängig von der aktuellen Systemaktualisierungsrichtlinie oder einem möglicherweise festgelegten Einfrierzeitraum. Eine der folgenden Installationsoptionen kann sein:

  • TYPE_INSTALL_AUTOMATIC – Eingehende Systemaktualisierungen werden sofort und ohne Benutzereingriff installiert, sobald sie verfügbar sind. Das Gerät startet automatisch neu.
  • TYPE_POSTPONE – Eingehende Systemaktualisierungen können um maximal 30 Tage verzögert werden. Benutzer können ein Update nicht manuell installieren. Gerätehersteller können entscheiden, ob Sicherheitspatches blockiert werden sollen oder nicht.
  • TYPE_PAUSE – Eingehende Systemaktualisierungen können bis auf weiteres auf unbestimmte Zeit verzögert werden. Benutzer können ein Update nicht manuell installieren. TYPE_PAUSE verzögert alle Updates, einschließlich Sicherheitspatches.

Systemaktualisierungsclients können SystemUpdatePolicy.InstallationOption mit SystemUpdatePolicy.getInstallationOptionAt(long when ) abfragen, wobei when die Zeit in Millisekunden darstellt, zu der die Installationsoption seit Epoche abgefragt wird. Mit der Methode SystemUpdatePolicy.getInstallationOptionAt(long when ) können Systemaktualisierungsclients auf die zurückgegebene Option reagieren, bis die effektive Zeit abgelaufen ist. Nachdem die zurückgegebene Option abgelaufen ist, kann der Client eine weitere Abfrage mit einem neuen Zeitstempel für die neueste Option durchführen.

Der Systemaktualisierungsclient muss auf DevicePolicyManager.ACTION_SYSTEM_UPDATE_POLICY_CHANGED Broadcasts warten, falls die gesamte Richtlinie aktualisiert wird.

Validierung der TYPE_PAUSE -Richtlinie

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

Die Richtlinie TYPE_PAUSE ist in Kraft

So überprüfen Sie, ob eine TYPE_PAUSE Richtlinie funktioniert:

  1. Legen Sie eine automatische Richtlinie fest und geben Sie TYPE_PAUSE an.
  2. Während sich die Systemuhr im Pausenzeitraum befindet, pushen Sie ein OTA-Update.
  3. Stellen Sie sicher, dass das Gerät das OTA-Update nicht akzeptiert und der Benutzer das Update nicht manuell installieren kann.
  4. Wenn es sich bei dem Gerät um ein A/B-Gerät handelt, starten Sie das Gerät neu und stellen Sie sicher, dass der Neustart keine automatische Installation des Updates ausgelöst hat.

Richtlinie TYPE_PAUSE ist abgelaufen

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

  1. Legen Sie eine automatische Richtlinie fest und geben Sie TYPE_PAUSE an.
  2. Während sich die Systemuhr im Pausenzeitraum befindet, pushen Sie ein OTA-Update.
  3. Warten Sie, bis die Pausenzeit abgelaufen ist.
  4. Stellen Sie sicher, dass das Gerät automatisch neu startet und das OTA-Update nach dem Neustart durchgeführt wird.