Managed Configurations unter Android: Apps für Mitarbeiter einrichten, bevor sie geöffnet werden

Ein typisches Support-Ticket am ersten Tag sieht so aus. Ein Mitarbeiter öffnet die Firmen-App, die App fragt nach einer Serveradresse, und niemand in der Halle kennt sie. Jemand aus der IT tippt dann dieselbe URL, denselben Kontonamen oder dieselbe Einstellung auf jedem Gerät ein, und früher oder später passiert auf einem davon ein Tippfehler.

Android Enterprise bietet einen Standardweg, um dies zu vermeiden: sogenannte Managed Configurations. Sie legen die Werte einer App einmalig in Ihrer MDM-Richtlinie fest. Sie erreichen jedes Gerät, das von dieser Richtlinie abgedeckt wird, und die App liest sie beim Start aus. Wenn eine Arbeitskraft Chrome, den Mail-Client, eine Scanner-App oder Ihre eigene Business-App öffnet, weiß die App bereits, wohin sie sich verbinden soll und was erlaubt ist.

Dieses Tutorial deckt beide Seiten der Einrichtung ab. Sie erfahren, wie Sie Managed Configurations für gängige Apps im Richtlinien-Editor Ihres MDMs finden und anwenden. Zudem erfahren Sie, was Sie von Ihren internen Entwicklern anfordern sollten, damit Ihre eigenen APKs denselben Mechanismus unterstützen.

Was eine Managed Configuration ist und wer die Felder definiert

Eine Managed Configuration ist eine Sammlung von Schlüssel-Wert-Einstellungen, die ein Unternehmen an eine App auf einem verwalteten Android-Gerät überträgt. Die Android Enterprise-Dokumentation von Google beschreibt die Kette wie folgt:

1. Der App-Entwickler definiert das Schema. In der Datei res/xml/app_restrictions.xml der App deklariert der Entwickler jede Einstellung, die die App akzeptiert: ihren Schlüssel, ihren Typ (String, Boolean, Integer, Choice, Multi-Select, Bundle usw.), einen Titel und einen Standardwert.
2. Google Play veröffentlicht das Schema. Wenn die App zu Google Play hochgeladen wird, liest Play diese Datei aus. Managed Google Play kann die Felder dann in EMM-Konsolen als Formular anzeigen.
3. Ihr MDM sendet die Werte. Über die Android Management API überträgt der Eintrag der App in einer Geräterichtlinie die von Ihnen gewählten Werte.
4. Die App liest sie aus. Auf dem Gerät ruft die App RestrictionsManager.getApplicationRestrictions() auf und wendet die gefundenen Werte an.

Der App-Entwickler bestimmt also, welche Felder existieren, nicht Ihr MDM. Wenn der Entwickler keinen Schlüssel für eine „Server-URL“ veröffentlicht hat, kann keine Konsole die Server-URL vorkonfigurieren. Die Konsole kann nur Felder ausfüllen, die der Entwickler bereitgestellt hat.

Hinweis: Managed Configurations sind von Geräterichtlinien getrennt. Eine Geräterichtlinie steuert Android selbst, beispielsweise die Kamera, USB oder WLAN. Eine Managed Configuration steuert Einstellungen innerhalb einer bestimmten App. In der Regel benötigen Sie beides.

Bevor Sie beginnen

• Geräte sind in Ihrem MDM mit Android Enterprise registriert (vollständig verwaltet oder Arbeitsprofil).
• Die Apps, die Sie konfigurieren möchten, sind in Managed Google Play freigegeben oder sind private Apps, die Ihre Entwickler dort veröffentlicht haben.
• Sie verfügen über ein Testgerät, das unter einer Testrichtlinie und nicht unter Ihrer Produktionsrichtlinie registriert ist.
• Sie kennen die Werte, die Sie übertragen möchten, wie z. B. Server-Hostnamen, zulässige URLs und Kontoformate.

Schritt 1: Prüfen, ob die App Managed Configurations unterstützt

Bevor Sie mit der Planung beginnen, vergewissern Sie sich, dass die App ein Schema veröffentlicht. Sie können dies an drei Stellen überprüfen:

