Android Remote Update per MDM durchführen – Die vollständige Anleitung

Vor MDM bedeutete das Einspielen eines Updates auf einem verwalteten Android-Gerät physischen Kontakt. Für IT-Admins, die Geräte an mehreren Standorten verwalten, hieß das oft: zum Standort fahren, durch ein Lager laufen oder jemanden vor Ort koordinieren, der dafür nicht ausgebildet war. Ein Android Remote Update ändert das grundlegend – aber nur, wenn Ihre Geräte enrollt und Ihre Richtlinien korrekt konfiguriert sind.

Remote-OS-Updates auf Android funktionieren über eine MDM-konfigurierte Systemupdate-Richtlinie, die dem Gerät mitteilt, wann OTA-Updates vom OEM installiert werden sollen. 14 % der Android-Geräte in Enterprise-Umgebungen im Jahr 2024 können überhaupt nicht aktualisiert werden und bleiben damit ungeschützt. Für alle anderen hängt die Update-Bereitstellung stark vom Enrollment-Modus ab – und nicht jeder Modus unterstützt jeden Richtlinientyp.

„Remote Update" umfasst drei verschiedene Funktionen: OS-seitige OTA-Updates, gesteuert durch die Systemupdate-Richtlinie, verwaltete App-Updates über Managed Google Play sowie Remote-Neustart als eigenständiger Gerätebefehl. Die Steuerung der OS-Update-Richtlinie erfordert den Fully Managed (Device Owner)-Modus – bei Work Profile-Geräten kann die MDM-Lösung keine Systemupdates kontrollieren.

Dieser Artikel behandelt die vier OS-Update-Richtlinientypen und wann welcher eingesetzt wird, wie sich App-Update-Richtlinien in Verhalten und Timing unterscheiden, die Enrollment-Entscheidung zwischen Device Owner und Work Profile, die Fehlersuche bei ausbleibenden Updates trotz bereitgestellter Richtlinie sowie die Überprüfung der Update-Compliance in Ihrer gesamten Flotte.

TL;DR

Was Android Remote Update für eine verwaltete Geräteflotte wirklich bedeutet

Ein Android Remote Update bezeichnet zwei separate Funktionen, die unterschiedlich konfiguriert werden und sich unterschiedlich verhalten. Die erste umfasst OS-/Firmware-Updates, die über die MDM-Systemupdate-Richtlinie bereitgestellt werden – diese steuert, wann Android-OTA-Updates vom OEM auf dem Gerät installiert werden. Die zweite sind App-Updates, die über die Update-Richtlinie von Managed Google Play verwaltet werden. Beide erfordern eine MDM- (oder EMM-)Plattform, die auf dem Gerät enrollt ist. Ohne Enrollment gibt es auf Standard-Android keine Remote-Update-Funktion. Custom-ROM-Ansätze existieren (verfügbar bei ausgewählten MDM-Anbietern), erfordern jedoch nicht standardmäßige Hardware und sind eine Nischenausnahme.

Das dritte Element ist der Remote-Neustart – ein eigenständiger Gerätebefehl, der von beiden Update-Richtlinientypen getrennt ist.

Eine wichtige Klarstellung zu dem, was Android MDM tatsächlich steuert: MDM-Systemupdate-Richtlinien verwalten ausschließlich OEM-OTA-Updates. Google Play System Updates – auch Project Mainline genannt – funktionieren unabhängig und werden nicht durch Ihre MDM-Update-Richtlinie gesteuert. Wenn Sie in den Geräteeinstellungen festgestellt haben, dass das Datum des Play System Updates wie aus dem Vorjahr aussah, ist das kein Zeichen dafür, dass Ihre MDM-Richtlinie versagt hat. Ab 2025 bestätigt Google, dass die angezeigten Datumsangaben von Play System Updates das letzte Mainline-Modul-Update widerspiegeln, nicht den OEM-Sicherheits-Patch-Level, den Ihre MDM-Lösung verwaltet.

Die vier Android-OS-Update-Richtlinientypen – und wann welcher eingesetzt wird

Alle vier Richtlinientypen werden über die MDM-Konsole konfiguriert und auf das Gerät übertragen. Zu verstehen, wie Android-Updates remote eingespielt werden, beginnt damit zu erkennen, dass diese Richtlinien nur auf Geräten wirksam werden, die im Fully Managed (Device Owner)-Modus enrollt sind. Geräte, die ein Android Work Profile verwenden – ob BYOD oder unternehmenseigen – können keine OS-Update-Richtlinien auf Systemebene erhalten. Dies ist eine Enrollment-Entscheidung, die vor der Bereitstellung getroffen werden muss, keine Einschränkung, die man erst danach entdeckt.

