Detecting Android Emulator Crashes with Web Push: A Short but Insightful Project

I spent about 6 hours building a small project. The idea itself was simple, but it turned out to be a surprisingly rich technical exercise, so I wanted to write it up and share what I learned.

GitHub repository: https://github.com/shanefully-done/mapleting

Live domain: https://mapleting.vercel.app

Problem Statement

The goal was straightforward:

When running a game on an Android emulator on a PC, if the game process crashes or exits, I want to detect that automatically and receive a notification — without having to constantly check the emulator manually.

In short: detect disconnections and notify proactively.

High-Level Architecture

The system is composed of three main parts:

• A lightweight monitoring program running on the PC

  • Uses ADB to periodically check whether a specific Android package is running

• A server that receives heartbeat and state-change events

  • Tracks status per nickname

• A notification layer

  • Sends push notifications to clients subscribed to a given nickname

At a glance, this sounds trivial. In practice, some parts were much more subtle than expected.

Local Monitoring: The Easy Part

The local monitoring logic was relatively simple.

Using ADB, the client periodically checks process state on the emulator. When a transition occurs (running → stopped), the client reports the event to the server.

This part was mostly about correctness and robustness, not complexity.

Server + Notifications: The Hard Part

The real challenge was notifications.

I chose PWA-based web push instead of native apps, which raised an important question:

Can a web app reliably deliver background notifications like a native app?

To answer that, I had to deal directly with:

• Service Workers

• Push API

• Notification API

And more importantly, how they behave across different operating systems and browsers.

OS and Browser Differences (The Pain Points)

Under the single label of “web push,” behavior varies significantly:

• iOS (Safari ≥ 16.4)

  • Supports PWA push notifications

  • Requires explicit PWA installation

  • UX and permission flows are restrictive

• Android

  • Generally flexible

  • Push delivery can still be affected by browser choice and battery optimizations

• macOS / Windows

  • Permission prompts, background execution, and reliability differ by browser

• Chromium-based browsers (e.g., Brave)

  • Some intentionally block push services by default (e.g., Google FCM)

  • In these cases, users may not even be able to subscribe to push notifications at all

  • The failure is upfront, not silent, but users are often left without clear guidance on how to fix it

This last point was particularly interesting: sometimes the hardest part isn’t handling failures, but explaining why a feature is unavailable in a way users can act on.

Key Takeaway

Even for a small, time-boxed project, building a reliable, state-based notification system across multiple OSes and browsers is non-trivial.

This project forced me to validate assumptions I had about PWAs and push notifications, not just rely on documentation.

Despite the short development time, it was a satisfying exercise in:

• Cross-platform thinking

• Real-world PWA limitations

• Designing systems that fail clearly, not mysteriously

Links