Verwalten von Systemupdates

Dieser Leitfaden erläutert, wie Ihr Geräteverwaltungscontroller (DPC) im Auftrag des Gerätebenutzers Android-Systemupdates verwalten kann.

Einführung

Android-Geräte können Over-the-Air (OTA)-Updates für das System- und Anwendungssoftware erhalten und installieren. Android benachrichtigt den Gerätebenutzer, wenn ein Systemupdate verfügbar ist, und der Gerätebenutzer kann das Update sofort oder später installieren.

Mithilfe Ihres DPC kann ein IT-Administrator Systemupdates für den Gerätebenutzer verwalten. DPCs können ein vollständig verwaltetes Gerät besitzen (als Gerätebesitzer bezeichnet) oder ein Arbeitsprofil besitzen (als Profilbesitzer bezeichnet). Tabelle 1 zeigt, wie Gerätebesitzer Systemupdates verwalten können, während Profilbesitzer nur Informationen über Systemupdates melden können.

Tabelle 1: Aufgaben, die von DPCs abhängig vom Besitzermodus verfügbar sind.

Aufgabe	Gerätebesitzer	Profilbesitzer
Überprüfen auf ausstehende Systemupdates	✔️	–
Benachrichtigung über neue Systemupdates erhalten	✔️	✔️
Lokale Update-Richtlinie festlegen	✔️	–
Betriebssystemversion über kritische Zeiträume einfrieren	✔️	–

Überprüfen auf ausstehende Updates

Ein ausstehendes Update ist ein Systemupdate für ein Gerät, das noch nicht installiert wurde. Ihr DPC kann IT-Administratoren dabei helfen, zu überprüfen, welche Geräte ausstehende Systemupdates haben und die Gerätebenutzer möglicherweise bitten, kritische Updates schnell zu installieren.

Gerätebesitzer und Profilbesitzer, die auf Android 8.0 (API-Level 26) oder höher laufen, können prüfen, ob ein Gerät ein ausstehendes Systemupdate hat. Rufen Sie DevicePolicyManager.getPendingSystemUpdate() auf, das null zurückgibt, wenn das Gerät auf dem neuesten Stand ist. Wenn ein Systemupdate aussteht, gibt die Methode Informationen über das Update zurück.

Weitere Informationen zu einem ausstehenden Update

Nach dem Aufruf von getPendingSystemUpdate() können Sie den zurückgegebenen SystemUpdateInfo-Wert überprüfen, um weitere Informationen über das ausstehende Update zu erhalten. Das folgende Beispiel zeigt, wie Sie beispielsweise feststellen können, seit wann das ausstehende Update für das Gerät verfügbar ist:

SystemUpdateInfo pendingUpdate = dpm.getPendingSystemUpdate();
if (pendingUpdate != null) {
    long pendingSince = pendingUpdate.getReceivedTime();
    // Weitere Verarbeitung ...
}

Systemrückrufe

Wenn ein Update verfügbar ist, benachrichtigt das Android-System Gerätebesitzer über das neue Update. In Android 8.0 oder höher benachrichtigt das System auch Profilbesitzer.

Überschreiben Sie in Ihrer DeviceAdminReceiver-Unterklasse den onSystemUpdatePending()-Rückruf. Sie müssen Ihren DPC nicht registrieren oder werben, um den Rückruf zu erhalten. Das System kann diese Methode mehrmals für ein einzelnes Update aufrufen, daher sollten Sie den Status des Updates vor der Antwort überprüfen. Rufen Sie getPendingSystemUpdate() auf, um im Rückruf weitere Informationen über das Systemupdate zu erhalten. Das folgende Beispiel zeigt, wie Sie dies tun können:

@Override
public void onSystemUpdatePending(Context context, Intent intent) {
    SystemUpdateInfo pendingUpdate = dpm.getPendingSystemUpdate();
    if (pendingUpdate != null) {
        int status = pendingUpdate.getStatus();
        // Weitere Verarbeitung ...
    }
}

Wenn ein System mehrere DPCs hat, zum Beispiel Arbeitsprofile auf vollständig verwalteten Geräten, erhalten sowohl der Gerätebesitzer als auch der Profilbesitzer den Rückruf.

Update-Richtlinien

Ein Gerätebesitzer kann steuern, wann Updates installiert werden, indem er eine lokale Systemupdate-Richtlinie für ein Gerät festlegt. Die Systemupdate-Richtlinie kann einen der folgenden drei Typen haben:

• Automatisch: Installiert Systemupdates, sobald sie verfügbar sind (ohne Benutzerinteraktion). Dieser Richtlinientyp installiert sofort ausstehende Updates, die möglicherweise aufgeschoben oder auf ein Wartungsfenster warten.
• Zeitfenster: Installiert Systemupdates während eines täglichen Wartungsfensters (ohne Benutzerinteraktion). Legen Sie den Start und das Ende des täglichen Wartungsfensters als Minuten des Tages fest, wenn Sie eine neue zeitfensterbasierte Richtlinie erstellen.
• Aufgeschoben: Verschiebt die Installation von Systemupdates um 30 Tage. Nach Ablauf der 30-Tage-Frist fordert das System den Gerätebenutzer auf, das Update zu installieren.

Aufschubzeiträume

Das System beschränkt jedes Update auf eine Aufschiebung von 30 Tagen. Der Zeitraum beginnt, wenn das System das Update zum ersten Mal aufschiebt, und das Festlegen neuer Aufschubrichtlinien verlängert den Zeitraum nicht.

Achtung: Das Aufschieben von OTA-Updates kann verhindern, dass Geräte wichtige Updates erhalten. Aus diesem Grund können Gerätehersteller oder Mobilfunkanbieter wichtige Sicherheitsupdates von einer Aufschiebepolitik ausnehmen. Ausgenommene Updates benachrichtigen den Gerätebenutzer, wenn sie verfügbar sind.

Abgesehen von der Aufschiebung kann Android ein Update aus anderen Gründen möglicherweise nicht installieren, wie zum Beispiel fehlende Konnektivität, unzureichender Speicherplatz oder schwacher Akku.

Der Timer für die 30-tägige Aufschiebung wird zurückgesetzt, wenn während des Zeitraums ein anderes Update verfügbar wird. Dadurch haben IT-Administratoren die Möglichkeit, die kombinierten Systemupdates auszuprobieren. Nach Ablauf von 30 Tagen ohne ein neues Update wird der Benutzer aufgefordert, alle ausstehenden Updates zu installieren. Wenn dann ein neues Systemupdate verfügbar wird, beginnt die 30-Tage-Frist erneut.

Richtlinie festlegen

Sie können Update-Richtlinien in Android 8.0 (API-Level 26) oder höher festlegen. Um festzulegen, wann das Gerät Systemupdates installieren soll, erstellen Sie eine Instanz von SystemUpdatePolicy mit einem der oben genannten Richtlinientypen. Um eine Richtlinie festzulegen, ruft der Gerätebesitzer die Methode setSystemUpdatePolicy() von DevicePolicyManager auf. Das folgende Codebeispiel zeigt, wie Sie dies tun können:

SystemUpdatePolicy policy = SystemUpdatePolicy.createAutomaticInstallPolicy();
devicePolicyManager.setSystemUpdatePolicy(adminComponentName, policy);

Policy-Instanzen können nicht geändert werden, nachdem sie erstellt wurden. Um zu ändern, wann ein Gerät Updates installiert, können Sie eine neue Richtlinie erstellen und setzen. Um eine Richtlinie von einem Gerät zu entfernen, rufen Sie setSystemUpdatePolicy() auf und übergeben null als Richtlinienargument. Nachdem Ihr DPC eine Richtlinie entfernt hat, sieht der Gerätebenutzer Benachrichtigungen für alle verfügbaren Systemupdates.

Apps können getSystemUpdatePolicy() aufrufen, um die aktuelle Richtlinie für das Gerät abzurufen. Wenn diese Methode null zurückgibt, ist keine Richtlinie festgelegt.

Einfrieren von Zeiträumen

Gerätebesitzer können die Betriebssystemversion während kritischer Zeiträume wie Feiertagen oder anderen geschäftigen Zeiten für bis zu 90 Tage einfrieren. Wenn sich ein Gerät innerhalb eines Einfrierzeitraums befindet, verhält es sich wie folgt:

• Das Gerät erhält keine Benachrichtigungen über ausstehende Systemupdates.
• Systemupdates für das Betriebssystem werden nicht installiert.
• Gerätebenutzer können in den Einstellungen nicht manuell nach Systemupdates suchen.

Das System legt einen obligatorischen Pufferzeitraum von 60 Tagen nach jedem definierten Einfrierzeitraum fest, um zu verhindern, dass das Gerät unendlich lange eingefroren bleibt. Denken Sie daran, dass das Einfrieren von Systemupdates verhindern kann, dass Geräte wichtige Updates erhalten.

Abbildung 1: Zwei Einfrierzeiträume für ein Gerät

Einfrierzeitraum festlegen

Sie können Einfrierzeiträume in Android 9 (API-Level 28) oder höher festlegen. Ein Gerätebesitzer legt einen Einfrierzeitraum auf eine Systemupdate-Richtlinie fest, bevor er die Richtlinie für das Gerät festlegt. Die Schritte sind wie folgt:

