Google hat seine „Continue On“-Funktion im Rahmen der I/O-Session „What’s new in Android“ angekündigt und sie auf der Entwicklerseite näher erläutert. Sie ist Teil von Android 17 und soll Nutzerinnen und Nutzer ermöglichen, eine App auf einem Android-Gerät zu starten und dann auf ein anderes Gerät in ihrem Android-Ökosystem zu wechseln, um die begonnene Aufgabe fortzusetzen.

Continue-on: Handoff für Android

Wie der Entwickler auf seiner Developer-Webseite erläutert, ist „Continue On“ für den bidirektionalen Einsatz konzipiert. Das heißt, dass jedes unterstützte Android-Gerät sowohl App-Aktivitäten senden als auch empfangen kann, dabei müssen die Geräte jeweils mit dem gleichen Google-Konto verknüpft sein.

Mit dem Release von Android 17, der im Laufe der kommenden Wochen erwartet wird, soll „Continue On“ zunächst den Übergang von Smartphones zu Tablets unterstützen. Dabei werde in der Taskleiste des Tablets ein Vorschlag für die zuletzt auf dem Smartphone geöffnete App angezeigt. Über diesen können Nutzer die App mit einem Fingertipp starten und dort weitermachen, wo er oder sie aufgehört habe.

Als Beispiel nennt Google etwa die Möglichkeit, dasselbe Dokument in Google Docs, das man zuerst auf dem Smartphone genutzt hat, auf dem Tablet zu öffnen und daran weiterzuarbeiten. Ein weiteres Beispiel zeigt, dass die Übergabe auch mit einem Webbrowser funktioniert: Eine E-Mail in Gmail wird an Chrome auf einem Tablet weitergeleitet, wo sie direkt geöffnet wird.

Trotz der anfänglichen Einschränkungen ähnelt der Ansatz stark Apples „Handoff“-Funktion, mit der iPhone-Nutzer Aufgaben nahtlos auf das iPad oder den Mac übertragen können. Apple hatte dieses Feature schon 2014, also vor über 10 Jahren, eingeführt. Im Hinblick auf Googles baldigen Marktstart der im Zuge der Android Show: I/O Edition angekündigten Googlebooks auf Android-Basis, dürfte die Funktion auch auf dieser neuen Gerätegattung landen, um das Ökosystem zu stärken.

Entwickler müssen handeln

Erste Informationen zur Handoff-Funktion veröffentlichte Google schon im Februar dieses Jahres in der Dokumentation zu Android 17 im Punkt „Funktionen und APIs“.

Damals erklärte Google, dass die Handoff-Funktion im Hintergrund auf dem Gerät eines Nutzers ausgeführt wird. Das Unternehmen schreibt in der Dokumentation: „Die Handoff-Unterstützung wird auf Basis einzelner Aktivitäten implementiert.“ Um Handoff zu aktivieren, müssen Entwickler die Methode setHandoffEnabled() für die Aktivität aufrufen. „Möglicherweise müssen zusätzliche Daten zusammen mit der Übergabe übermittelt werden, damit die neu erstellte Aktivität auf dem empfangenden Gerät den entsprechenden Status wiederherstellen kann. Implementieren Sie den Rückruf onHandoffActivityRequested(), um ein HandoffActivityData-Objekt zurückzugeben, das Details enthält, die angeben, wie Handoff die Aktivität auf dem empfangenden Gerät verarbeiten und neu erstellen soll.“

(afl)

Hannes Mühleisen ist Mitschöpfer von DuckDB und CEO von DuckDB Labs. Zusammen mit Mark Raasveldt hat er DuckDB ursprünglich als Forschungssprojekt am Centrum Wiskunde & Informatica (CWI) Amsterdam ins Leben gerufen.

Golo: Hannes, du bist einer der Mitschöpfer von DuckDB und Mitgründer von DuckDB Labs. Als DuckDB im Sommer 2024 in Version 1.0 erschienen ist, habe ich für heise darüber berichtet – und seitdem ist viel passiert. Bevor wir in die Details gehen, würde ich gerne ganz am Anfang beginnen: DuckDB hat seine Wurzeln in eurer Forschung am CWI in Amsterdam, wo du und Mark Raasveldt jahrelang an Datenbank-Internas gearbeitet habt. Was war der Moment (oder die Lücke), an dem ihr beide entschieden habt, dass die Welt tatsächlich noch eine weitere Datenbank benötigt, und was sollte sie ursprünglich sein?

