Eigentlich sagte Google im April, dass das Update auf Android 17 Beta 4 die „letzte geplante Beta“ des Entwicklungszyklus sei, bevor die Version als stabile Version veröffentlicht werde. Mit der Beta 4.1 kommt der Konzern also ein wenig überraschend um die Ecke. Zudem macht Google darauf aufmerksam, dass einige Hardwarepartner auch schon Betas für einige ihrer Geräte anbieten.

Das Update Android 17 Beta 4.1 ist den Release-Notes zufolge recht klein, steht aber für das Pixel 6 bis hin zu den Geräten der neuen Pixel-10-Serie zur Installation bereit. Der Build CP21.260330.011.A1 ist für Pixel 6/Pro/a Pixel 7/Pro bestimmt, während sich CP21.260330.011 an alle anderen Pixel-Modelle richtet.

Fehlerbehebungen im Fokus

Hinsichtlich der Neuerungen enthält die Beta 4.1 lediglich fünf kleine Fehlerbehebungen, jedoch keine neuen Funktionen. Die aus Googles Sicht wichtigsten neuen Features hatte der Konzern im Zuge der Android Show: I/O Edition am 12. Mai gezeigt – inklusive der agentischen KI Gemini Intelligence, die jedoch nur für High-End-Geräte bestimmt ist.

Google erklärt, dass es mit dem nun veröffentlichten Update ein Problem behebt, bei dem die Statusleiste fälschlicherweise keinen Signalbalken anzeigte, obwohl eine Verbindung bestand. Ebenso haben die Entwickler ein Problem mit der UI-Synchronisation gefixt, bei dem das Symbol für die Schnellsteuerung der mobilen Daten im Flugmodus aktiv blieb.

Zudem soll es keine Probleme mehr beim Anschluss externer Displays geben – zumindest sollen sie nun nicht mehr schwarz werden, wenn eine hohe Auflösung ausgewählt wird. Ebenso habe Google einen Fehler bei der Bluetooth-Audioübertragung behoben, der nach Systemunterbrechungen wie Timern zu einer Unterbrechung der Wiedergabe führte. Außerdem sollen Hörgeräte nach Inaktivität oder dem Aufladen nicht mehr automatisch aus den gekoppelten Geräten entfernt werden.

Android 17 Beta für „Partnergeräte“

Während Google seine Betas nur für seine Pixel-Modelle anbietet, macht der Konzern darauf aufmerksam, dass einige Hardwarepartner Versionen der Android-17-Beta für ausgewählte Smartphones anbieten.

Zu den Partnern zählen Honor, iQOO, Lenovo/Motorola, OnePlus, Oppo, Realme, Sharp, Vivo und Xiaomi. Interessanterweise erwähnt Google seinen engen Partner Samsung nicht, obwohl der Konzern sein Betaprogramm auf One UI 9 auf Basis von Android 17 für die Galaxy-S26-Serie gestartet hat.

Für interessierte und wagemutige Besitzerinnen und Besitzer eines der kompatiblen Modelle hat Google eine Übersichtsseite gestaltet, die zu den jeweiligen Betaprogrammen führt.

Auf den Webseiten der Partner finden Nutzer jeweils Anleitungen, wie sie die Android-17-Beta installieren können. Die meisten bieten System-Images zum Herunterladen und Flashen an, einige unterstützen derweil zusätzlich Over-the-Air-Updates (OTA), wie etwa Samsung über sein eigenes Betaprogramm.

(Andreas Floemer)

Google wird Android-Apps erlauben, ein Dutzend well-known Ports (kleiner als 1024) zu nutzen – etwa als Server respektive Service. Das öffnet neue Einsatzmöglichkeiten für populäre Android-Geräte, insbesondere im lokalen Netzwerk. Konkret sollen mit dem nächsten Update des Google Play Systems Android-Apps bei Bedarf Dienste auf diesen neun TCP-Ports anbieten dürfen: 20 und 21 (typischerweise für FTP genutzt), 22 (SSH/SFTP), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 445 (SMB), sowie die beiden regelmäßig für vernetzte Drucker eingesetzten Ports 515 (LPD) und 631 (IPP).

Hinzu kommen drei UDP-Ports: 319/320 (typischerweise für Zeitgeber-Synchronisierung mittels PTP) und 443 (für das QUIC-basierte WWW-Protokoll HTTP/3). Das geht aus einer am Wochenende veröffentlichten Mitteilung im öffentlichen Bugtracker Androids hervor. Kein Glück haben beispielsweise Nutzer von TFTP (UDP-Port 69) oder Doom-Fans (klassisch Port 666).

