Field Report ⑥: Reviving a stalled Android app with AI

AI case studies

“The app runs. It is only the notifications that have not arrived for years.” That was how the request began. An Android app for a membership-based B2C service. It was published on the store and it launched, yet at some point not a single push notification was going out. This time we rebuilt an “untouchable” mobile app — no original developer, no documentation — while carrying over every member asset and the signing key untouched. This is that record.

The scariest legacy is not an app that crashes.
It is an app that never crashes while its most important feature has quietly stopped.

Beneath “it still runs,” notifications had been dead for years.

What this app really was: a native shell displaying an existing web service — a WebView wrapper plus push notifications. The screens were reused existing web assets, so they were alive. The problem was the notifications. The sending mechanism relied on a previous-generation delivery platform, and the moment that platform reached end of service the route itself disappeared. The database had only a column added for storing tokens of the new scheme, and nothing was ever written to it — the wiring had been left severed halfway.

approx. 14,000registered devices (total)
approx. 3,200Android devices
2016year the existing signing key was issued
oncere-releases required

Eighty percent of “untouchable” was really the fear of rebuilding.

The walls we actually hit were less about difficult code than about the fear of carrying things over. On Android in particular, one wrong move turns it into a different app that existing users cannot update.

The notification delivery platform had disappeared, generation and allCommunication pathThe previous-generation delivery service had shut down, so no sending route existed. We had to start by moving to a modern route.
No original developer, no design documentsApplicationAll that remained was old source code. An AI agent read the structure, we grasped the skeleton — shell + WebView + notifications — and then redesigned. Not from scratch, but understanding the real thing and rebuilding it — that was the approach.
Without the signing key, no user can updateApplicationOn Android, only a build signed with the same signing key arrives as an update. We tracked down the key issued in 2016, about ten years ago, carried it over, and confirmed that the certificate fingerprint matched exactly — securing delivery as an update rather than a fresh install.
The registration API required encrypted communicationCommunication pathThe old server was configured to reject plaintext connections, and this was behind most of the failed device registrations. Rather than disabling verification to get around it, we standardised the app on encrypted communication.
The build environment had not kept up with current store requirementsApplicationThe store will not accept an old runtime. We raised the build stack — build tool, language, runtime — to current versions so that it could produce a signed distribution package.

We drew a clear line between what to keep and what to rebuild.

The job is not to make everything new. Assets that still work are kept as they are. Broken down, it looks like this.

ItemBeforeAfter the rebuild
Notification routea previous-generation delivery platform
(discontinued — cannot send)
Moved to the current delivery platform (FCM)
App shellAn old-generation native implementationRegenerated with a current native implementation
Screens (contents)Displays the existing web serviceContinues unchanged (member assets preserved)
Signing keyIssued in 2016Same key carried over (delivered as an update)
Member and device dataApprox. 14,000 devices registeredCarried over unchanged

The rebuild itself was driven straight through by an AI agent. On an emulator we ran the rebuilt app through obtaining a notification token → registering it with the server → an actual notification arriving from end to end, confirming that the round trip worked. The output is a signed package ready for distribution.

Design the rebuild and the re-release to be as small as possible.Reviving notifications can in fact be triggered by the server-side switch alone, and we prepared it that way. The app is re-released once, and from then on notifications can be brought back into operation without touching any device — not asking users to update over and over matters more the larger the membership.

Most apps described as broken are not a total loss. As long as you secure the few severed wires and the keys that must be carried over, you can bring the real thing back onto a modern platform without discarding it. In the iOS instalment (Field Report ⑦) we cover the other platform, where most members are, and the story common to both operating systems: modernising notifications while leaving the old server in place.

* This article generalises a real project to the extent that no company or service can be identified. Figures are approximate, based on measurements as of August 2026. Duration and scope of work vary with the structure of the app.

Category:

Tags:

🌐 English