Hannes: Wir haben damals recht eng mit Statistikern zusammengearbeitet, die große Umfragedaten auswerten mussten. Für uns war klar, die brauchen Datenbank-Technologie! Aber als wir das vorgeschlagen haben, haben die gesagt, dass sie eigentlich keine Lust auf eine Datenbank im klassischen Sinne haben. Es war zum Beispiel vor Docker nicht einfach, eine Datenbank lokal zu installieren, ohne Experte zu sein. Außerdem konnte man den Zustand der Datenbank auch nicht ohne weiteres mit jemand anderem teilen.

Es war klar, dass eine neue Architektur notwendig ist, ein eingebettetes analytisches Datenbanksystem. Das gab es damals noch gar nicht. Es war recht schnell klar, dass wir eine komplette Neuentwicklung brauchten – ein sauberes Design, das auf das eingebettete Einsatzmodell zugeschnitten war, mit einer modernen Systemarchitektur.

Im Sommer 2018 beschlossen wir, dies in die Tat umzusetzen, und begannen mit der Implementierung von DuckDB.

Der Begriff „SQLite for Analytics“ haftet DuckDB schon seit Jahren an. Er bringt vieles in nur drei Worten auf den Punkt, kann aber auch reduzierend wirken. Wie treffend findest du dieses Framing aus deiner heutigen Sicht, und wo greift es zu kurz?

Hannes: „SQLite für Analytics“ war in den ersten fünf Jahren eine treffende Beschreibung des Projekts. Im Laufe der Zeit haben wir einen leistungsfähigen Erweiterungsmechanismus hinzugefügt, der die Arbeit mit nahezu jedem Dateiformat wie Parquet, JSON oder Iceberg und vielen gängigen Speicheroptionen, zum Beispiel S3-API, ermöglicht. Deshalb haben wir begonnen, DuckDB als universelles Datenwerkzeug zu bezeichnen.

Das ist vielleicht weniger einprägsam als die ursprüngliche Beschreibung, erfasst aber, dass das System inzwischen wesentlich vielseitiger ist. Und wenn man ein SQLite für Analytics braucht, kann man DuckDB nach wie vor dafür verwenden.

Jenseits von Big Data

Du vertrittst seit einiger Zeit die Position, dass verteilte Systeme für die allermeisten analytischen Workloads schlicht überdimensioniert sind – und dass eine einzelne moderne Maschine deutlich mehr leisten kann, als die Branche meist annimmt. Das ist ein Argument, das ich auch in einem ausführlichen iX-Test aufgegriffen habe, in dem ich DuckDB als schlanke Alternative zu Apache Spark positioniert habe. Magst du diese These in deinen eigenen Worten machen? Und wie reagierst du auf Leute, die dich daraufhin sofort dafür kritisieren, ihr Problem zu unterschätzen?

Hannes: Mein Argument stützt sich auf drei Säulen. Erstens: Die Hardwareentwicklung hat große Fortschritte gemacht, und moderne Computer sind erstaunlich leistungsfähig. Heute wird ein leistungsstarker Laptop mit einem Dutzend schneller CPU-Kerne, mehreren zehn Gigabyte Arbeitsspeicher und einer schnellen SSD mit Terabytes an Speicherplatz ausgeliefert. Ein Server kann leicht das Zehnfache und mehr bieten.

Zweitens: Das Feld der Datenbankarchitektur hat sich seit 2010 – als Big Data aufkam – erheblich weiterentwickelt. Wir konnten auf Ergebnisse zu spaltenbasierter Speicherung, vektorisierter Abfrageverarbeitung, Parallelität und Nebenläufigkeitskontrolle aufbauen. Darüber hinaus haben wir eigene Forschung zu Themen wie Kompression und Operatoren für Datenmengen, die den Arbeitsspeicher übersteigen, betrieben.

