<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1732033&amp;fmt=gif">
Skip to content
Kontakt
All posts

Android 17 im Unternehmen: Diese Richtlinien gehören vor den Rollout

  ISEC7 Redaktion  ·  6 minute read

Google hat Android 17 am 16. Juni 2026 veröffentlicht, und mehrere Änderungen betreffen verwaltete Geräte im Unternehmen direkt. Laut Googles Übersicht der Neuerungen für Unternehmen in Android 17 bekommen Administratoren neue Schalter für KI-Automatisierung und eine Laufzeitberechtigung für den Zugriff aufs lokale Netz. Dazu kommen Certificate Transparency ab Werk und eine Sperre für Localhost-Verkehr zwischen Arbeits- und Privatprofil. Vieles davon lässt sich vorab per Richtlinie regeln. Bei Certificate Transparency braucht es einen Blick in die eigenen Apps.

Unser englischsprachiger Beitrag zu Android 16 for Enterprise aus dem Jahr 2025 beschrieb vor allem neue Optionen, die die IT einschalten konnte. Die Liste für Android 17 ist kürzer. Dafür ändert sie öfter das Standardverhalten, und ein Standard wirkt auf den Geräten, ob jemand eine Richtlinie angefasst hat oder nicht.

Eingeordnet haben die Neuerungen Oliver Schiemann und Magnus Wonschik im ISEC7-Webcast „What’s new in Android 17 for Enterprise?“ am 11. Juni 2026, wenige Tage vor der Veröffentlichung. Die Aufzeichnung gibt es kostenfrei nach Registrierung, wie die übrigen Aufzeichnungen in unserer Webcast-Übersicht.

Was Android 17 im Unternehmen ändert

Android 17 entspricht API-Level 37. Die Änderungen für die Geräteverwaltung lassen sich in drei Gruppen ordnen:

  • Per Richtlinie steuerbar: KI-Automatisierung abschalten, App-Functions-Daten für KI-Agenten auf dem Gerät sperren, die Berechtigung fürs lokale Netz vorab erteilen, USB-Datenverkehr samt HID, USB4 und Thunderbolt blockieren.
  • Ausgelöst durch Ihre Apps: Certificate Transparency und die Berechtigung fürs lokale Netz greifen bei Apps, die auf API-Level 37 oder höher zielen.
  • Wirksam für jede App: Localhost-Verkehr zwischen Arbeitsprofil und privatem Profil ist gesperrt.

Google hat die Unternehmensseite zuletzt am 16. September 2026 aktualisiert.

Lassen sich KI-Agenten und App Functions auf verwalteten Geräten abschalten?

Ja, auf Firmengeräten. Android 17 bringt ein Framework, mit dem KI-Agenten Abläufe in Apps automatisieren. In Arbeitsprofilen lässt Google diese Automatisierung nicht zu. Auf vollständig verwalteten Geräten und im privaten Profil von COPE-Geräten schalten Administratoren sie mit der vorhandenen Richtlinie setNearbyAppStreamingPolicy ganz ab.

Ein zweiter Weg reicht Gerätedaten an KI-Agenten auf dem Gerät weiter. Berechtigte Assistenten-Apps bekommen sie über das App-Functions-Framework. Aus Arbeitsprofilen liefert es nichts, und global abschalten lässt es sich mit setAppFunctionsPolicy und dem Wert APP_FUNCTIONS_DISABLED.

Bei BYOD mit Arbeitsprofil ist die dienstliche Seite damit von Haus aus geschützt, die private bleibt Sache der Nutzer. Auf Firmengeräten entscheiden Sie. Im Webcast zu Android 17 haben die Referenten das Arbeitsprofil als Schutzwall für dienstliche Daten beschrieben. Ihr Rat: prüfen, welche Verbindungen aus dem Arbeitsprofil heraus möglich sind, und sie bei Bedarf sperren, etwa per URL-Filter, wenn das Arbeitsprofil im VPN läuft. Die Frage gehört in dieselbe Richtlinienprüfung wie jede andere Einschränkung, und Ihr UEM muss beide Richtlinien anbieten, bevor Sie sie setzen können.

Warum scheitern eigene Apps mit interner PKI unter Android 17?

Weil Certificate Transparency jetzt standardmäßig aktiv ist. Zielt eine App auf Android 17 (API-Level 37) oder höher, prüft das System ihre Verbindungen gegen Certificate Transparency; unter Android 16 mussten Apps das noch selbst einschalten (Google, Verhaltensänderungen). Google warnt, dass Verbindungen mit privaten oder internen Zertifikaten scheitern können, wenn die betroffenen Domains nicht in einer eigenen Network Security Configuration ausgenommen sind.

