Google hat bereits 2010 mit Android 2.2 mit dem Android Device Administrator (DA) API -Set Funktionen zur Verwaltung mobiler Geräte für Android eingeführt.

Im Jahr 2020 sehen wir, dass sich die Art und Weise, wie mobile Geräte in der Unternehmenslandschaft verwendet werden, im Laufe des Zeitraums dramatisch verändert hat.

Die Arbeit ist mobiler denn je, und mobile Geräte werden mehr als zuvor verwendet, um auf Unternehmensdaten zuzugreifen und die Arbeit unterwegs zu erledigen, und ziemlich oft wird dasselbe Gerät sowohl für private als auch für geschäftliche Zwecke verwendet.

Das Device Administrator (DA) API -Set konnte mit den Anforderungen dieser neuen mobilen Belegschaft nicht Schritt halten. Daher musste Google eine Lösung finden, um Android in den Unternehmensanwendungsfällen relevant zu halten.

Das Ergebnis, wie wir es heute alle kennen, ist Android Enterprise.

Im Jahr 2014 führte Google mit Android Lollipop (5.x) einen neuen Satz moderner Geräteverwaltungs-APIs ein . Wir haben die Einführung von zwei neuen Verwaltungsmodi gesehen

Android Enterprise, wie es damals eingeführt wurde, war als Android for Work bekannt und markierte die Device Administrator (DA).

Im Jahr 2017 kündigte Google offiziell seinen Plan an, dass nur Android Enterprise die Unterstützung für die Device Admin API in Zukunft einstellen wird .

Mit der Veröffentlichung von Android Pie (9) im August 2018 wurden mehrere Funktionalitäten der Device Admin (DA) API von Google als veraltet markiert, wobei die Device Admin (DA) API mit der Veröffentlichung von Android 10 im September 2019 vollständig eingestellt wurde.

Es wird jedoch empfohlen, auf Android Enterprise umzusteigen . Es ist wichtig zu beachten, dass Geräte, auf denen Android-Versionen bis Oreo (Android 8) ausgeführt werden und die derzeit über den alten Geräteadministratormodus verwaltet werden , weiterhin verwaltet werden und nicht betroffen sind .

Android war von Anfang an eine Open-Source-Plattform, was einer der Hauptgründe dafür ist, dass Android die bevorzugte Plattform für OEMs ist, die Mobilgeräte für den Massenmarkt herstellen.

Das von Google kommerziell gesponserte Android Open Source Project (AOSP) , das hauptsächlich unter der Apache-Lizenz lizenziert ist, ermöglicht es einem OEM, den Android-Quellcode zu nehmen und ihn weiter anzupassen, um sein eigenes mobiles Betriebssystem auf Basis von Android zu erstellen.

Sie fügen ihre eigenen Apps, Gerätetreiber, eine komprimierbare Benutzeroberfläche, einige benutzerdefinierte Funktionen und APIs (und ja, auch etwas Bloatware) über dem Standard-Android-Image hinzu und erstellen eine völlig neue Android-Variante (ROM-Build), die sie einfügen das Chassis (Gerät).

Die OEMs tun dies hauptsächlich, um die Endbenutzererfahrung zu kuratieren. Obwohl auf den Geräten verschiedener OEMs möglicherweise dieselbe Android-Version ausgeführt wird, unterscheiden sich das Erscheinungsbild (und einige Funktionen) aus diesem Grund, und daher erhalten wir Androiden mit unterschiedlichen Geschmacksrichtungen auf dem Markt.

Die Tatsache, dass Android eine Open-Source-Plattform ist, half Google dabei, einen beträchtlichen Anteil am Markt für mobile Betriebssysteme zu gewinnen, und derselbe Grund wurde versehentlich zum Achilles Hill für Google, wenn es um die Verwendung von Android in Unternehmensanwendungsfällen ging.

Verstehen des Problems mit der Geräteverwaltungs-API

Jede EMM-Plattform (Enterprise Mobility Management) ist auf APIs angewiesen, um mit verwalteten Geräten zu kommunizieren und diese zu steuern.

Android ermöglichte dies in den ersten Tagen mit der Device Admin (DA) API , jedoch wurde schnell klar, dass seine eingeschränkte Funktionalität den sich entwickelnden Anforderungen der modernen mobilen Belegschaft nicht gewachsen war.

Das Device Admin (DA) API -Set hatte viele Mängel sowohl in Bezug auf Benutzerfreundlichkeit als auch auf Sicherheit, die ausgeprägtesten davon sind unten aufgeführt.

Hinzu kommt, dass die inzwischen veraltete Device Admin API nie ein Standardbestandteil des ursprünglichen Android-Quellcodes war und in ihren Fähigkeiten sehr eingeschränkt war .