1. Der Richtlinien-Editor Ihres MDMs. Fügen Sie die App zu einer Testrichtlinie hinzu und prüfen Sie, ob ein Konfigurationsformular angezeigt wird. Wenn ja, hat der Entwickler ein Schema veröffentlicht.
2. Die Enterprise-Dokumentation des Anbieters. Viele Anbieter veröffentlichen ihre Schlüssel. Google listet beispielsweise die Enterprise-Richtlinien von Chrome samt Plattformunterstützung für jede einzelne unter chromeenterprise.google/policies auf.
3. Das Support-Team des Anbieters. Fragen Sie nach: „Unterstützt Ihre Android-App Android Enterprise Managed Configurations und welche Schlüssel werden bereitgestellt?“

Notieren Sie jeden benötigten Schlüssel und seinen Typ. Zu den Schematypen gehören string, bool, integer, choice, multi-select, hidden, bundle und bundle_array. Ein bool-Feld erwartet true oder false, nicht den Text "true", und ein multi-select-Feld erwartet Werte aus einer festen Liste.

Erwartetes Ergebnis: Sie wissen für jede App, ob sie Managed Configuration unterstützt und welche Felder Sie konfigurieren werden.

Warnung: Wenn eine App kein Schema besitzt, gibt es innerhalb des Managed-Configuration-Systems keinen Workaround. Ihre Optionen bestehen darin, den Anbieter um die Implementierung eines Schemas zu bitten, zu einer anderen App zu wechseln oder einen dokumentierten manuellen Einrichtungsschritt für diese App beizubehalten.

Schritt 2: Die App zur Richtlinie hinzufügen und ihre Konfiguration öffnen

1. Öffnen Sie die Richtlinie, die für die Zielgeräte gilt. Verwenden Sie zunächst Ihre Testrichtlinie.
2. Fügen Sie die App aus Managed Google Play hinzu, falls sie nicht bereits in der Richtlinie enthalten ist.
3. Öffnen Sie das Konfigurationsformular der App.

In Nomid MDM öffnet die App-Karte im Richtlinien-Editor die verwaltete Konfiguration der App. Das sind die Einstellungen, die der Entwickler über Google Play veröffentlicht, angezeigt als Felder zum Ausfüllen. Nomids eigene Android-Apps lesen ihre Einstellungen auf dieselbe Weise.

Erwartetes Ergebnis: Sie sehen ein Formular, dessen Felder mit den in Schritt 1 notierten Schlüsseln übereinstimmen.

Hinweis: Google Play liest das Schema aus der hochgeladenen App, daher erscheint das Formular für Apps, die über Managed Google Play verteilt werden, öffentliche wie private. In Nomid zeigen auch private Apps im Nomid Store ein Konfigurationsformular, wenn die hochgeladene App ein Schema deklariert. Bei jedem anderen Verteilungsweg prüfen Sie, wie die Konfiguration funktioniert, bevor Sie sich darauf verlassen.

Schritt 3: Konfiguration für gängige Apps ausfüllen

Lesen Sie die Schritte 4 und 5, bevor Sie Werte eintragen. Legen Sie fest, welche Werte für alle Geräte der Richtlinie gleich sind und welche sich je Standort oder Gerät unterscheiden, damit Sie die Formulare später nicht neu aufbauen müssen.

Nachfolgend finden Sie die drei Muster, die die meisten Geräteflotten benötigen. Da die Feldnamen von Anbieter zu Anbieter variieren, sollten Sie die Schlüssel als Beispiele betrachten und sie mit dem Formular der jeweiligen App abgleichen.

3a. Browser: Startseite und URL-Listen (Chrome)

Chrome unter Android akzeptiert viele der Enterprise-Richtlinien von Desktop-Chrome, die als Managed Configuration bereitgestellt werden. Zu den Richtlinien, die häufig auf Arbeitsgeräten verwendet werden, gehören:

Bevor Sie sich auf eine Richtlinie verlassen, prüfen Sie die Liste der Chrome Enterprise-Richtlinien, um sicherzustellen, dass sie unter Android unterstützt wird. Einige Desktop-Richtlinien, insbesondere bezüglich Start- und Startseitenverhalten, verhalten sich anders oder sind unter Android nicht verfügbar. Wenn Sie einen festen Startbildschirm benötigen, sind verwaltete Lesezeichen (Managed Bookmarks) oder ein Web-Link in einem Kiosk-Launcher oft verlässlicher. Wenn Sie mit URLBlocklist ["*"] alles sperren, nehmen Sie auch die Anmeldeseiten Ihres Identitätsanbieters in URLAllowlist auf, sonst laden Arbeitsseiten mit Anmeldung nicht.

3b. Mail-Client: Server und Konto