Auslöser ist das Ziel-API-Level der App, nicht allein das Betriebssystem. Bei Certificate Transparency verhält sich eine interne App unter Android 17 wie bisher, bis ihre Entwickler das Ziel auf 37 anheben. Dann zählt, ob die App Server mit Zertifikaten aus einer internen CA anspricht und ob der Build diese Domains ausnimmt. Die Korrektur steckt in der App, nicht im UEM. Sie gehört also zu dem Team, das Ihre eigenen Apps baut. Die Empfehlung aus unserem Webcast zu Android 17 passt dazu: interne CAs und selbstsignierte Zertifikate vor dem Rollout testen und die eigenen Apps prüfen.

Ähnlich liegt der Fall bei Encrypted Client Hello (ECH). Bei Apps mit Ziel Android 17 nutzt das System ECH für TLS-Verbindungen, sofern die Netzwerkbibliothek der App und der Server es unterstützen. Der Servername im Verbindungsaufbau ist dann verschlüsselt (Google, Verhaltensänderungen). Oliver Schiemann und Magnus Wonschik raten deshalb, das Netzwerkteam früh einzubinden und URL-Filter zu prüfen.

Zwei weitere Punkte für dieses Team: Bei Apps mit Ziel Android 17 schaltet setContentCaptureEnabled(false) die Content Capture nicht mehr ab, Google verweist für Bildschirme, die nicht erfasst werden dürfen, auf FLAG_SECURE. Und die Berechtigung fürs lokale Netz im nächsten Abschnitt greift ab demselben Ziel-API-Level.

Zugriff aufs lokale Netz braucht eine Berechtigung

Android 17 führt die Laufzeitberechtigung ACCESS_LOCAL_NETWORK für Apps ein, die Geräte im lokalen Netz finden oder ansprechen. Bei Apps mit Ziel-API-Level 37 oder höher ist der Zugriff aufs lokale Netz gesperrt, bis die Berechtigung erteilt ist. Apps mit Ziel 36 oder niedriger behalten den Zugriff über die INTERNET-Berechtigung (Google, Local network permission).

Die Sperre sitzt tief im Netzwerkstapel. Sie gilt für ausgehende und eingehende TCP-Verbindungen zu lokalen Adressen, für UDP als Unicast, Multicast und Broadcast, für die Erkennung per mDNS und SSDP sowie für die Klasse NsdManager. Die Berechtigung gehört zur Gruppe NEARBY_DEVICES. Wer schon eine andere Berechtigung dieser Gruppe erteilt hat, wird nicht noch einmal gefragt.

Auf verwalteten Geräten müssen Sie nicht darauf warten, dass Nutzer „Zulassen“ tippen. Google nennt setPermissionGrantState() als Weg, die Berechtigung für die Apps, die sie brauchen, vorab zu erteilen.

Localhost zwischen Arbeits- und Privatprofil ist gesperrt

Ab Android 17 ist Loopback-Verkehr über Profilgrenzen, etwa an 127.0.0.1, standardmäßig nicht mehr erlaubt (Google, Verhaltensänderungen für alle Apps). Innerhalb desselben Profils bleibt er möglich. Die Änderung gilt für jede App unter Android 17, unabhängig vom Ziel-API-Level.

Spricht eine App im Arbeitsprofil über Localhost mit einem Hilfsdienst oder Proxy im privaten Profil, reißt diese Verbindung mit dem Update ab. Google begründet die Sperre mit dem Schutz von Unternehmensdaten.

USB, HID und Thunderbolt hängen an einer Richtlinie

Direkter Zugriff auf Rohdaten von Eingabegeräten (Human Interface Devices) braucht jetzt die als gefährlich eingestufte Berechtigung ACCESS_HID. Auf verwalteten Geräten sperren Administratoren diesen Zugriff, indem sie mit setUsbDataSignalingEnabled den USB-Datenverkehr abschalten.

Dieselbe Richtlinie deckt die neuen schnellen Schnittstellen ab. Android 17 unterstützt PCIe-Tunnel über USB4 und Thunderbolt, und laut Google werden diese Tunnel blockiert, sobald der USB-Datenzugriff eingeschränkt ist. Wer USB-Daten auf Firmengeräten schon abschaltet, hat die neuen Schnittstellen damit erfasst.

Außerdem

Die Kontaktauswahl des Systems (Contacts Picker) kann jetzt vollständige Kontakteinträge über Profilgrenzen weitergeben, wobei Nutzer jeden Kontakt einzeln auswählen. Ob dienstliche Kontakte von der privaten Seite aus sichtbar sind, regelt weiterhin setCrossProfileContactsSearchDisabled. Eine bestehende Einstellung behält also ihre Wirkung.

Nicht an Android 17 gebunden, im Webcast aber ebenfalls Thema: Das Zero-Touch-Portal kennt neben Owner und Admin die Rollen Manager, Assigner und Viewer (Google, Zero-touch enrollment for IT admins). Ein Assigner weist Konfigurationen zu, ohne sie ändern zu können. Die Nur-Lese-Rolle Viewer nannten die Referenten besonders für die Compliance-Dokumentation nützlich.

Verfügbarkeit