Automatisch

Die Automatisch-Richtlinie installiert ein OS-Update, sobald es vom OEM verfügbar ist. Dies ist die richtige Standardeinstellung für die meisten Unternehmensflotten, bei denen Patch-Verzögerungen ein Compliance-Risiko darstellen.

• Vorteil: Nach der Einrichtung kein Admin-Eingriff erforderlich
• Nachteil: Kein Testfenster vor der flottenweiten Bereitstellung – ein Update, das ein App-Kompatibilitätsproblem verursacht, erreicht alle Geräte schnell
• Hier zahlt sich Echtzeit-Compliance-Monitoring aus – es erkennt Update-bedingte Regressionen in der Flotte, bevor sie zu Support-Tickets werden
• Praktischer Hinweis: „Verfügbar" wird durch die Rollout-Warteschlange des OEMs definiert. Selbst bei aktiviertem Automatisch-Modus erhalten nicht alle Geräte das Update am gleichen Tag – der Rollout erfolgt gestaffelt durch den Hersteller

Wenn Sie Automatisch eingestellt haben und Ihre Geräte nicht aktualisieren, liegt die häufigste Ursache darin, dass diese Geräte im Work Profile-Modus und nicht im Fully Managed-Modus enrollt sind. Die Richtlinie erscheint im Dashboard als bereitgestellt, hat aber keinen Einfluss auf OS-Updates außerhalb des Device Owner-Modus.

Zeitfenster

Zeitfenster installiert Updates nur innerhalb eines definierten täglichen Zeitfensters – zum Beispiel von 2:00 bis 4:00 Uhr. Dies ist die richtige Wahl für betriebliche Geräte, die während der Geschäftszeiten nicht neu gestartet werden können.

• Am besten geeignet für: Kiosk-Tablets, POS-Terminals, Lagergeräte
• Vorteil: Update erfolgt automatisch nach Ihrem Zeitplan
• Nachteil: Wenn das Gerät während des Zeitfensters ausgeschaltet oder nicht verbunden ist, wird das Update in diesem Zyklus übersprungen und am nächsten Tag erneut versucht

Die größte praktische Hürde bei der Einrichtung von Zeitfenster-Richtlinien liegt nicht in der Konfiguration – sondern darin, eine Einigung mit dem Betriebs- oder Facility-Team darüber zu erzielen, welche Stunden tatsächlich sicher für einen Geräteneustart sind. Dieses Gespräch dauert in der Regel länger als das MDM-Setup.

Verschoben

Verschoben verzögert die OS-Update-Installation um 30 Tage ab dem Zeitpunkt, an dem das Update verfügbar wurde. Nach diesem Zeitfenster wird das Gerät zur Installation aufgefordert.

• Am besten geeignet für: Große Flotten, die vor dem flottenweiten Rollout ein Pilottestfenster benötigen
• Vorteil: Bietet einen Puffer, um das Update zunächst auf einer Teilmenge von Geräten zu validieren
• Nachteil: 30 Tage sind ein echtes Compliance-Risiko – CISAs Android-Patch-Direktive vom April 2025 gab Bundesbehörden Tage, nicht Wochen, um diese spezifische Schwachstelle zu beheben. Hochkritische CVEs haben zunehmend kurze Behebungsfristen, die eine 30-tägige Postponed-Richtlinie nicht erfüllen kann.

Wenn während Ihres 30-tägigen Postponed-Fensters eine Zero-Day-Schwachstelle auftaucht, haben Sie eine 30-tägige Exposition ohne automatisierten Schutz geschaffen. In HIPAA-pflichtigen Umgebungen, in denen Patches innerhalb von 30 Tagen nach Veröffentlichung erforderlich sind, lässt diese Richtlinie überhaupt keinen Spielraum.

Standard (Keine Richtlinie)

Ohne festgelegte Richtlinie kontrolliert MDM das Update nicht. Das Gerät folgt dem OEM- oder Carrier-Update-Verhalten – wann immer das auch stattfindet.

• Vorteil: Keine Konfiguration erforderlich
• Nachteil: Keine Transparenz, keine Kontrolle und kein Audit-Trail – für keine Compliance-Umgebung geeignet
• Am besten geeignet für: Selten akzeptabel; nur für unkritische Szenarien, in denen keine Patch-Compliance-Anforderung besteht