Enterprise-Mail-Apps stellen typischerweise Felder wie die folgenden bereit:

• E-Mail-Adresse oder Benutzername
• Server-Hostname (z. B. ein Exchange ActiveSync-Host)
• SSL/TLS-Anforderung
• Ob private Konten hinzugefügt werden können

Benutzerspezifische Werte wie die E-Mail-Adresse werden in Schritt 5 behandelt. Füllen Sie vorerst die Felder aus, die für alle identisch sind, wie z. B. den Server-Host und die Sicherheitsoptionen.

3c. Scanner- und Line-of-Business-Apps: Server-URL und Verhalten

Dienstprogramme für robuste Geräte, Scan-Apps und Unternehmensanwendungen stellen in der Regel Folgendes bereit:

• Backend- oder API-Basis-URL, beispielsweise https://wms.example.com/api
• Mandanten-, Standort- oder Lager-Code
• Funktionsschalter, wie Offlinemodus, Kamerascan im Vergleich zu Hardware-Scannern oder das Deaktivieren von Debug-Logging

Speichern Sie die Richtlinie. Stellen Sie dann sicher, dass Ihr Testgerät ihr zugewiesen ist. Erwartetes Ergebnis: Das Formular jeder App enthält die gemeinsamen Werte dieser Richtlinie, die Richtlinie ist gespeichert und das Testgerät verwendet sie.

Warnung: Vermeiden Sie es, Passwörter oder langlebige Geheimnisse in Managed Configurations zu hinterlegen. Die Werte werden auf dem Gerät gespeichert und sind für die App lesbar. Bevorzugen Sie Abläufe, bei denen die Konfiguration die App auf den richtigen Server verweist und sich die Arbeitskraft oder die App anschließend authentifiziert.

Schritt 4: Einmal pro Richtlinie festlegen

Managed Configurations gehören zur Richtlinie, nicht zu einem einzelnen Gerät. Jedes Gerät unter dieser Richtlinie erhält dieselben Werte. Nutzen Sie dies zu Ihrem Vorteil:

1. Gruppieren Sie Geräte nach den Unterschieden. Wenn Filiale A und Filiale B unterschiedliche Backend-URLs verwenden, benötigen sie unterschiedliche Konfigurationen. Organisieren Sie Ihre Richtlinien oder Richtliniengruppen anhand dieser Unterschiede.
2. Verwenden Sie eine bewährte Baseline wieder. Erstellen Sie eine vollständig konfigurierte Richtlinie und nutzen Sie diese als Ausgangspunkt für neue Standorte, damit Sie die Konfiguration nicht manuell neu erstellen müssen. In Nomid dienen Richtlinienvorlagen und Richtliniengruppen diesem Zweck.
3. Einmal ändern, überall ausrollen. Wenn sich die Server-URL ändert, bearbeiten Sie sie in der Richtlinie. Die Geräte übernehmen den neuen Wert bei der nächsten Richtliniensynchronisierung.

Erwartetes Ergebnis: Jeder eindeutige Satz von Werten wird genau einer Richtlinie oder Richtliniengruppe zugeordnet, und nichts wird pro Gerät manuell konfiguriert.

Schritt 5: Gerätespezifische Werte verwalten

Einige Werte unterscheiden sich auf jedem Gerät: die E-Mail-Adresse eines Benutzers, ein Gerätename, ein Asset-Tag oder eine Seriennummer, die Ihre App für die Lizenzierung benötigt. Seit Android 10 können herkömmliche Apps die Hardware-Seriennummer nicht mehr selbst auslesen; die Übergabe über eine Managed Configuration ist daher ein gängiges Muster.

Es gibt zwei grundlegende Ansätze:

• Variablen. Die Android Management API ermöglicht es einer Konsole, Konfigurationsvariablen an eine Managed-Configuration-Vorlage anzuhängen. Eine Vorlage kann dann auf jedem Gerät zu unterschiedlichen Werten aufgelöst werden. Wie eine Konsole dies bereitstellt und welche Variablen sie anbietet, unterscheidet sich von Produkt zu Produkt. Klären Sie mit Ihrem Anbieter ab, welche Geräte- oder Benutzerattribute eingefügt werden können, bevor Sie Ihr Konzept darauf aufbauen.
• Kleinere Richtlinienbereiche. Wenn der gerätespezifische Wert eigentlich einem Standort oder einem Team zugeordnet ist, weisen Sie dieser Gruppe eine eigene Richtlinie zu. Bei einer Handvoll Geräten ist dies einfach. Bei Hunderten von Geräten skaliert dies nicht, was ein Zeichen dafür ist, dass Sie Variablen oder eine Anpassung in der App benötigen.