Daher hatten die OEMs bei der Vorbereitung ihres mobilen Betriebssystems, indem sie den Android-Quellcode von AOSP nahmen und ihn anpassten, die Möglichkeit, entweder die Geräteverwaltungs-APIs zu integrieren oder sie alle zusammen zugunsten ihrer eigenen benutzerdefinierten APIs wegzulassen, die sie entwickelt haben, um ihre eigenen Unternehmensfunktionen zu bilden .

Beispiel: Samsung mit ihrem KNOX , Zebra mit ihren Mx- Plattformkonfigurationen. In Anbetracht der schieren Anzahl von OEMs, die Android-Geräte herstellen, erfordert jede EMM-Lösung viel Aufwand, um mit allen OEMs zusammenzuarbeiten, um alle ihre benutzerdefinierten APIs nativ zu integrieren.

Dies ist weder praktikabel noch möglich, da die EMM-Lösungen jede Version der von OEMs entwickelten APIs warten und verwalten müssten, um die Abwärtskompatibilität aufrechtzuerhalten. Wenn sich ein EMM dagegen dafür entscheidet, die OEM-APIs nicht zu implementieren, ist die Unterstützung für die Verwaltung von Unternehmensfunktionen von Geräten dieses OEM verständlicherweise nicht verfügbar.

Warum ein EMM die Implementierung von APIs ablehnen kann, hängt von der Verfügbarkeit von Ressourcen, Budget- oder Zeitbeschränkungen, dem Fehlen einer OEM/EMM-Partnerschaft oder anderen Gründen ab.

In der realen Welt wurde jedoch tatsächlich festgestellt, dass Geräte von verschiedenen OEMs und manchmal von verschiedenen Gerätemodellen desselben OEMs (wenn überhaupt) unterschiedliche Ergebnisse zeigten, wenn sie versuchten, eine bestimmte Funktion von einer EMM-Lösung aus zu verwalten.

Dies führte zu dem berüchtigten „Alles-oder-Nichts“ -Verwaltungsansatz mit der Geräteverwaltungs – API , der zu einer inkonsistenten Verwaltbarkeit und damit zu einem geringen Vertrauen der IT-Administratoren führte.

Wie hat Google das Problem eigentlich gelöst?

Die direkte Antwort wäre die Einführung von Android Enterprise .

Android Enterprise ist Googles modernes Android-Geräteverwaltungs-Framework , das eingeführt wurde, um die Mängel der Geräteverwaltungs-API zu überwinden und Android zu einer geeigneten Plattform für Anwendungsfälle in Unternehmen zu machen.

Android Enterprise , wie wir es heute kennen, debütierte ursprünglich unter dem Namen Android for Work mit Android Lollipop (5.x) . Aber zum Zeitpunkt seiner Veröffentlichung war es noch eine optionale Lösung, die OEMs zur Integration in ihre Geräte zur Verfügung gestellt wurde.

Dies änderte sich jedoch bald.

Mit Android Marshmallow (6.0) hat Google Android Enterprise zur obligatorischen Komponente für alle GMS-zertifizierten Geräte gemacht .

Dadurch wurde sichergestellt, dass selbst wenn Ihre Palette von Android-Geräten aus Geräten verschiedener OEMs besteht und alle Geräte GMS-zertifiziert sind, sie immer noch die gleiche Verwaltbarkeit und Endbenutzererfahrung bieten.

Lernen Sie Android Enterprise kennen

Android Enterprise ist eine Reihe robuster Verwaltungs-APIs, die es EMM-Lösungen ermöglichen, Android-Geräte sicher für den Einsatz in Unternehmen bereitzustellen und zu verwalten.

Android Enterprise ist eine Reihe moderner Verwaltungs-APIs, die für die Unternehmensanwendungsfälle ausreichen, um von allen OEMs in ihre Android-Builds integriert zu werden, und wird somit zur einzigen Reihe von APIs, die eine EMM-Lösung unabhängig davon für eine effektive und effiziente Android-Verwaltung implementieren muss dem Geräte-OEM, wodurch eine konsistente Verwaltbarkeit über OEMs hinweg erreicht wird.

Android Enterprise unterstützt mehrere Anwendungsfälle, wie unten gezeigt

Einfache und sichere App-Bereitstellung

Managed Google Play bietet IT-Administratoren eine standardmäßige und sichere Möglichkeit, Apps für eine einfache Bereitstellung auf die Whitelist zu setzen, private Apps zu verteilen und unbeaufsichtigte App-Installationen durchzuführen, ohne dass die Installation von Apps aus unbekannten Quellen aktiviert werden muss .

Die Play Protect – Lösungssuite von Google hilft dabei, Geräte vor potenziell schädlichen Anwendungen (PHA) zu schützen

Garantierte Sicherheitsupdates