Bislang sperrt Google auf seinen Android-Versionen grundsätzlich Ports kleiner 1024. Nur wenn solche Android-Implementierungen gerootet sind, kann der Administrator die sogenannten well-known Ports zugänglich machen. Das schwächt unter Umständen bestimmte IT-Sicherheitsmaßnahmen.

Ein bisschen Glasnost

Daher regen Entwickler im Android Bugtracker seit vielen Jahren an, die Einschränkung fallen zu lassen. Doch Google hat das mehrfach als „absichtliches Verhalten” eingestuft und das Gesuch abgelehnt („Won’t Fix”). Im Oktober 2021 überraschte ein Googler mit der „Erklärung”, dass „raw sockets konstante Quelle für kernel exploits” seien, weshalb die Verbesserung nicht infrage komme. Dabei hatte niemand nach raw sockets (OSI-Layer 2 oder 3) gefragt, sondern lediglich nach Zugang für unprivilegierte Apps auf Layer 4.

Auch den zumindest dritten Anlauf vor gut vier Jahren hat Google mit „Won’t Fix” abgeschmettert. Doch vorige Woche entdeckte ein womöglich deutscher Entwickler, dass Anwendungen in der Developer Preview auf Android 17 Zugriff auf die UDP-Ports 319 und 320 ergattert haben.

Daraufhin rang Google sich zu einer teilweisen Öffnung durch, auch für altere Androids. Die grundsätzliche Herangehensweise, well-known Ports zu sperren, bleibt aufrecht. So viel Orthodoxie muss offenbar sein. Immerhin wird die Nutzung der zwölf obgenannten Ports ermöglicht.

Technisch gesehen setzt Google die neue Port-Whitelist mittels eBPF (extended Berkley Packet Filter) um. Das erfolgt in jenem APEX-Modul, das in Android Mainline für Datenverbindungen samt Tethering zuständig ist. Solche Module können durch Google Play Updates erneuert werden und bedürfen keines Updates des gesamten Betriebssystems. Der Konzern könnte Zukunft also relativ einfach weitere well-known Ports zur Verfügung stellen, wenn er denn möchte.

Voraussetzungen und Vergleich

Voraussetzung für den neuen Portzugriff sind sowohl mindestens Android 13 (API-Version 33 und höher) als auch mindestens Linux-Kernel 5.15. Damit sind Anwender erst mit Systemen, die neu mit Googles Android 14 ausgeliefert wurden, auf der sicheren Seiten. Mobiltelefone, die mit Googles Android 13 neu ausgeliefert wurden, durften Kernel 5.10 oder 5.15 nutzen, sind also nicht alle mit dabei. Geräte, die mit älteren Android-Versionen auf den Markt gekommen und später auf jüngere Versionen des Betriebssystems upgegradet worden sind, können sogar mit noch älteren Kernel-Versionen laufen.

Bei den Android-Varianten Android Auto, TV und Wear könnte die Verbesserung länger auf sich warten lassen. Das gilt auch für Android Go; das ist eine für weniger leistungsstarke Handys und Mobilfunknetze optimierte Android-Variante.

Die Einschränkung der niedrigen Ports ist auch bei anderen Linux-Systemen üblich. Allerdings ist es dort Administratoren in der Regel ein Leichtes, bei Bedarf Anwendungen den Zugriff zu gestatten. Für MacOS galt das nicht, doch können nicht-privilegierte Anwendungen seit Version 10.14 über die Wildcard-Adresse 0.0.0.0 auch an well-known Ports andocken. Den nicht auf Linux basierenden Betriebssystemen iOS und Windows ist die strikte Portnummern-basierte Blockade fremd.

(ds)

Die Wiener Proxmox Server Solutions GmbH hat ihren Proxmox Datacenter Manager 1.1 veröffentlicht. Der Datacenter Manager bietet eine zentrale, einheitliche Web-Konsole, um alle Instanzen des Proxmox Virtual Environment (VE) und des Proxmox Backup Servers zu managen. Der gesamte Cluster samt aller Nodes kann so organisationsübergreifend verwaltet, überwacht und skaliert werden. Die neue Version 1.1 des Proxmox Datacenter Managers bietet automatisierte Workflows für das Ausrollen von Nodes, eine umfassende Subskriptions-Verwaltung, ein einheitliches Ceph-Cluster-Monitoring sowie ein erweitertes, zentrales Gast- und Snapshot-Management.