Eine dritte Option liegt auf Seiten der App. Die App kann einen gemeinsamen Wert wie eine Mandanten-ID aus der Konfiguration übernehmen und anschließend nach dem Login gerätespezifische Einstellungen aus ihrem eigenen Backend abrufen. Dies erweist sich oft als stabiler, als jedes gerätespezifische Detail über das MDM zu verteilen.

Erwartetes Ergebnis: Sie haben für jedes Feld entschieden, ob der Wert geteilt (auf Richtlinienebene), variabel (pro Gerät aufgelöst) oder von der App nach dem Login abgerufen wird.

Schritt 6: Überprüfen, ob die App die Änderung übernommen hat

1. Bestätigen Sie, dass das Gerät die Richtlinie empfangen hat. Überprüfen Sie den Status „Zuletzt gesehen“ oder den Synchronisierungsstatus in Ihrer Konsole. In Nomid zeigt die Asset-Liste den Zuletzt-gesehen- und Kontaktstatus an.
2. Prüfen Sie, ob die App installiert ist. Eine Konfiguration, die vor Abschluss der Installation gesendet wird, greift, sobald die App vorhanden ist, aber die App muss tatsächlich installiert sein. Prüfen Sie die App-Liste des Geräts in Ihrer Konsole oder auf dem Gerät selbst.
3. Beenden Sie die App erzwungen und öffnen Sie sie erneut. Viele Apps lesen ihre Konfiguration nur beim Start. Beenden Sie die App über ihre Seite in den Einstellungen. Sperrt die Richtlinie die Einstellungen, etwa im Kiosk, starten Sie das Gerät neu, was auch aus der Ferne geht.
4. Prüfen Sie innerhalb der App. Das Serverfeld sollte vorausgefüllt und gesperrt sein, die blockierte Website sollte blockiert sein usw. Ein Remote-Screenshot ermöglicht Ihnen die Überprüfung, ohne das Gerät in die Hand nehmen zu müssen.

Erwartetes Ergebnis: Auf dem Testgerät zeigt jede konfigurierte App die übertragenen Werte ohne manuelle Eingabe. Rollen Sie dann schrittweise aus: Notieren Sie die aktuellen Werte für einen Rückweg, übernehmen Sie die getesteten Werte in die Produktionsrichtlinie, wenden Sie sie zuerst auf eine kleine Pilotgruppe an und erweitern Sie, sobald die Pilotgeräte die richtigen Werte zeigen.

Hinweis: Wenn die App nach dem erzwungenen Beenden weiterhin alte Werte anzeigt, lesen Sie die nachfolgenden FAQ zur Fehlerbehebung. Die Ursache liegt in der Regel darin, wie die App die Konfiguration verarbeitet, nicht in der Übertragung.

Für interne Apps: Fordern Sie Ihre Entwickler auf, ein Schema zu veröffentlichen

Wenn Ihre eigene App Mitarbeiter immer noch dazu auffordert, eine Server-URL einzugeben, liegt die Lösung im Code der App. Sie können das folgende Briefing an Ihr Entwicklungsteam weiterleiten.

1. Schema deklarieren

Erstellen Sie res/xml/app_restrictions.xml:

<?xml version="1.0" encoding="utf-8"?>
<restrictions xmlns:android="http://schemas.android.com/apk/res/android">
    <restriction
        android:key="server_url"
        android:title="@string/cfg_server_url_title"
        android:description="@string/cfg_server_url_desc"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="site_code"
        android:title="@string/cfg_site_code_title"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="allow_offline"
        android:title="@string/cfg_offline_title"
        android:restrictionType="bool"
        android:defaultValue="false" />
</restrictions>

2. Im Manifest referenzieren

<application ...>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/app_restrictions" />
</application>

3. Werte auslesen und auf Änderungen reagieren

class MainActivity : AppCompatActivity() {
    private val configReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) = applyConfig()
    }

    override fun onResume() {
        super.onResume()
        applyConfig() // picks up changes made while the app was in the background
        registerReceiver(
            configReceiver,
            IntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED)
        )
    }

    override fun onPause() {
        unregisterReceiver(configReceiver)
        super.onPause()
    }

    private fun applyConfig() {
        val rm = getSystemService(Context.RESTRICTIONS_SERVICE) as RestrictionsManager
        val config = rm.applicationRestrictions
        val serverUrl = config.getString("server_url", "")
        val allowOffline = config.getBoolean("allow_offline", false)
        // Apply serverUrl and allowOffline to the app's settings here
    }
}