Google veröffentlicht monatliche Sicherheitsupdates, um Schwachstellen und Exploits in Android zu patchen. Abgesehen von Pixel-Geräten müssen jedoch fast alle anderen Android-Geräte warten, um die Sicherheitsupdates zu erhalten, sobald sie von OEMs bereitgestellt werden.

Mit der Einführung des Android Enterprise Recommended – Programms müssen Geräte, die unter das Programm fallen , die Updates innerhalb von 90 Tagen nach der Veröffentlichung von Google erhalten . Das Android One – Programm ist eine weitere Ergänzung, indem es Sicherheitsupdates innerhalb von 30 Tagen nach der Veröffentlichung von Google vorschreibt .

Obwohl Android Enterprise jetzt die einzige empfohlene und moderne Methode zur Verwaltung von Android-Geräten in Ihrer Unternehmensumgebung ist, müssen Sie sich darüber im Klaren sein, dass Android Enterprise offiziell nur auf GMS-zertifizierten Geräten unterstützt wird .

Was ist GMS?

Während Android selbst ein Open-Source-Projekt ist, enthält das mobile Gerät, das in die Hände der Benutzer gelangt, einige proprietäre Teile, insbesondere Apps und Dienstpakete von Google, die zusammen als Google Mobile Services (GMS) bekannt sind .

Das Paket ist von Region zu Region unterschiedlich, enthält jedoch normalerweise Folgendes

Zusätzlich zu den oben genannten proprietären Google-Apps beinhaltet GMS auch den wichtigen Zugang zur Nutzung von Google Play-Diensten und den entsprechenden Google-APIs (SafetyNet, Play Protect, Play EMM usw.).

Google hat GMS so auf dem Android Open Source Project (AOSP) aufgebaut.

Wo Ersteres kostenlos ist und es jedem ermöglicht, den Android-Quellcode zu nehmen und damit sein eigenes benutzerdefiniertes ROM zu erstellen, das auf einem Gerät ausgeführt werden kann (hauptsächlich durch die Apache-Lizenz erleichtert), erfordert Letzteres einen OEM, um eine GMS-Lizenz, auch bekannt als The, zu erhalten Mobile Application Distribution Agreement (MADA) von Google, um Google-Apps und -Dienste auf ihren Geräten vorzuinstallieren.

Den Unterschied zwischen einer GMS-Lizenz und einer GMS-Zertifizierung verstehen

Eine MADA-Lizenz berechtigt einen OEM, die proprietären Apps und Dienste von Google auf seinen Geräten einzuschließen und zu verwenden, bedeutet jedoch nicht unbedingt, dass jedes von ihm hergestellte/zu produzierende Gerätemodell GMS-zertifiziert ist/sein wird.

Um eine GMS-Zertifizierung zu erhalten, muss das Gerät mehrere von Google entwickelte Kompatibilitätstests und -prozesse durchlaufen , um sicherzustellen, dass es die Leistungsanforderungen von Google erfüllt und Google-Apps und -Dienste ordnungsgemäß ausführen und verwenden kann.

Was ist mit Geräten, die nicht GMS-zertifiziert sind?

Nicht GMS-zertifizierte Geräte müssen leider mit der veralteten und veralteten Device Admin API verwaltet werden, vorausgesetzt, sie führen eine unterstützte Android-Version (bis zu Android Oreo) aus.

Für nicht GMS-zertifizierte Geräte, auf denen AOSP-Builds für Android-Version 10 oder höher ausgeführt werden, können sie leider nicht mit der Geräteverwaltung verwaltet werden, da das Kern-Android-Betriebssystem auf diesen Versionen nicht über die Geräteverwaltungs-API verfügt.

Ein neueres Beispiel, auf das Sie sich vielleicht alle beziehen, wäre der Fall von Huawei .

Inoffiziell ermöglichen nicht GMS-zertifizierte moderne Android-Geräte eine eingeschränkte Android Enterprise-Verwaltungserfahrung mit einem EMM, das geschlossene Netzwerk- oder Nicht-GMS-Verwaltung wie VMWare Workspace One unterstützt.

Microsoft Intune (auch bekannt als Microsoft Endpoint Manager) bietet keine Unterstützung für die Android-Verwaltung von Closed Network AOSP.

Die Empfehlung eines Android-Geräts für Unternehmensanwendungen war vor einigen Jahren eine schwierige Aufgabe, aber die Szenarien haben sich jetzt mit Android Enterprise zum Besseren verändert, das eine zuverlässige, konsistente Verwaltbarkeit und Benutzererfahrung über OEMs hinweg garantiert.

Darüber hinaus hat Google versucht, Unternehmenskunden durch die Einführung von Programmen wie Android Enterprise Recommend (AER) zu helfen .