Nach den vier Richtlinientypen gibt es einen weiteren Mechanismus, den es zu kennen gilt: Einfrierperioden. Eine Einfrierperiode blockiert alle OTA-Updates für bis zu 90 Tage, wobei zwischen aufeinanderfolgenden Einfrierperioden mindestens 60 Tage liegen müssen. Verwenden Sie diese für geplante Betriebsunterbrechungen – Handelshochsaison, Produkteinführungen oder andere Zeitfenster, in denen ein Geräteneustart störend wäre. Sobald die Einfrierperiode endet, kombinieren Sie sie mit einer konformen Update-Richtlinie, um verpasste Patches nachzuholen. Quelle: Google Support, Android Enterprise Update-Management.

Wie Android-App-Update-Richtlinien funktionieren – und warum sie sich anders verhalten als OS-Updates

App-Update-Richtlinien unterscheiden sich in jeder relevanten Hinsicht von OS-Update-Richtlinien. Sie gelten speziell für Apps, die über Managed Google Play installiert werden – nicht für sidegeloadete APKs – und das Timing-Verhalten wird teilweise durch die Infrastruktur von Google gesteuert, nicht nur durch Ihre MDM-Konfiguration. Wenn Sie Android-Apps remote aktualisieren müssen, arbeiten Sie mit einem anderen Mechanismus als bei den oben beschriebenen OS-Update-Richtlinientypen.

Derselbe Managed Google Play-Kanal, den Sie zum remote Installieren von Android-Apps verwenden, ist auch der Kanal, der steuert, wie Updates bereitgestellt werden. Drei Richtlinienmodi stehen zur Verfügung:

• Standard: Das Gerät folgt dem Standard-Timing von Google Play – Hintergrund-Updates, wenn das Gerät mit WLAN verbunden und geladen ist
• Verschieben: Die App wird 90 Tage nach Veralterung nicht automatisch aktualisiert – nützlich, wenn eine neue Version vor dem flottenweiten Rollout durch die IT validiert werden muss
• Hohe Priorität: Die App wird aktualisiert, sobald die neue Version verfügbar ist – verwenden Sie diese für sicherheitskritische Apps oder nachdem eine bekannte Schwachstelle in einem neuen Release gepatcht wurde

Etwas, das Admins oft überrascht: MDM legt die Richtlinie fest, aber Google Play kontrolliert die Rollout-Warteschlange. Selbst bei konfigurierter Hoher Priorität verteilt Google Updates in Batches. Admins berichten, dass selbst bei konfigurierter Hoher Priorität ein erheblicher Teil der Geräte innerhalb der ersten 48 Stunden möglicherweise nicht aktualisiert wird – das ist das Batch-Rollout-Verhalten von Google Play, kein Konfigurationsfehler.

Managed Google Play prüft etwa einmal täglich auf Updates. Wenn Sie nach einem kritischen Patch eine schnellere Abdeckung benötigen, ist der praktische Ansatz, eine manuelle Play Store-Synchronisierung auf dem Gerät zu erzwingen oder ein manuelles APK-Update über Ihr MDM für Nicht-Play-Apps einzuspielen.

App-Update-Richtlinien gelten nur für Managed Google Play-Apps. Bei sidegeloadeten APKs ist der einzige Update-Pfad eine manuelle Neubereitstellung oder die Verwendung eines MDM, das eine stille Installation über Device Owner-Berechtigung unterstützt.

Zwei Punkte für Sonderfälle. Erstens: Wenn ein Update mit Hoher Priorität nach 24–48 Stunden nicht auf Geräten erscheint, überprüfen Sie, ob die App über Managed Google Play veröffentlicht wurde – sidegeloadete APKs unterliegen keinerlei Update-Richtlinien. Zweitens: Das Setzen einer App auf Verschieben (90 Tage) bedeutet, dass Ihre Flotte bei einer Sicherheitslücke in dieser App-Version den Patch bis zu drei Monate lang nicht erhält. Planen Sie einen manuellen Übersteuerungsprozess, bevor Sie ihn benötigen.

Device Owner vs. Work Profile – die Enrollment-Entscheidung, die alles verändert

OS-seitige Systemupdate-Richtlinien funktionieren nur auf Geräten im Fully Managed (Device Owner)-Modus. Das ist die wichtigste Tatsache in diesem Abschnitt, und sie ist es, die Organisationen mitten in der Bereitstellung überrascht, wenn sie feststellen, dass ihre sorgfältig konfigurierten Update-Richtlinien nichts bewirken.

Die beiden Enrollment-Modi funktionieren folgendermaßen:

• Fully Managed (Device Owner): MDM hat vollständige Kontrolle über das Gerät. Alle vier OS-Update-Richtlinientypen sind verfügbar. Das Gerät ist unternehmenseigen und ausschließlich für die Arbeit. Dies ist der Enrollment-Pfad, der vollständige Android-Geräteverwaltungs-Funktionen freischaltet, einschließlich Systemupdate-Richtlinie, Kiosk-Modus und vollständiges App-Management.
• Work Profile: MDM verwaltet einen separaten Work-Container auf einem persönlichen oder semi-persönlichen Gerät. Die private Seite bleibt unberührt. OS-Update-Richtlinien gelten nicht – das Gerät aktualisiert sich nach eigenem OEM- oder Benutzerplan außerhalb der MDM-Kontrolle.

Ein dokumentierter Fall aus der r/Intune-Community aus dem Jahr 2024 zeigte ein IT-Team, das seine gesamte Flotte von Corporate-Owned Work Profile auf Fully Managed migrierte, weil OS-Update-Kontrolle die benötigte Funktion war. Die Empfehlung aus diesem Thread war eindeutig: Wenn Ihre Organisation die Hardware besitzt und Update-Richtlinienkontrolle benötigt, enrollen Sie von Anfang an als Fully Managed.

Die erneute Enrollung von Work Profile auf Fully Managed erfordert einen Werksreset. Das bedingt eine vorab geplante Terminierung, Datensicherung der Nutzer und in der Regel die Genehmigung eines Vorgesetzten oder IT-Leiters – es ist keine einfache Konfigurationsänderung. Die einmaligen Migrationskosten sind real, aber die Rendite ist vollständige Update-Richtlinienkontrolle für die Zukunft. Planen Sie das Migrationsfenster sorgfältig, anstatt es als schnelle Lösung zu betrachten.

Warum Ihr Android Remote Update nicht installiert wird – und wie Sie das prüfen

Sie haben Ihre Update-Richtlinie festgelegt. Das MDM zeigt sie als bereitgestellt an. Aber ein Compliance-Audit – oder die MDM-Flottenansicht selbst – zeigt Geräte mit einem alten Sicherheits-Patch. MDM ist das Werkzeug, das Ihnen die Transparenz gibt, um genau dieses Problem zu erkennen, und der Mechanismus, um dagegen vorzugehen. Ohne es hätten Sie keine Richtlinie, keinen Audit-Trail und keine Remote-Aktion verfügbar.

Die häufigsten Grundursachen, in grober Häufigkeitsreihenfolge:

• Enrollment-Modus-Diskrepanz: Das Gerät befindet sich im Work Profile-Modus, nicht im Fully Managed-Modus. Die Richtlinie erscheint im Dashboard als angewendet, hat aber keinen Einfluss auf OS-Updates. Dies ist die häufigste Ursache in der Praxis.
• Gerät nicht im WLAN: Viele OEM-Update-Prozesse erfordern WLAN zum Herunterladen des Update-Pakets. Bei mobilen Daten kann das Update den Nutzer zur Bestätigung auffordern, anstatt automatisch zu installieren.
• Akkuladestand nicht erreicht: Einige OEM-Update-Prozesse laufen unterhalb eines Mindest-Akkustands nicht. Das Update wartet auf den nächsten geeigneten Zyklus, anstatt sichtbar zu scheitern.
• Aktive Einfrierperiode: Wenn eine Einfrierperiode konfiguriert ist, werden keine OTA-Updates installiert – einschließlich erwarteter. Überprüfen Sie Ihren Einfrierperioden-Kalender, bevor Sie weitere Fehlersuche betreiben.
• OEM-Batch-Rollout: Selbst bei Automatisch-Richtlinie hat der OEM das Update möglicherweise noch nicht für bestimmte Gerätemodelle freigegeben. Updates werden in Batches ausgerollt – nicht gleichzeitig für alle Geräte.
• Richtlinie nicht mit Gerät synchronisiert: Die Richtlinie ist serverseitig bereitgestellt, hat sich aber noch nicht mit dem Gerät synchronisiert. Erzwingen Sie eine Richtlinien-Synchronisierung über die MDM-Konsole, falls diese Option verfügbar ist.

Der Ground-Truth-Verifikationsschritt: Navigieren Sie auf dem Gerät selbst zu Einstellungen > Sicherheit und Datenschutz > Arbeitsstrategie-Info > Richtlinien, die Ihr Gerät betreffen. Dies bestätigt, ob die Update-Richtlinie tatsächlich auf Geräteebene angewendet wird. Das MDM-Dashboard kann „bereitgestellt" anzeigen, auch wenn die Richtlinie nicht wirksam ist – diese On-Device-Prüfung ist die definitive Bestätigung.