Der Broadcast ACTION_APPLICATION_RESTRICTIONS_CHANGED wird nur an Receiver zugestellt, die zur Laufzeit registriert wurden. Die App sollte die Konfiguration außerdem in onResume() erneut auslesen, damit Änderungen wirksam werden, die vorgenommen wurden, während sie sich im Hintergrund befand.

4. Über Managed Google Play veröffentlichen

Laden Sie die App zu Google Play hoch – als private App für Ihr Unternehmen, falls sie nicht öffentlich ist –, damit Play das Schema auslesen und das Formular Ihrem MDM anzeigen kann. Jedes neue Release, das einen Schlüssel hinzufügt oder umbenennt, erfordert einen erneuten Upload.

Checkliste für Entwickler

• Schlüssel stabil halten. Das Umbenennen von server_url beschädigt jede Richtlinie, die diesen Schlüssel setzt.
• Ein Feld in der Benutzeroberfläche ausblenden, wenn es durch eine Konfiguration festgelegt wurde, damit Mitarbeiter es nicht überschreiben können.
• Fehlertolerant reagieren, wenn ein Schlüssel leer ist, beispielsweise durch die Anzeige einer verständlichen Meldung wie „Bitte IT kontaktieren“.
• Niemals ein Geheimnis in der Konfiguration voraussetzen. Nutzen Sie sie, um den Server zu finden, und führen Sie anschließend eine ordnungsgemäße Authentifizierung durch.
• Testen Sie mit Googles TestDPC-App auf einem Gerät, das nicht in Ihrem MDM registriert ist. TestDPC muss die Verwaltungs-App des Geräts sein und läuft daher nicht auf einem Gerät, das Ihr MDM bereits verwaltet.

FAQ zur Fehlerbehebung

Die App hat kein Konfigurationsformular in meinem Richtlinien-Editor.

Der Entwickler hat kein Schema über Google Play veröffentlicht, oder die Version auf Play stammt aus der Zeit davor. Prüfen Sie die Dokumentation des Anbieters oder fragen Sie direkt nach. Vergewissern Sie sich bei internen Apps, dass der meta-data-Eintrag im Manifest vorhanden ist und dass der Build mit dem Schema hochgeladen wurde. Ein in einer neuen Version hinzugefügter Schlüssel erscheint erst im Formular, nachdem diese Version zu Google Play hochgeladen und verarbeitet wurde.

Ich habe einen Wert geändert, aber die App zeigt immer noch den alten an.

Gehen Sie diese Schritte der Reihe nach durch:

1. Hat das Gerät die aktualisierte Richtlinie synchronisiert? Prüfen Sie den Zuletzt-gesehen-Status.
2. Beenden Sie die App erzwingend und öffnen Sie sie erneut. Wenn der neue Wert nun erscheint, liest die App die Konfiguration nur beim Start aus und reagiert nicht auf den Broadcast für Änderungen.
3. Erscheint er immer noch nicht, hat die App den alten Wert womöglich in ihrem eigenen Speicher abgelegt. Das Löschen der App-Daten behebt das, entfernt aber alles, was nur auf dem Gerät liegt, etwa noch nicht synchronisierte Offline-Scans. Synchronisieren Sie also vorher. Andernfalls muss der Entwickler die App korrigieren.

Der Wert kommt an, aber die App ignoriert ihn.

Prüfen Sie, ob Schlüsselname und Typ exakt mit dem Schema übereinstimmen. Bei Schlüsseln wird zwischen Groß- und Kleinschreibung unterschieden, und ein als String gesendeter Boolean wird nicht als Boolean gelesen. Prüfen Sie auch, ob die App-Version auf dem Gerät älter ist als diejenige, mit der der Schlüssel eingeführt wurde. Prüfen Sie auf einem Gerät mit Arbeitsprofil, ob die Person die Arbeitskopie der App geöffnet hat, erkennbar am Aktenkoffer-Symbol. Die private Kopie erhält die Konfiguration nie.

Einige Chrome-Richtlinien funktionieren, andere nicht.

