Kategorie: Android

Managed Home Screen: Woher kommt der angezeigte Gerätename?

Managed Home Screen: Woher kommt der angezeigte Gerätename?

Wer den Microsoft Managed Home Screen (MHS) im Shared Device Mode einsetzt, kennt das: In der Top Bar wird ein Gerätename angezeigt – übersichtlich, praktisch, nützlich für Frontline-Worker-Umgebungen. Aber mal ehrlich: Hast du dich schon gefragt, wo dieser Name eigentlich herkommt? Aus dem Android-System? Aus Intune? Und was passiert, wenn du das Gerät in der Konsole umbenennst?

Genau diese Frage hatte ich letztens im Office und habe mich rangesetzt, um ihr auf den Grund zu gehen. Spoiler: Ich wusste schon intuitiv woher die Info kommt – aber ich wollte es dann doch etwas technischer beleuchten. 😄

1. Die Quelle: Nicht Android – sondern Intune

Kurze Antwort zuerst: Der angezeigte Gerätename kommt nicht vom Android-Betriebssystem selbst. Es ist nicht das, was unter Einstellungen → Gerät → Gerätename steht. Sondern es ist der Device Name-Eintrag aus dem Microsoft Intune Admin Center – also der Anzeigename, den du in der Verwaltungskonsole vergeben hast.

⚠️ Wichtig: Das Umbenennen eines Geräts in Intune ändert nur den Anzeigenamen in der Konsole – nicht den lokalen Gerätenamen auf dem Android-Betriebssystem selbst! MHS zeigt immer den Intune-seitigen Namen an.

2. Der Übertragungsweg: App Configuration Policy mit {{DeviceName}}

Der Name gelangt über eine App Configuration Policy an das Gerät. Microsoft stellt dafür die dynamische Variable {{DeviceName}} bereit – Intune löst diese Variable serverseitig auf und bettet den echten Gerätenamen in die Policy ein, bevor sie ans Gerät gepusht wird.

Die drei relevanten Konfigurationsschlüssel in der App Configuration Policy:

Konfigurationsschlüssel Wert Funktion
Top Bar Primary Element Device Name Gerätename als primäres Element (nur ohne Sign-In)
Top Bar Secondary Element Device Name Gerätename als sekundäres Element
Show device name for all supported OS versions on MHS {{DeviceName}} Pflichtfeld – Intune befüllt automatisch den korrekten Wert

ℹ️ Shared Device Mode – Sonderregel: Wenn Sign-In aktiviert ist, wird das primäre Top-Bar-Element automatisch durch den Namen des angemeldeten Benutzers ersetzt. Der Gerätename kann dann nur noch als sekundäres Element konfiguriert werden.

3. Wird der Name lokal gespeichert? Ja – aber nicht wo du denkst

Hier wird es technisch interessant. Der Gerätename wird lokal auf dem Gerät gespeichert – allerdings nicht in einer einfachen Datei oder Datenbank, die ein Nutzer einsehen könnte. Stattdessen nutzt Android dafür den sogenannten Managed Configuration Mechanismus, auch bekannt als App Restrictions oder RestrictionsManager.

Der vollständige Datenpfad

Schritt              Was passiert?
1 Intune löst {{DeviceName}} serverseitig auf → z.B. „DEV-WARD-01“
2 App Configuration Policy mit aufgelöstem Wert wird an das Gerät gepusht
3 Device Policy Controller (Intune / Company Portal) schreibt Wert ins Android Managed Config Bundle
4 Android RestrictionsManager speichert Bundle im geschützten Systembereich
5 MHS App liest Wert beim Start via RestrictionsManager.getApplicationRestrictions()
6 Anzeige des Namens in der Top Bar

Eigenschaften des lokalen Caches

Eigenschaft Detail
Speicherort Systembereich des Android OS – nicht im App-eigenen Storage
Format Android Bundle (Key-Value-Pairs, binär)
Zugriffsrechte Nur der DPC (Intune Company Portal) darf schreiben; MHS darf nur lesen
Persistenz Bleibt über App-Neustarts erhalten; wird bei Policy-Sync oder Factory Reset aktualisiert
Offline-Verhalten Gerätename wird auch ohne Netzwerkverbindung angezeigt (gecacht)
Update-Zyklus Wird beim nächsten Policy-Sync aktualisiert (~alle 8 Stunden oder manuell)

4. Wo wird der Name nicht gespeichert?

Zur Klarheit – diese Speicherorte werden explizit nicht verwendet:

  • ❌ Nicht im lokalen Android-Gerätenamen (Settings.Global.DEVICE_NAME)
  • ❌ Nicht in einer Datei im MHS-App-Verzeichnis (/data/data/com.microsoft.launcher.enterprise/)
  • ❌ Nicht in einer für den Nutzer zugänglichen Datenbank
  • ✅ Ausschließlich im geschützten Android Managed Configuration Bundle – weder einsehbar noch manipulierbar durch den Endnutzer

Fazit

