Unternehmens-OTA-Updates

Die Android CDD-Software (Compatibility Definition Document) für die Implementierung der SystemUpdatePolicy . 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 angibt, wann das OTA-Update zum ersten Mal verfügbar war. OTA-Clients können DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime, boolean isSecurityPatch) , um die Apps von Geräteeigentümern zu benachrichtigen. Wenn der OTA-Client nicht weiß, ob ein Update ein Sicherheitspatch handelt, kann der OTA-Client DevicePolicyManager.notifyPendingSystemUpdate(long updateReceivedTime)

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

Richtlinie für Systemupdates

Android 9 verbessert die Inhaber*innen Kontrolle , da Geräteeigentümer OTA-Updates um bis zu 90 Tage. Diese Funktion, die sich auf Lösungen für zweckbestimmte Geräte (früher „unternehmenseigene, zweckgebundene Geräte“ (COSU)) konzentriert, ermöglicht es Eigentümern, die auf ihren Geräten ausgeführte Betriebssystemversion während kritischer Zeiträume wie Feiertagen zu 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 oder höher), in denen die Betriebssystemversion während kritischer Zeiträume wie Feiertagen oder anderen geschäftigen Zeiten eingefroren wird. 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

Mit Android 9 wird eine @SystemApi, SystemUpdatePolicy.InstallationOption, das so konzipiert ist, für die Systemupdate-Clients. SystemUpdatePolicy.InstallationOption dient als Wrapper 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. Eine Installationsoption kann eine der Folgendes:

  • 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 festlegen, ob Sicherheits-Patches blockiert werden sollen oder nicht.
  • TYPE_PAUSE – Eingehende Systemupdates können sich bis auf Weiteres unbegrenzt verzögern. Nutzer können Updates nicht installieren manuell. TYPE_PAUSE verzögert alle Updates, einschließlich Sicherheitspatches.

Systemupdate-Clients 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 so lange auf die zurückgegebene Option reagieren, bis die effektive Zeit verstrichen ist. Nachdem die zurückgegebene Option abgelaufen ist, 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 wenn die Richtlinie aktualisiert wird.

TYPE_PAUSE-Richtlinie prüfen

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

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. Während die Systemuhr in der Pause ist, senden Sie ein Over-the-air-Update.
  3. Prüfen Sie, ob das Gerät das OTA-Update nicht akzeptiert und der Nutzer das Update nicht manuell installieren kann.
  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 Richtlinie „TYPE_PAUSE“ 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üfen Sie, ob das Gerät automatisch neu gestartet wird und das OTA-Update nach dem Neustart durchgeführt wird.