Zu verfolgen, welche Geräte den neuesten Patch angewendet haben und welche nicht, ist Teil dessen, was eine Remote Monitoring Management-Plattform neben der Update-Richtliniendurchsetzung übernimmt. Bei 75 im Jahr 2024 erfassten Zero-Day-Schwachstellen sind unerkannte Update-Fehler keine administrative Unannehmlichkeit – sie sind ein reales Expositionsfenster. Zu wissen, welche Geräte aktuell sind und welche nicht, ist keine Option.

So starten Sie ein Android-Gerät remote neu

Remote-Neustart ist ein separater Befehl von Update-Richtlinien – es ist eine eigenständige MDM-Aktion, kein Teil der Update-Richtlinienkonfiguration. Remote-Update und Remote-Neustart als zwei unterschiedliche Operationen zu verstehen, ist bei der Fehlersuche wichtig: Sie benötigen möglicherweise einen Neustart nach einer erzwungenen Richtlinien-Synchronisierung, nach einem manuellen App-Update oder wenn ein Gerät nicht auf normale Befehle reagiert.

Remote-Neustart ist für Android-Geräte in jedem Verwaltungsmodus verfügbar – Device Owner oder Work Profile – und ist daher nicht wie OS-Update-Richtlinien an den Enrollment-Modus gebunden. COPE-Geräte unterstützen auch die remote Work Profile-Entfernung als zusätzlichen Befehl. Suchen Sie in der Remote-Aktionen-Menü Ihrer MDM-Konsole nach „Neu starten" oder „Neustart" – die genaue Bezeichnung variiert je nach Plattform.

Wenn ein Remote-Neustart-Befehl nicht ausgeführt wird, bestätigen Sie, dass das Gerät eine aktive Netzwerkverbindung hat. Das MDM muss das Gerät erreichen können, um den Befehl zu übermitteln – ein offline oder ohne MDM-Verbindung befindliches Gerät wird ihn nicht empfangen.

Wie Trio MDM beim Android Remote Update Management hilft

Trio MDM unterstützt Android Enterprise über zwei Einrichtungspfade: Trio Managed Setup für die meisten Organisationen und Self-Managed Setup für Teams, die vollständige Konfigurationskontrolle benötigen. Beide verbinden sich über Googles EMM-System, die Integrationsschicht, die verwaltete Update-Richtlinien ermöglicht.

Für App-Updates unterstützt Trio MDM sowohl Automatische als auch Manuelle Bereitstellung. Der automatische Pfad konfiguriert Geräte zur App-Aktualisierung über Managed Google Play – denselben zugrunde liegenden Kanal, der das App-Update-Timing wie in diesem Artikel beschrieben steuert. Der manuelle Pfad ermöglicht es Ihnen, eine neue APK-Version direkt zur Bereitstellung hochzuladen, was die richtige Option für private Apps oder Szenarien ist, in denen Sie genau kontrollieren möchten, welche Version die Geräte erreicht.

Trio MDM unterstützt alle vier Android-Enrollment-Modi: Work Profile, Fully Managed, Device Owner (über USB) und Basic RMM (APK). Für Android Remote Update-Kontrolle auf OS-Ebene ist Fully Managed der relevante Pfad – und Trio MDM unterstützt ihn ab Android 8.0.

Auf der Compliance-Seite bietet Trio MDM Echtzeit-Compliance-Status pro Gerät, sofortige Identifikation fehlgeschlagener Kontrollen und kontinuierliches Monitoring durch Automated Control Testing. Individuelle Geräte-Compliance-Prozentzahlen werden in Echtzeit aktualisiert, und ein unternehmensweiter Benchmark-Score wird über die gesamte Flotte berechnet. Das ist die Transparenzschicht, die Ihnen zeigt, welche Geräte aktuell sind und welche nicht – ohne manuelles Prüfen.

Trio MDM deckt auch Windows, macOS, iOS, Linux und Android von einer einzigen Plattform ab. Für Teams, die gemischte Geräteflotten verwalten, bedeutet das eine konsistente Monitoring- und Richtliniendurchsetzungsschicht für jeden Endpunkt, nicht nur für Android. Für das umfassendere Android RMM-Bild – Remote Monitoring, das über Update-Richtlinien hinaus die gesamte Geräteflotte abdeckt – übernimmt Trio MDM das innerhalb derselben Plattform.

Starten Sie Ihre kostenlose Testversion, um zu sehen, wie Trio MDM Android-Enrollment und App-Update-Management für Ihre Flotte handhabt, oder buchen Sie eine Demo, um die Compliance-Monitoring-Funktionen gemeinsam mit dem Team zu durchleuchten.