Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps. Wenn die Anforderungen höher werden, sind File-based Apps keine Sackgasse.

Entwicklerinnen und Entwickler können per Kommandozeilenbefehl aus einer File-based App ein C#-Projekt mit .csproj-Projektdatei machen:

dotnet project convert .\Dateiname.cs

Dabei wird ein neuer Ordner angelegt und eine Projektdatei angelegt, die die Präprozessor-Informationen aus der C#-Datei übernimmt.

Sollten die Dateien Dateiname.settings.json und Dateiname.run.json vorhanden sein, werden sie beim Konvertieren allerdings ignoriert.

(rme)

Etwa drei Wochen nach der Android 17 Beta 3 schiebt Google die Beta 4 heraus. Es ist laut der Entwickler die letzte geplante Betaversion, in den nächsten Wochen könnten noch Patches und Bugfixes erscheinen. Die neue Beta enthält neben wenigen Neuerungen eine lange Liste an Fehlerbehebungen – und das Easter-Egg.

„Du bist auf dem aktuellen Stand“

Nach der Beta 3, die allerhand neue nutzergerichtete Funktionen mit sich brachte, wie etwa die App-Bubbles, sind die Neuerungen in der Beta 4 überschaubar. Lediglich die schon in der April-Version von Android Canary gesichtete neue Nachricht nach dem Entfernen sämtlicher Benachrichtigungen: „Du bist auf dem aktuellen Stand“, begleitet von einem Pokal, ist neu. Die neue Anzeige orientiert sich dabei an Wear OS 6 etwa auf der Pixel Watch, sodass sie über das Ökosystem hinweg einheitlicher anmutet.

Zudem hat die letzte Beta das traditionelle Android-Easter-Egg an Bord: Begibt man sich in die Einstellungen „Über das Smartphone“, tippt auf die Android-Versionsnummer und anschließend dreimal schnell erneut auf die Android-Version, erscheint das Easter-Egg. Hier füllt man mit dem Finger den Kreis vollständig und hält das dann erscheinende Android-17-Logo gedrückt. Nun erscheint das seit einigen Android-Generationen integrierte kleine Space-Game, in dem man ein kleines Raumschiff durchs All manövriert.

Speicherbegrenzungen für Apps

Für Entwickler wichtig: Google führt mit Android 17 Beta 4 Speicherbegrenzungen für Apps ein, „die sich nach dem gesamten RAM-Speicher des Geräts richten, um eine stabilere und deterministische Umgebung für Ihre Anwendungen und Android-Nutzer zu schaffen“, schreibt Google. In der neuen Android-Version seien die Grenzwerte konservativ festgelegt, um Systembasiswerte zu etablieren. „Damit sollen extreme Speicherlecks und andere Ausreißer bekämpft werden, bevor sie systemweite Instabilität auslösen, die zu Rucklern in der Bedienoberfläche, erhöhtem Akkuverbrauch und dem Beenden von Apps führt“, erklärt der Konzern weiter.

Google empfiehlt Entwicklern, bewährte Verfahren für den Speicherumgang zu befolgen und Speicherlecks zu beheben. Um Entwicklern bei der Suche nach Speicherlecks zu helfen, bietet Android Studio Panda eine „LeakCanary-Integration“ direkt im Android Studio Profiler als eigene Aufgabe an.

Überdies unterstützt der Android-Keystore nun den nach NIST-Standard entwickelten ML-DSA (Module-Lattice-Based Digital Signature Algorithm). Auf unterstützten Geräten können Entwickler ML-DSA-Schlüssel generieren und diese zur Erstellung quantensicherer Signaturen nutzen. Den Schutz vor Angriffen durch Quantencomputer für Android 17 hatte Google Ende März angekündigt.

Behobene Fehler der Beta von Android 17 hat Google in einem umfangreichen Reddit-Beitrag dokumentiert. Unter anderem fixt Google ein Problem, das dazu führte, dass die Ladegeschwindigkeit von Geräten deutlich abnahm, sobald die 80-Prozent-Marke der Akkuladung erreicht wurde. Dieser Bug steckt auch in Android 16 QPR3.

Wagemutige und Entwickler können die Beta auf kompatiblen Pixel-Geräten installieren. Zu diesen gehören alle Modelle ab dem Pixel 6 und neuer als auch das Pixel Tablet sowie Googles Foldables. Um die Beta zu erhalten, müssen Nutzerinnen und Nutzer ihr Gerät im Android-Betaprogramm registrieren, anschließend wird die Software als Over-the-Air-Update angeboten.

Weitere Neuerungen von Android 17 dürfte Google im Zuge der Entwicklerkonferenz I/O 2026 verraten, die am 19. und 20. Mai stattfindet. Als gesichert gilt, dass Google seinem mobilen Betriebssystem agentische Fähigkeiten verleihen wird, die Nutzern mehrstufige Aufgaben abnehmen sollen. Der Chef des Android-Ökosystems Sameer Samat sagte dazu: „Wir bewegen uns weg von einem Betriebssystem hin zu einem intelligenten System, einer Plattform, die Sie wirklich versteht und für Sie arbeitet.“ Die finale Version von Android 17, zunächst für Pixel-Geräte, wird im Juni erwartet.