Was wird für Android Enterprise empfohlen? Wie profitieren Unternehmenskunden davon?

Um Käufern in Unternehmen zu helfen, sicher Android-Geräte für ihre Anwendungsfälle auszuwählen, was möglich ist

Google hat bereits 2018 das Programm Android Enterprise Recommended (AER) entwickelt.

m als Android Enterprise Recommended (AER) -Gerät aufgeführt zu werden, muss ein Gerät zusätzlich zu den GMS-Zertifizierungsanforderungen eine zusätzliche Reihe gründlicher Tests nach den von Google festgelegten Best Practices und allgemeinen Anforderungen durchlaufen.

Nachfolgend sind einige der wesentlichen Anforderungen aufgeführt, die das Gerät erfüllen muss, um als AER-Gerät aufgeführt zu werden.

Vor Android 10 benötigte Google ein AER-Gerät, um Sicherheitspatches innerhalb von 90 Tagen nach der Veröffentlichung von Google für einen Zeitraum von 3 Jahren zu garantieren. Mit Android 11 hat Google diese Anforderung jedoch aufgehoben, indem es stattdessen den OEM beauftragt, Informationen zu Sicherheitsupdates auf seiner Website zu veröffentlichen und den Zeitraum, in dem ein Gerät garantiert Sicherheitsupdates erhält.

 

Wenn sich ein Unternehmen für den Kauf von Android Enterprise Recommended – Geräten entscheidet, kann es sicher sein, dass die Geräte getestet wurden, um die Unternehmenskriterien von Google zu erfüllen, und als solche eine nahtlose und konsistente Erfahrung und Verwaltbarkeit über OEMs hinweg aufweisen, zusammen mit der Gewissheit, dass die Geräte dies tun werden vom OEM für den angegebenen Zeitraum unterstützt und gepatcht werden, wodurch die Sicherheitsbedenken während des gesamten Gerätelebenszyklus berücksichtigt werden.

Weitere Verbesserungen im Android-Management mit OEMConfig

Google hat immer klargestellt, dass Android Enterprise nur ein Basissatz von APIs ist, die es im Laufe des Jahres weiterentwickeln und neue APIs hinzufügen wird, während das Betriebssystem weiter reift und die weiteren kommenden neuen Anforderungen erfüllt.

Dies gibt den OEMs die Möglichkeit, ihren Geräten einen weiteren Mehrwert zu verleihen, indem sie ihre eigenen APIs erstellen, um bestimmte neue Funktionen über Android Enterprise hinaus anzusprechen und zu verwalten.

Aber bringt uns das nicht wieder zum Anfang zurück? Die EMM-Lösungen müssten wiederum mit den OEMs zusammenarbeiten, um diese OEM-spezifischen benutzerdefinierten APIs zu integrieren, um die Funktionen nutzen zu können.

Nein . Und hier kommt OEMConfig ins Spiel .

OEMConfig ist ein von Google definierter Standard, der es einer EMM-Lösung ermöglicht, OEM-spezifische APIs zu verwalten, die über und über Android Enterprise aufgebaut sind, ohne dass diese OEM-spezifischen APIs nativ in EMM integriert werden müssen, aber dennoch in der Lage sind, diese OEM-spezifischen Funktionen von Ihrem aus zu verwalten EMM aufgrund der Verwendung von Konfigurationen, die App-Konfigurationsprofilen ähneln, um Geräteeinstellungen zu konfigurieren und an eine vom OEM entwickelte Anwendung zu liefern, die auf dem Gerät vorhanden ist (von der EMM-Lösung mithilfe von Managed Play gepusht), die als Schnittstelle zwischen dem EMM und den OEM-spezifischen APIs fungiert und angewendet wird /erzwingt die gelieferten Einstellungen auf dem Gerät.Jeder OEM hat seine eigene OEMConfig-App, die im Google Play Store verfügbar ist und als Schnittstelle zwischen der EMM-Lösung und den OEM-spezifischen APIs auf dem Gerät fungiert, und benötigt daher keine EMM-Lösung, um dies zu unterstützen.

Die Verantwortung liegt bei den OEMs, die ihre OEMConfig-App entwickeln und verfügbar machen und über Konfigurationsreferenzdokumente verfügen müssen, damit die IT-Administratoren App-Konfigurationsprofile aus der EMM-Lösung erstellen können.

OEMConfig ist eine unglaublich leistungsstarke Lösung, die es einem IT-Administrator ermöglicht, neue Gerätefunktionen vom ersten Tag an zu verwalten (hängt wiederum vom OEM ab, ob er seine OEMConfig-App zusammen mit der neuen Version aktualisiert hat), ohne dass eine komplexe Entwicklung von der EMM-Seite erforderlich ist.
Tagged , , , ,