Drittens: Was die meisten nicht bedenken – auch wenn eine Organisation auf Petabytes an Daten sitzt, muss man nie alle Daten in einer einzigen Abfrage verarbeiten. Dafür gibt es inzwischen belastbare Belege: In den letzten Jahren haben sowohl Snowflake als auch Redshift Stichproben und Statistiken ihrer Benutzerabfragen veröffentlicht – wahre Fundgruben, um reale Workloads zu verstehen. George Fraser von Fivetran hat eine hervorragende Analyse dazu vorgestellt, in der er zeigt, dass selbst unter den Abfragen auf Snowflake und Redshift das 99,9-Perzentil etwa 300 GB scannt und somit problemlos auf einem einzelnen Knoten laufen könnte.

Performance ist einer der auffälligsten Aspekte von DuckDB – viele Erstanwender beschreiben ihre erste Erfahrung mit den Worten „das kann nicht stimmen, lass mich das Ergebnis nochmal prüfen“. Welche architektonischen Entscheidungen sind dafür aus deiner Sicht am wichtigsten, und welche davon sind für Außenstehende nicht offensichtlich?

Hannes: Wir haben bereits über die Entscheidung für eine Einzelknoten-Architektur gesprochen, die verschiedene Arten von Overhead in Implementierung, Betrieb und Leistung eliminiert. Aber es gibt auch einige nicht triviale architektonische Entscheidungen.

Wir haben uns für vektorisierte Ausführung statt JIT-Kompilierung entschieden, weil sie perfekt für analytische Workloads und langfristig deutlich einfacher zu warten ist. Wir haben keine GPUs oder exotische Hardware wie KI-Beschleuniger eingesetzt, sondern all unsere Energie darauf verwendet, die effizientesten Algorithmen für die CPU zu schreiben. Und schließlich haben wir bei der Implementierung dieser Algorithmen bewusst auf SIMD-Intrinsics (manuell ausformulierte Vektorbefehle) verzichtet. Stattdessen haben wir skalaren Code geschrieben und den Compiler die Auto-Vektorisierung übernehmen lassen. Das Ergebnis ist hoch portabler und zugleich leistungsfähiger Code.

Darüber hinaus – wie in der vorherigen Frage besprochen – sind viele aktuelle Forschungsergebnisse in DuckDB eingeflossen. Die Verarbeitung von Datenmengen, die den Arbeitsspeicher übersteigen, durch Auslagerung auf die Festplatte trägt maßgeblich zur Leistung von DuckDB bei. Die meisten modernen Datenbanksysteme können auf die Festplatte auslagern, aber wenn sie es tun, erleben sie einen Performance-Absturz. DuckDB nutzt moderne Flash-basierte Speicher, um dies wesentlich eleganter zu handhaben – oft bemerken die Benutzer kaum, dass ihre Abfragen auf die Festplatte ausgelagert wurden.

Das Ökosystem

Die Reichweite von DuckDB in die Python- und R-Communities, in Node.js, in alle möglichen Tools und Notebooks ist bemerkenswert. War diese Ökosystem-Strategie von Anfang an bewusst gewählt, oder ist sie entstanden, weil die Leute DuckDB in ihre Workflows hineingezogen haben?

Hannes: Man muss die Anwender natürlich da abholen, wo sie sind. Am Anfang stellten wir uns vor, dass DuckDB für Data-Science-Workloads genutzt werden würde, und das bestimmte die erste Auswahl an Clients. Wir brauchten natürlich einen Kommandozeilen-Client. Auf der Sprachseite war Python bereits sehr stark, und wir hatten enge Verbindungen zur R-Community, also entschieden wir uns, diese Clients zuerst zu implementieren.

Node.js folgte bald darauf. Als DuckDB wuchs, begann die Community eigenständig Clients zu entwickeln. Das ermöglichte es uns, deren Akzeptanz zu beobachten, bevor wir die Arbeit des Kernteams in fünfzehn verschiedene Treiber investierten. Zum Beispiel wurde der DuckDB-Go-Treiber zunächst von Marc Boeker implementiert, der den Code später an die DuckDB Foundation übergab.