(afl)

Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind. Der Sammelbegriff „Shared Library“ steht in den Artikeln gleichermaßen für eine Shared Library unter Unix wie für eine Windows-DLL.

Der Ausgangspunkt der Arbeit mit FFM war meine Suche nach einem Weg, per Java auf ein Hardware-Sicherheitsmodul (HSM) zuzugreifen. Da aber noch kein physisches HSM vorhanden war, suchte ich nach einer softwaregestützten Umsetzung. Die Applikation SoftHSM2 lässt sich mit PKCS11 ansprechen, aber der Pkcs#11-Treiber von Sun ist veraltet. Da ich keine passende Open-Source-Anwendung gefunden habe, entwickelte ich selbst einen PKCS11-Wrapper für Java auf Basis der FFM-API.

Da das Projekt sehr umfangreich ist, steht für diese dreiteilige Artikelserie eine eigens entwickelte C-Library im Fokus, die dazu dient, die Konzepte der FFM-API zu erläutern. Die kleine Demo-Library ist auf Windows und Linux getestet.

Ein wenig Historie

In Java gab es vor dem FFM mit dem Java Native Interface (JNI) seit Langem einen Weg, um auf in C geschriebenen Code zuzugreifen. Das JNI war allerdings sehr kompliziert und fehlerbehaftet.

Daher begannen im JDK 14 (Java Development Kit) die Arbeiten an einer neuen Schnittstelle: Foreign Function & Memory API. Die Java-Community hat sie über einige JDK-Versionen und JEPs hinweg verfeinert und schließlich in JDK 22 finalisiert. Allerdings erschien sie im JDK 24 nochmals in veränderter Form. Wegen einiger Breaking Changes ist die API aus Java 24 nicht zu der in Java 22 kompatibel. Dieser Artikel beschreibt die aktuelle Version aus dem JDK 24.

Um die FFM-API zu nutzen, gelten folgende Voraussetzungen:

• Ein JDK ab Version 24 muss installiert sein.
• Das Betriebssystem muss Windows oder Linux auf x64-Basis sein. Die Demo-App sollte auch unter macOS funktionieren, wozu ich aber keine Tests durchgeführt habe.
• Eine Windows-DLL oder eine Shared Library für Linux in 64-Bit-Version muss vorhanden sein.
• Die DLL beziehungsweise Shared Library muss in einer Sprache geschrieben sein, die die C-ABI (Application Binary Interface) unterstützt. Dazu gehören neben C und C++ (mit passend deklarierten Funktionen) auch weitere Sprachen wie Rust und Go.
• Beim Zugriff auf die Shared Library muss man den Native Access erlauben. Das ist aktuell noch ohne Einschränkungen möglich, was sich in einer späteren Java-Version ändern könnte.

Beschreibung der DemoLib

Der Ausgangspunkt für FFM ist immer eine Header-Datei, die in C die Funktionen und gegebenenfalls Typen der Shared Library beschreibt.

Die in C entwickelte Beispiel-Library enthält nur wenige Funktionen und einen Datentyp:

#ifdef _WIN32
  #define EXPORT __declspec(dllexport)
#else
  #define EXPORT
#endif

typedef struct 
{
  double x;
  double y;
} Point;


#define VERSION 1

EXPORT void   initialize(void);
EXPORT int    getVersion(void);
EXPORT void   getVersion2(int *version);
EXPORT long   add(long a, long b);
EXPORT double calcAverage(int *lvalues, int size);
EXPORT double distance(Point *p1, Point *p2);

Es gibt nur eine einzige Typdefinition (Point) und wenige Funktionen. Die Direktive #ifdef im Header-File sorgt dafür, dass sich der Code sowohl unter Linux als auch unter Windows kompilieren lässt.

Toolanbindung mit Stolperfallen

Das Tool jextract hilft beim Zugriff auf native Funktionen. Ausgangspunkt ist auch hier wieder eine Header-Datei, um die notwendigen Zugriffsmethoden für die Funktionen aus der Shared Library zu erzeugen.

jextract kämpft jedoch mit diversen Schwierigkeiten. Zunächst ist es nicht für jedes JDK verfügbar – nach JDK 22 erst wieder für JDK 25. Für die Demo-Library zum Artikel hat die Version aus JDK 22 zwei Klassen generiert: Point für den Zugriff auf die Datenstruktur und DemoLib_h, um auf die Funktionen zuzugreifen. Die Klasse Point hat einen Umfang von etwa 170 schlecht leserlichen Codezeilen, und die Klasse DemoLib_h hat weitere 390 Zeilen Code, die ebenfalls schwer lesbar sind.

Bei komplexen Header-Files ist der Einsatz von jextract noch schwieriger. Beim Versuch, einen Wrapper für PKCS11 zu erzeugen, brach jextract im Zusammenspiel mit dem JDK 22 ab. Die Header-Datei pkcs11.h lädt zwei weitere Header-Dateien nach. Das führte zum Abbruch mit Fehlermeldungen, dass inkompatible Typ-Redefinitionen vorhanden seien.

jextract ist derzeit nur für kleine Projekte einsatzbereit – und auch das mit Einschränkungen. Aufgrund des schwer lesbaren Codes ist es keine Vorlage für eigenen Code. Daher ist der deutlich bessere Ansatz, den Code selbst zu entwickeln und das entsprechende Know-how aufzubauen, um den Code zu verstehen.