Mit Version 1.1 erweitert der Proxmox Datacenter Manager seine Rolle zum zentralen Konfigurationsserver für automatisiertes Host-Provisioning in verteilten Infrastrukturen. Administratoren können sogenannte Antwortdateien mit vordefinierten Installationsparametern zentral verwalten und für das unbeaufsichtigte Ausrollen neuer Hosts bereitstellen. Die Abläufe sind über den neuen Bereich „Automatische Installationen“ im Reiter „Remotes“ direkt im Webinterface erreichbar. Dort lässt sich auch der Fortschritt laufender Installationen in Echtzeit überwachen.

Für die Absicherung des Provisioning-Prozesses setzt Proxmox auf einen tokenbasierten Mechanismus: Nur autorisierte Zielsysteme erhalten Zugriff auf die hinterlegten Konfigurationen. Damit adressiert Proxmox vor allem größere Cluster- und Edge-Szenarien, in denen konsistente Rollouts und zentrale Verwaltung entscheidend sind. Wie das aktuelle Proxmox Virtual Environment 9.2 basiert auch der Proxmox Datacenter Manager 1.1 auf Debian GNU/Linux 13.5 „Trixie“ mit Linux-Kernel 7.0 inklusive aktualisierter Pakete und Bugfixes sowie OpenZFS 2.4.2.

Zentrale Verwaltung von Subskriptionen

Ebenfalls neu im Proxmox Datacenter Manager 1.1 ist eine zentrale Subscription-Registry, um die Verwaltung von Lizenzschlüsseln in verteilten Infrastrukturen zu vereinfachen. Administratoren können Subscription-Keys zentral vorhalten, einzelnen Remotes zuweisen und bei Bedarf wieder entkoppeln. Das reduziert den Verwaltungsaufwand insbesondere in Multi-Site-Umgebungen mit vielen Hosts. Zudem lassen sich Subscription-Keys direkt in vorbereitete Antwortdateien integrieren. Neue Hosts registrieren ihre Subscription damit automatisch bereits während der Installation. Die Funktion verzahnt Lizenzmanagement und automatisiertes Provisioning und soll konsistente Deployments in größeren Proxmox-Umgebungen erleichtern.

Der Proxmox Datacenter Manager 1.1 erweitert das Monitoring verteilter, hyperkonvergenter Infrastruktur-Umgebungen (HCI) um eine native Überwachung angebundener Ceph-Cluster. Administratoren erhalten über ein zentrales Dashboard konsolidierte Einblicke in Zustand, Kapazität und Echtzeit-Performance mehrerer Cluster. Die einheitliche Ansicht erleichtert insbesondere den Betrieb verteilter Proxmox-VE-Infrastrukturen und reduziert den Aufwand für die Analyse einzelner Standorte. Darüber hinaus liefert das Monitoring detaillierte Statusinformationen zu Object Storage Daemons (OSDs), Monitoren, Managern, Metadata Servern (MDS), Storage-Pools, CephFS sowie relevanten Cluster-Flags. Damit adressiert Proxmox vor allem Betreiber größerer HCI-Deployments mit hohen Anforderungen an Transparenz und Betriebsüberwachung.

Zentrales Guest- und Snapshot-Management

Mit Version 1.1 legt der Proxmox Datacenter Manager den Grundstein für ein zentrales Guest-Management über mehrere Remotes hinweg. Virtuelle Maschinen auf Basis von QEMU sowie LXC-Container lassen sich nun in einer gemeinsamen Ansicht verwalten, wahlweise als sortierbare Tabelle oder in einer nach Remotes strukturierten Baumansicht. Textfilter erleichtern die Suche nach einzelnen Gästen, während häufig genutzte Aktionen direkt aus der Übersicht heraus verfügbar sind.

Neu hinzu kommt ein zentrales Snapshot-Management: Snapshots lassen sich in einer Parent-Child-Struktur anzeigen, erstellen, wiederherstellen oder löschen. Auch das Bearbeiten von Beschreibungen ist möglich. Ergänzend führt Proxmox den Befehl „Resume“ für pausierte oder suspendierte QEMU-VMs ein. Die Funktionen markieren den ersten Schritt hin zu einer umfassenderen Guest-Orchestrierung, die in kommenden Releases weiter ausgebaut werden soll.

Preise und Verfügbarkeit

Geplante Funktionen sowie alle Verbesserungen und Neuerungen des Proxmox Datacenter Managers 1.1 beschreibt dessen Roadmap detailliert. Der Proxmox Datacenter Manager 1.1 steht als Open-Source-Software ab sofort zum Download bereit und kann kostenlos eingesetzt werden. Die Software selbst ist kostenlos, ihr Einsatz erfordert allerdings aktive Enterprise Support Subscriptions für alle verwalteten Produkte.

(axk)