1. Erstellen Sie eine neue (oder erhalten Sie die aktuelle) Systemupdate-Richtlinie.
2. Legen Sie die Einfrierzeiträume auf der Richtlinie fest, indem Sie setFreezePeriods() aufrufen.
3. Legen Sie die Richtlinie und die Einfrierzeiträume für das Gerät fest, indem Sie setSystemUpdatePolicy() aufrufen.

Da der Einfrierzeitraum jährlich wiederholt wird, werden die Start- und Enddaten des Zeitraums durch Monats- und Tagwerte dargestellt. Der Starttag muss mindestens 60 Tage nach dem Ende eines vorherigen Einfrierzeitraums beginnen. Das folgende Beispiel zeigt, wie Sie zwei Einfrierzeiträume für eine vorhandene Systemupdate-Richtlinie festlegen können:

SystemUpdatePolicy policy = devicePolicyManager.getSystemUpdatePolicy(adminComponentName);
if (policy == null) {
    policy = SystemUpdatePolicy.createAutomaticInstallPolicy();
}

policy.setFreezePeriods(
        new Period.Builder()
                .setStart(LocalDate.of(2021, 12, 24))
                .setEnd(LocalDate.of(2021, 12, 25))
                .build(),
        new Period.Builder()
                .setStart(LocalDate.of(2022, 4, 1))
                .setEnd(LocalDate.of(2022, 4, 2))
                .build());

devicePolicyManager.setSystemUpdatePolicy(adminComponentName, policy);

Sowohl der Starttag als auch der Endtag sind inklusiv. Wenn der Starttag später als der Endtag ist (wie bei “WinterSale” im vorherigen Beispiel), erstreckt sich der Einfrierzeitraum auf das folgende Jahr.

Beim Festlegen von Einfrierzeiträumen auf einer Systemupdate-Richtlinie überprüft Android diese Anforderungen:

• Kein Einfrierzeitraum dauert länger als 90 Tage.
• Das Intervall zwischen Einfrierzeiträumen beträgt mindestens 60 Tage.
• Einfrierzeiträume überlappen sich nicht.
• Es gibt keine doppelten Einfrierzeiträume.

Beim Festlegen der Systemupdate-Richtlinie für ein Gerät wiederholt Android diese Tests und berücksichtigt alle aktuellen oder früheren Einfrierzeiträume für das Gerät.

Wenn eines dieser Tests fehlschlägt, wirft Android eine SystemUpdatePolicy.ValidationFailedException aus.

Alle installierten Apps können SystemUpdatePolicy.getFreezePeriods() aufrufen, um eine Liste der zuvor auf einer Systemupdate-Richtlinie festgelegten Einfrierzeiträume abzurufen. Das folgende Beispiel ruft diese Methode auf, um die Einfrierzeiträume eines Geräts zu protokollieren:

SystemUpdatePolicy policy = devicePolicyManager.getSystemUpdatePolicy(adminComponentName);
if (policy != null) {
    List<Period> freezePeriods = policy.getFreezePeriods();
    for (Period period : freezePeriods) {
        Log.d(TAG, "Freeze period: " + period.getStart() + " - " + period.getEnd());
    }
}

Schaltjahre

Android verwendet den ISO-8601-Kalender (auch Gregorianischer Kalender genannt), um Einfrierzeiträume zu berechnen, und ignoriert Schaltjahre. Dies bedeutet, dass der 29. Februar nicht als gültiges Datum erkannt wird und als wäre es der 28. Februar behandelt wird. Daher wird der 29. Februar bei der Berechnung der Dauer eines Einfrierzeitraums nicht berücksichtigt.

Entwicklung und Tests

Während Sie die Systemupdate-Funktion Ihres DPC entwickeln und testen, müssen Sie möglicherweise viele Einfrierzeiträume erstellen. Da Android auf ein 60-tägiges Intervall zwischen vergangenen Einfrierzeiträumen prüft, können Sie möglicherweise keinen neuen Einfrierzeitraum festlegen, ohne zuerst den Verlauf vergangener Zeiträume zu löschen. Um den Einfrierzeitraumverlauf des Geräts zu löschen, führen Sie den folgenden Befehl in der Android Debug Bridge (adb) Shell aus:

adb shell dpm clear-freeze-period-record

Sie können überprüfen, ob sich ein Gerät in einem Einfrierzeitraum befindet, indem Sie überprüfen, ob die Benutzeroberfläche für Systemupdates deaktiviert ist.

Weitere Ressourcen

Um mehr über Systemupdates zu erfahren, lesen Sie die OTA Updates-Dokumentation des Android Open Source Project.