Praxisbericht ⑥: Eine stillgelegte Android-App mit KI wiederbeleben

KI-Fallbeispiele

„Die App läuft. Nur die Benachrichtigungen kommen seit Jahren nicht mehr an.“ So begann die Anfrage. Eine Android-App für einen mitgliederbasierten B2C-Dienst. Sie stand im Store und startete auch, doch irgendwann ging keine einzige Push-Benachrichtigung mehr hinaus. Diesmal haben wir eine „unberührbare“ mobile App — ohne die Menschen, die sie gebaut hatten, ohne Dokumentation — genommen und sämtliche Mitgliederbestände und den Signaturschlüssel lückenlos übernommen und sie mit KI neu gebaut. Das ist der Bericht darüber.

Das gefährlichste Altsystem ist nicht die App, die abstürzt.
Es ist die App, die nie abstürzt, während ausgerechnet ihre wichtigste Funktion still stehen bleibt.

Unter dem „läuft doch“ waren die Benachrichtigungen seit Jahren tot.

Was diese App wirklich war: eine native Hülle, die einen bestehenden Webdienst anzeigt — ein WebView-Wrapper plus Push-Benachrichtigungen. Die Oberflächen nutzten vorhandene Web-Bestände weiter und waren daher intakt. Das Problem waren die Benachrichtigungen: Der Versandmechanismus hing an einer Zustellplattform der vorigen Generation, und in dem Moment, in dem diese Plattform eingestellt wurde, verschwand der Zustellweg selbst. In der Datenbank war nur eine Spalte für die Tokens des neuen Verfahrens ergänzt worden, in die nie etwas geschrieben wurde — die Leitung blieb auf halber Strecke gekappt liegen.

ca. 14.000registrierte Geräte (gesamt)
ca. 3.200Android-Geräte
2016Ausstellungsjahr des vorhandenen Signaturschlüssels
einmalnötige Neuveröffentlichungen

Achtzig Prozent von „unberührbar“ waren in Wahrheit die Angst vor dem Neubau.

Die Wand, gegen die wir tatsächlich liefen, war weniger schwieriger Code als die Angst vor der Übernahme. Gerade bei Android macht ein einziger Fehltritt daraus eine andere App, die bestehende Nutzer nicht aktualisieren können.

Die Versandplattform für Benachrichtigungen war mitsamt ihrer Generation verschwundenKommunikationswegDer Zustelldienst der vorigen Generation war abgeschaltet, auf der Senderseite existierte kein Weg mehr. Wir mussten zuerst auf einen „modernen Weg“ umziehen.
Weder die Erbauer noch Entwurfsunterlagen vorhandenAnwendungGeblieben war allein alter Quellcode. Ein KI-Agent las die Struktur aus, wir erfassten das Gerüst — Hülle + WebView + Benachrichtigungen — und entwarfen erst dann neu. Nicht bei null anfangen, sondern das Vorhandene verstehen und neu bauen — so sind wir vorgegangen.
Ohne den Signaturschlüssel kann kein einziger Nutzer aktualisierenAnwendungUnter Android kommt nur ein mit demselben Signaturschlüssel signiertes Paket als „Update“ an. Wir haben den vor rund zehn Jahren, 2016, ausgestellten Schlüssel aufgespürt, übernommen und bestätigt, dass der Fingerabdruck des Zertifikats exakt übereinstimmt — damit war die Auslieferung als Update statt als Neuinstallation gesichert.
Die Registrierungs-API setzte verschlüsselte Kommunikation vorausKommunikationswegDer alte Server war so konfiguriert, dass er Klartextverbindungen abwies; daran scheiterte ein Großteil der Geräteregistrierungen. Statt die Prüfung abzuschalten und das Problem zu umgehen, haben wir die App-Seite durchgängig auf verschlüsselte Kommunikation umgestellt.
Die Build-Umgebung hielt mit den heutigen Store-Anforderungen nicht mehr SchrittAnwendungDer Store akzeptiert keine veraltete Laufzeitumgebung. Wir hoben den Build-Unterbau (Build-Werkzeug, Sprache, Laufzeitumgebung) auf den aktuellen Stand, bis er ein signiertes Distributionspaket ausgeben konnte.

Wir haben klar getrennt, was bleibt und was neu gebaut wird.

Die Aufgabe lautet nicht „alles neu machen“. Bestände, die sich weiter nutzen lassen, bleiben unverändert im Einsatz. Aufgeschlüsselt sieht das so aus.

PunktBisherNach dem Neubau
Benachrichtigungswegeiner Zustellplattform der vorigen Generation
(eingestellt – Versand nicht möglich)
Auf die aktuelle Zustellplattform (FCM) umgezogen
App-HülleNative Umsetzung einer alten GenerationMit aktueller nativer Umsetzung neu erzeugt
Oberfläche (Inhalt)Zeigt den bestehenden Webdienst anBleibt unverändert (Mitgliederbestände erhalten)
Signaturschlüssel2016 ausgestelltDerselbe Schlüssel übernommen (Auslieferung als Update)
Mitglieder- und GerätedatenRund 14.000 Geräte registriertUnverändert übernommen

Den Neubau selbst hat ein KI-Agent in einem Zug durchgezogen. Die neu gebaute App haben wir auf einem virtuellen Gerät die gesamte Kette Benachrichtigungs-Token abrufen → beim Server registrieren → Benachrichtigung kommt tatsächlich an bis zum Ende durchlaufen lassen und bestätigt, dass der Hin- und Rückweg funktioniert. Das Ergebnis ist ein signiertes, unmittelbar auslieferbares Paket.

Neubau und Neuveröffentlichung so klein wie möglich auslegen.Die Rückkehr der Benachrichtigungen haben wir tatsächlich so vorbereitet, dass sie allein durch die Umstellung auf Serverseite zündet. Die App wird nur einmal neu veröffentlicht; danach lassen sich Benachrichtigungen wieder in Betrieb nehmen, ohne ein einziges Gerät anzufassen — „Nutzer nicht immer wieder um ein Update bitten“ wiegt umso schwerer, je mehr Mitglieder ein Dienst hat.

Die meisten Apps, von denen es heißt, sie liefen nicht mehr, sind kein Totalschaden. Wenn Sie die wenigen gekappten Leitungen und die zu übernehmenden Schlüssel im Griff haben, lässt sich das Vorhandene erhalten und zugleich auf eine moderne Basis zurückholen. Im iOS-Teil (Praxisbericht ⑦) geht es um die andere Plattform, auf der die Mehrheit der Mitglieder liegt, und um das, was für beide Betriebssysteme gilt: Benachrichtigungen modernisieren, ohne den alten Server anzutasten.

* Dieser Beitrag verallgemeinert ein reales Projekt so weit, dass weder Unternehmen noch Dienst identifizierbar sind. Die Zahlen sind Näherungswerte auf Basis von Messungen mit Stand August 2026. Dauer und Umfang der Arbeiten hängen vom Aufbau der jeweiligen App ab.

Kategorie:

Tags:

🌐 Deutsch