Google hat Android 17 am 16. Juni 2026 veröffentlicht, zuerst für die meisten unterstützten Pixel-Geräte. Am selben Tag kam der Quellcode ins Android Open Source Project. Über Pixel hinaus kündigt Google neue Geräte mit Android 17 für die kommenden Monate an.

So fangen Sie an

  1. Über KI-Automatisierung entscheiden, für vollständig verwaltete Geräte und COPE, und beide Richtlinien setzen, sobald Ihr UEM sie anbietet.
  2. Beim App-Team nachfragen, welche eigenen Apps auf API-Level 37 zielen oder bald zielen werden und ob sie Server mit internen Zertifikaten ansprechen. Parallel prüft das Netzwerkteam die URL-Filter.
  3. Apps mit Bedarf am lokalen Netz auflisten und ihnen ACCESS_LOCAL_NETWORK vorab erteilen.
  4. Apps im Arbeitsprofil testen, die über Localhost mit dem privaten Profil sprechen.
  5. USB-Richtlinie prüfen. Ist der USB-Datenverkehr schon abgeschaltet, sind HID, USB4 und Thunderbolt mit abgedeckt.

Wer was macht

Google legt die Schnittstellen und die neuen Standards fest. Welche Richtlinien eine UEM-Plattform anbietet und ab welchem Release, entscheidet der UEM-Hersteller. Ziel-API-Level und Network Security Configuration bestimmen die Entwickler Ihrer Apps.

Hinter der Frage nach dem UEM steht ein Umbau, den unser Webcast zu Android 17 ausführlich behandelt hat: weg vom Device Policy Controller, den bisher jeder UEM-Hersteller als eigene App mitbringt, hin zur Android Management API (AMAPI) von Google. Die Referenten rieten, die AMAPI-Roadmap des eigenen UEM-Herstellers zu verfolgen. Den Unterschied zeigten sie am Arbeitsprofil: fünf Schritte und 5 bis 10 Minuten mit der Agent-App des Herstellers, drei Schritte und 3 bis 5 Minuten per Web-based Enrollment ohne App-Download. Die Grundlagen zu AMAPI beschreibt unser Beitrag zur Zukunft des Android-Gerätemanagements.

ISEC7 berät zu UEM-Plattformen mehrerer Hersteller, integriert und betreibt sie im Rahmen unseres Endpoint Managements. Für Google sind wir autorisierter Google Chrome Service Partner und Android Enterprise Service Provider. Wer das eigene Team auf Android vorbereiten will, findet dafür das eintägige Training Android Enterprise Fundamentals mit Device-Management-Modellen, Bereitstellungsmethoden und der Integration ins UEM, virtuell oder in Hamburg. Für Flotten mit Samsung Knox gibt es zusätzlich den Kurs Samsung Knox Fundamentals.

Häufige Fragen

Lässt sich KI-Automatisierung auf verwalteten Android-17-Geräten abschalten?

Ja. In Arbeitsprofilen lässt Google die Automatisierung durch KI-Agenten gar nicht zu. Auf vollständig verwalteten Geräten und im privaten Profil von COPE-Geräten schalten Administratoren sie mit der vorhandenen Richtlinie setNearbyAppStreamingPolicy ganz ab. Die Weitergabe von Gerätedaten über App Functions lässt sich mit setAppFunctionsPolicy und dem Wert APP_FUNCTIONS_DISABLED global sperren.

Warum funktionieren eigene Apps nach dem Wechsel auf Android 17 möglicherweise nicht mehr?

Bei Apps mit Ziel-API-Level 37 oder höher ist Certificate Transparency standardmäßig aktiv. Google warnt, dass Verbindungen mit privaten oder internen Zertifikaten scheitern können, wenn die Domains nicht in einer eigenen Network Security Configuration ausgenommen sind. Die Korrektur steckt im Build der App. Sie liegt deshalb bei den Entwicklern, nicht bei der UEM-Administration.

Kann die IT die Berechtigung fürs lokale Netz vorab erteilen?

Ja. Apps mit Ziel-API-Level 37 oder höher brauchen die Laufzeitberechtigung ACCESS_LOCAL_NETWORK, um Geräte im lokalen Netz zu erreichen. Auf verwalteten Geräten erteilen Administratoren sie mit setPermissionGrantState() vorab, dann fragt das Gerät die Nutzer nicht. Apps mit Ziel 36 oder niedriger behalten den Zugriff über die INTERNET-Berechtigung.

Welche Änderung in Android 17 betrifft alle Apps, egal auf welches API-Level sie zielen?

Die Sperre für Loopback-Verkehr über Profilgrenzen. Ab Android 17 ist Verkehr an Adressen wie 127.0.0.1 zwischen Arbeitsprofil und privatem Profil standardmäßig nicht mehr erlaubt. Innerhalb desselben Profils funktioniert Loopback weiter. Die Änderung gilt für jede App unter Android 17, unabhängig von ihrem Ziel-API-Level.

Quellen

ISEC7-Ressourcen