Nicht jede Chrome Enterprise-Richtlinie wird unter Android unterstützt. Überprüfen Sie die Plattformunterstützung jeder einzelnen Richtlinie in der Chrome Enterprise-Richtlinienliste und kontrollieren Sie die Chrome-Version auf dem Gerät.

Kann ich an jedes Gerät einen anderen Wert übertragen?

Ja, aber nicht standardmäßig. Verwenden Sie Konfigurationsvariablen, wenn Ihre Konsole diese für das benötigte Attribut unterstützt, unterteilen Sie Geräte in kleinere Richtlinien oder lassen Sie die App gerätespezifische Einstellungen von ihrem Backend abrufen. Siehe Schritt 5.

Die Konfiguration wurde angewendet, aber der Mitarbeiter kann das Feld immer noch bearbeiten.

Das Sperren eines Feldes ist Aufgabe der App, nicht von Android. Bitten Sie den Entwickler, Einstellungen, die aus einer Managed Configuration stammen, zu deaktivieren oder auszublenden.

Wie teste ich, ohne die Produktivumgebung zu beeinträchtigen?

Verwenden Sie eine dedizierte Testrichtlinie und ein einzelnes registriertes Gerät. Für interne Apps können Entwickler TestDPC nutzen, noch bevor die App jemals Ihr MDM erreicht.

Nächste Schritte

Wichtigste Erkenntnisse:

• Der App-Entwickler definiert, was konfiguriert werden kann. Ihr MDM füllt lediglich diese Felder aus und nichts darüber hinaus.
• Prüfen Sie zuerst die Unterstützung, erfassen Sie Schlüssel und Typen und testen Sie auf einem Gerät, bevor Sie den Rollout starten.
• Gemeinsame Werte gehören in die Richtlinie. Gerätespezifische Werte erfordern Variablen, kleinere Richtlinienbereiche oder app-seitige Abfragen.
• Bei internen Apps erfordert das Hinzufügen eines Schemas eine kleine, gut dokumentierte Änderung und macht den manuellen Einrichtungsschritt für Mitarbeiter überflüssig.

Beginnen Sie diese Woche mit der App, die die meisten Einrichtungs-Tickets verursacht. Listen Sie deren Schlüssel auf, erstellen Sie eine Testrichtlinie und verifizieren Sie sie auf einem Gerät. Senden Sie anschließend die obige Entwickler-Checkliste an das Team, das für Ihre interne App zuständig ist.

Wenn Sie diesen Ablauf mit Nomid MDM ausprobieren möchten: Die App-Karte im Richtlinien-Editor öffnet die Managed Configuration jeder App, und der kostenlose Tarif deckt bis zu 10 Geräte ohne zeitliche Begrenzung ab. Das reicht für eine Testrichtlinie und eine Pilotgruppe aus. Fernzugriff und die API sind im kostenlosen Tarif nicht enthalten.

FAQ

Was ist eine Android Managed Configuration?

Es handelt sich um eine Sammlung von Schlüssel-Wert-Einstellungen, die ein Unternehmen an eine App auf einem verwalteten Android-Gerät überträgt. Beispiele hierfür sind eine Server-URL, zulässige Websites oder Funktionsschalter. Der Entwickler der App definiert die verfügbaren Felder in einem über Google Play veröffentlichten Schema, und das MDM sendet die Werte über die Geräterichtlinie.

Woran erkenne ich, ob eine App App-Konfigurationen unter Android Enterprise unterstützt?

Fügen Sie die App zu einer Testrichtlinie in Ihrem MDM hinzu und prüfen Sie, ob ein Konfigurationsformular angezeigt wird. Sie können auch die Enterprise-Dokumentation des Anbieters einsehen oder dessen Support-Team fragen, welche Managed-Configuration-Schlüssel die App bereitstellt.

Was ist app_restrictions.xml?

Es ist die XML-Datei in den Ressourcen einer Android-App, in der der Entwickler das Managed-Configuration-Schema deklariert: Schlüssel, Typ, Titel und Standardwert jeder Einstellung. Die Datei wird im App-Manifest referenziert, und Google Play liest sie aus, wenn die App hochgeladen wird.

Wird eine Änderung der Managed Configuration sofort wirksam?

Das Gerät empfängt sie bei der nächsten Richtliniensynchronisierung. Ob die App sie sofort anwendet, hängt von der App ab. Apps, die auf den Restrictions-Changed-Broadcast lauschen, aktualisieren sich während der Ausführung, während andere ihre Konfiguration erst beim nächsten Start auslesen.