Der im Managed Home Screen angezeigte Gerätename kommt direkt aus dem Intune Admin Center – übermittelt via App Configuration Policy mit der Variable {{DeviceName}}. Lokal wird er im Android RestrictionsManager-Bundle gecacht: sicher, persistent, offline-fähig und für den Endnutzer weder einsehbar noch veränderbar.

Das macht die Sache für Frontline-Worker-Szenarien besonders praktisch. Egal ob das Gerät gerade online ist oder nicht – der Gerätename wird immer korrekt angezeigt.

Android spiegeln unter macOS via Screen Copy

Wenn man so wie ich, im täglichen Leben als MDM Architekt mit Android und iOS Devices arbeiten muss/darf, kommt man manchmal an Punkte, wo es ganz hilfreich ist, dass jeweilige Device (in meinem Falle Samsung und Zebra Rugged Devices) auf dem Lokalen Rechner zuspiegeln. Da ich aber keinen Windowsrechner benutze, sondern einen Mac, ist es manchmal halt bissel anders als unter dem Fenster-Riesen. Durch ein aktuelles Projekt, welches wir gerade begleiten, bin ich auf das Tool Screen Copy gestossen. Um dieses unter MacOS zu benutzen, mag ich euch heute diese Installationsanleitung näher bringen, da ich keine Deutsche Anleitung gefunden haben (ein Youtube Video in Englisch hänge ich unten dran). 😉

 

Scrcpy (auch Screen Copy genannt) ist ein OpenSource Projekt welches auf GitHub plaziert wurden. Scrcpy findet Ihr unter DIESEM Link. Scrcpy dient dazu, das Display des Android Devices auf eurem Mac (da es OpenSource ist, auch unter Win, Linux, etc) zu spiegeln und auch zu steuern. Gerade in Zeiten von COVID-19 und Home Office, eine super praktische Sache um in Präsentationen/Meetings den Kollegen/Kunden auch praktisch das Device zu präsentieren, obwohl diese halt nicht direkt vorort sind.

Also fangen wir an. Wir öffnen uns als erstes die Scrcpy Seite und gelangen auf die GitHUB Projekt Seite. Wenn Ihr dort runterscrollt, bekommt Ihr eine kurze Anleitung und Screenshots präsentiert. Für Scrcpy benötigt Ihr als erstes HomeBrew. Diese installiert ihr via:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Um das Script auszuführen, sucht Ihr nach eurer Terminal APP ( COMMAND + SPACEBAR und dann Terminal eingeben) und startet diese.

Hier gebt Ihr nun den Befehl ein und euer Adminpasswort (sudo):

MASCHINE:~ USERID$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
==> Checking for `sudo` access (which may request your password)...
Password:
==> This script will install:
.
.
.
. //WAIT JUST A FEW MINUTES
==> Installation successful!

Ist die Installation durch, kommen wir zum nächsten Punkt und installieren Scrcpy über den Terminal. Dazu geht Ihr wieder zurück in den Terminal und gebt dort folgenden Befehl ein:

brew install scrcpy

Der Befehl lädt nun alle benötigten Pakete von Scrcpy herunter und installiert diese. An dieser Stelle keine Panik, die Installation inkl. der Downloads dauert ein bischen was 😉

Ist der Prozess durch, müssen wir noch ADB (Android Debug Bridge) installieren. Dies tun wir über folgendes Kommando im Terminal:

brew install android-platform-tools

Sind wir hier durch, haben wir es endlich geschafft und können scrcpy starten. Dazu schließen wir das Android Device am Mac an und gehen in den Terminal um dort den Befehl einzugeben:

scrcpy

ein.

Wenn Ihr z.B. folgenden Fehler bekommt:
DEM0114:~ u074652$ scrcpy
2021-11-17 10:27:08.774 scrcpy[12412:322834] INFO: scrcpy 1.20 <https://github.com/Genymobile/scrcpy>
adb: error: failed to get feature set: no devices/emulators found
2021-11-17 10:27:08.788 scrcpy[12412:322835] ERROR: "adb push" returned with value 1
2021-11-17 10:27:09.170 scrcpy[12412:322834] ERROR: Server connection failed

müsst Ihr auf dem Gerät des Debugging-Modus & adb-Autorisierungs-Timout deaktivieren. Um dies zu ermöglichen, geht ihr wie folgt vor:

  • EINSTELLUNGEN
  • TELEFONINFO
  • SOFTWAREINFORMATIONEN
  • nun mindestens 7 mal auf BUILDNUMMER tippen

und der Entwichlermodus ist aktiviert.
Danach habt Ihr unter EINSTELLUNGEN den Punkt ENTWICKLEROPTIONEN und könnt hier die oben genannten Optionen aktivieren. Nun könnt Ihr euer Android Device via Mouse steuern und es am Mac darstellen.

Falls Ihr das ganz lieber als Video (in Englisch) sehen wollt, empfehle ich euch folgendes Video auf Youtube:

Viel Spaß