Der Extension-Mechanismus wirkt wie eine eher leise, aber sehr folgenreiche Designentscheidung. Er erlaubt DuckDB, Formate zu lesen, für die es nicht gebaut wurde, mit Object Stores zu arbeiten und sogar mit anderen Datenbanken zu sprechen. Wie denkst du über die Grenze zwischen dem, was in den Kern gehört, und dem, was in einer Extension besser aufgehoben ist?

Hannes: Wir sehen, dass DuckDB in ressourcenbeschränkten Umgebungen eingesetzt wird – Einplatinencomputer, Browser-Tabs, Container mit begrenztem Arbeitsspeicher. Um diesen Einsatz zu ermöglichen, wollen wir den Kern von DuckDB kleinhalten und nur das Wesentliche einbauen: den SQL-Parser, die Datenbank-Engine, die Speicher-Engine, den CSV-Reader – und den Erweiterungsmechanismus. Die meisten anderen Funktionen wie der Parquet-Reader oder sogar HTTPS-Unterstützung stehen als Erweiterungen zur Verfügung.

Ein schöner Nebeneffekt dieses leistungsfähigen Erweiterungsmechanismus ist, dass unsere Community eigene Erweiterungen bauen kann. Derzeit gibt es mehr als 180 Community-Erweiterungen für DuckDB, die jeweils neue Funktionen ins System bringen und sich mit einer einzigen Zeile installieren lassen.

Die Maintainer des quelloffenen Content-Management-Systems Drupal haben angekündigt, am Abend des Mittwochs, 20. Mai 2026, ein hochkritisches Sicherheitsupdate für Drupal Core veröffentlichen zu wollen. IT-Verantwortliche sollten es zeitnah installieren.

In der Vorankündigung des Sicherheitspatches schreibt das Drupal-Sicherheitsteam, dass die Aktualisierung zwischen 19 und 23 Uhr hiesiger Zeit erscheinen soll (17:00-21:00h UTC). Die Entwickler weisen darauf hin, dass Admins sich dringend die Zeit für das Anwenden des Drupal-Core-Updates nehmen sollten, da Exploits innerhalb von Stunden oder Tagen nach der Veröffentlichung des Fixes entwickelt werden könnten.

Immerhin, es sollen nicht alle Drupal-Konfigurationen gleichermaßen betroffen sein. Zu den Einschränkungen schreiben die Programmierer noch nichts, jedoch sollen Admins zum Zeitpunkt der Veröffentlichung prüfen, ob ihre Instanzen betroffen sind und ein sofortiges Update benötigen.

Updates nur für unterstützte Versionen

Die Aktualisierungen soll es eigentlich nur für die noch unterstützten Drupal-Core-Versionen 11.3.x, 11.2.x, 10.6.x und 10.5.x geben. Als Ausnahme kommen nun jedoch auch Patches für Drupal Core 11.1.x und 10.4.x hinzu, obwohl die bereits am Ende des Produkt-Supportzyklus angelangt sind. Als Begründung nennen die Entwickler den Schweregrad des Problems. Selbst für Drupal Core 9.5 und 8.9 legt das Sicherheitsteam korrigierte Software bereit.

Damit sich die Updates anwenden lassen, sollen Installationen mit Drupal Core 11.1 und 11.0 auf den Stand 11.1.9 aktualisiert werden, die Entwicklungszweige 10.4, 10.3, 10.2, 10.1 und 10.0 hingegen benötigen zuvor den Stand 10.4.9. Für die noch älteren Fassungen sind Drupal Core 9.5.11 und 8.9.20 Voraussetzung. Wer noch Drupal Core 7 einsetzt, ist von dem konkreten Problem nicht betroffen.

Am heutigen Abend soll die Verfügbarkeit des Sicherheitsupdates dann auf der Sicherheitsseite von Drupal sowie in den sozialen Medien angekündigt werden. Drupal-Core-Admins sollten in dem Zeitraum regelmäßig prüfen, ob das Update verfügbar ist, und es umgehend anwenden.

(dmk)