Im heutigen Beitrag meines C++-Blogs möchte ich auf die statische Reflexion in C++26 eingehen. Einer der großen Vorteile von Reflexion ist, dass wir die neue Funktion bereits ausprobieren können, da mit Clang ein Compiler verfügbar ist, der alle Facetten implementiert. Und auch der jüngst erschienene GCC 16 implementiert das Feature bereits.

Anhand meiner typischen Anwendungsfälle habe ich untersucht, welche Aufgaben sich mit Reflexion besser lösen lassen. Eine Aufgabe, die mich den größten Teil meiner Karriere beschäftigt hat, war das Lesen und Schreiben von Daten, die über eine Netzwerkverbindung kamen. Die Definition von „Netzwerk“ war zu verschiedenen Zeiten unterschiedlich. Gemeinsam war jedoch, dass alles, was gesendet wurde, in Netzwerk-Byte-Reihenfolge (Big-Endian) verschickt wurde, und alles, was empfangen wurde, ebenfalls in Netzwerk-Byte-Reihenfolge ankam. Für manche Systeme machte das keinen Unterschied, da sie bereits Big-Endian-Maschinen waren. Aber nicht immer. Vor allem ARM setzte auf Little-Endian. Bei einem Teil der Systeme mussten die Daten beim Empfangen oder Senden daher byteweise vertauscht werden.

Wie tauscht man Daten?

Das Problem hier (war), wie tauscht man die Daten? Jeder Datentyp, der größer als ein Byte ist, muss jedes Mal getauscht werden. C++23 hat uns std::byteswap gegeben, wodurch POSIX-Funktionen wie htons überflüssig geworden sind. Das bedeutet zumindest eine Verbesserung im Hinblick auf Sicherheit.

Fangen wir mit einem Beispiel an. Der folgende Code zeigt die Datenstrukturen, die ich heute verwende.

enum class Color16 : uint16_t
{
};

struct RGB48 {
  Color16 red;
  Color16 green;
  Color16 blue;

  auto operator<=>(const RGB48&) const = default;
};

struct LEDState {
  bool  state;
  RGB48 rgbColor;

  auto operator<=>(const LEDState&) const = default;
};

struct LEDStateMessage {
  uint32_t messageId;
  LEDState state;

  auto operator<=>(const LEDStateMessage&) const = default;
};

Wie du sehen kannst, ist die letzte Struktur LEDStateMessage später die Wurzel. Diese Struktur enthält eine Struktur, die wiederum eine Struktur enthält. Wir gehen es heute also rekursiv an.

Alle structs verfügen über einen Dreiwege-Vergleichsoperator – das erleichtert die Überprüfung.

Was ich erreichen möchte, sieht in etwa so aus:

LEDStateMessage msg{.messageId = 3,
                    .state{.state = true,
                           .rgbColor{.red   = Color16{0x5u},
                                     .green = Color16{0x28u},
                                     .blue  = Color16{0x40u}}}};

Serialize(msg);

Die Daten sollten ausgetauscht oder besser noch an Ort und Stelle serialisiert werden. Ich gehe von einem System mit Speicherbeschränkungen aus, bei dem ich es mir nicht leisten kann, doppelt so viel Speicher zu verbrauchen.

Denke jetzt mal einen Moment darüber nach, wie viel Mühe du dir in der Vergangenheit gegeben hast, damit Serialize funktioniert. Ich für meinen Teil kann sagen, dass es mich viele Stunden gekostet hat.

Reflexion zur Rettung

Bist du bereit? Okay, hier kommt es:

template
requires(not std::is_pointer_v) and std::is_trivially_copyable_v
constexpr void Serialize(T& data)
{
  if constexpr(std::is_array_v) {  // #A
    for(int i{}; i < std::size(data); ++i) { Serialize(data[i]); }

  } else if constexpr(std::is_enum_v) {  // #B
    data = static_cast(std::byteswap(std::to_underlying(data)));

  } else if constexpr(not std::is_class_v) {  // #C
    data = std::byteswap(data);

  } else {  // #D
    static constexpr auto members =
      std::define_static_array(std::meta::nonstatic_data_members_of(
        ^^T, std::meta::access_context::current()));

    template for(constexpr auto& mem : members) { Serialize(data.[:mem:]); }
  }
}

Die Implementierung von Serialize besteht aus vier Teilen. In Abschnitt #A prüft Serialize, ob es sich um ein Array handelt. Wenn der Datentyp passt, ruft die Implementierung Serialize für jedes Element des Arrays auf.

Als Nächstes prüft die Implementierung in #B, ob der Datentyp ein enum ist. In diesem Fall wird C++23s std::to_underlying zusammen mit std::byteswap verwendet, um die Bytes tatsächlich zu vertauschen.

Nun wird in #C, falls dieser Datentyp kein Klassentyp ist, std::byteswap auf die Daten angewendet.

So weit, so gut. Bisher ist das alles generischer Code, den du schon vor C++26 so schreiben konntest. Der knifflige Teil sind die Datenelemente von Klassentypen. Genau das wird in #D behandelt.

Dank der Reflexion-Fähigkeiten durchläuft die Implementierung alle Datenelemente der Klasse und ruft für jedes davon Serialize auf. Et voilà, ein hervorragender erster Entwurf einer generischen Serialisierungsfunktion.

(Matthias Parbel)

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)