DEV Community: Rao Asad

I wrote my own document scanner and PDF engine for Android. Here's what that involved

Rao Asad — Mon, 19 Oct 2026 13:00:00 +0000

There are already great ways to add document scanning to an Android app. Google's ML Kit has a ready-made scanner screen, OpenCV can find a page in a few lines, and plenty of libraries write PDFs.

For Keepscan, I used none of them for the core. The page detection, the camera screen, the perspective correction and the PDF writer are all plain Kotlin on top of platform APIs. The only ML library in the app is on-device text recognition, for copying text out of a scan.

That wasn't purity. A scanner app is its engine, and I wanted to be able to change any part of it later without waiting on someone else's roadmap. Here's what building it involved, and the parts that surprised me.

Finding the page: lines, not contours

The classic tutorial approach is: edge detection, find the largest closed contour with four corners, done. It works beautifully on a clean page on a dark desk.

Real photos aren't like that. A thumb covers a corner, a shadow falls across an edge, a white page sits on a light table. Any gap breaks the contour, and the page is lost.

So Keepscan looks for straight lines instead, and assembles the page from them:

Shrink the frame to 256 px on its long side and blur it. Page edges survive easily; text strokes and paper texture mostly don't.
Canny edge detection: Sobel gradients, thinned to one-pixel ridges, strong ones kept.
A Hough transform turns edge pixels into line candidates. A line survives gaps that would break a contour.
Try every pair of roughly horizontal lines against every pair of roughly vertical ones, and score each quadrilateral.

Two details made the difference.

Rank each direction separately. Rows of text produce lots of strong horizontal lines. Ranked together, they crowd out the page's vertical edges entirely. Keeping the top 10 of each direction fixed that.

Score like a page, not like a line. A pen lying on the desk is a long straight edge too. What a pen doesn't have is paper on one side and desk on the other. So each side of a candidate is sampled at 48 points, and a point only counts if it sits on an edge pixel and there's a consistent brightness step across it: the page side brighter (or darker) than the outside, with the same polarity along the whole side. The weakest side weighs heavily in the score, because three good sides and one fake one isn't a page.

val support = (total / 4) * 0.6f + weakest * 0.4f
return support * (0.55f + 0.45f * sqrt(q.area()))   // bigger pages get a modest bonus

One more refinement: Hough lines are quantised to whole degrees, and over a page-length edge a fraction of a degree moves the ends by several pixels, enough for the scorer to sample beside the real edge. So each winning line is refitted to the edge pixels within 2 px of it with a total least-squares fit (the direction of least spread in their covariance). That puts it exactly on the edge.

All of this is pure functions on plain IntArrays, so it runs identically on a camera frame, a gallery photo and a unit test.

Making it feel steady

Per-frame detection flickers. A tracker sits between the detector and the screen:

A new outline only replaces the shown one after it's been seen twice in a row, so one odd frame doesn't make the overlay jump. Small movements are eased rather than snapped.
A few missed frames keep the last outline, so a passing shadow doesn't blink it away.
It reports how long the page has held still. Auto-capture fires after 1.1 seconds of stillness.

Flattening the page

Once you have four corners, the platform already has what you need: Matrix.setPolyToPoly with four point pairs is a full perspective transform. The output keeps the page's real proportions (width from the longer of the top and bottom edges, height from the longer side), so a receipt stays receipt-shaped instead of being stretched to A4.

Writing PDFs by hand

Android has PdfDocument, and I started with it. The problem: it re-encodes bitmaps losslessly. A phone scan came out at several megabytes per page, and no quality setting could shrink it.

A PDF page that's just an image is a small amount of structure around the image bytes, and PDF can embed a JPEG as-is with the /DCTDecode filter. So Keepscan writes the file itself: catalog, page tree, and for each page a page object, a one-line content stream that draws the image, and the JPEG bytes untouched.

val content = "q ${w} 0 0 ${h} 0 0 cm /Im0 Do Q\n"   // scale the image to the page, draw it
stream("<< /Type /XObject /Subtype /Image /Width ${page.widthPx} /Height ${page.heightPx} " +
       "/ColorSpace /DeviceRGB /BitsPerComponent 8 /Filter /DCTDecode /Length ${jpeg.size} >>", jpeg)

The file ends up the size of its images, which is what the size presets promise. Each page is sized so its long side matches A4's (842 pt), keeping the scan's own aspect ratio.

"Exactly under 2 MB"

Upload forms love hard limits: "max 2 MB". So Keepscan can save a PDF that's the best quality that still fits under a size you pick.

There's no formula from settings to file size; it depends on what's on the pages. So there's a ladder of resolution and JPEG-quality pairs, and the exporter binary-searches it: render at the middle rung, check the size, go up or down. A long document is rendered a few times instead of once per rung. Each attempt is written to a file rather than held in memory, because a 30-page document at a high rung is large. If even the smallest rung is too big, you get that file plus an honest "didn't fit".

Password-protected PDFs without a PDF library

I added PDFBox for encryption, then removed it the same day. It was a big dependency for one feature. Keepscan only ever needs to encrypt its own files, never open someone else's, and that turns out to be a well-specified, contained job.

It's the PDF Standard security handler, revision 6 (AES-256), from ISO 32000-2, written on javax.crypto:

One random 256-bit file key encrypts every stream with AES-256-CBC and a random IV in front.
The user password unlocks that key.
The owner password also unlocks it, so it's generated randomly and thrown away. There's no second, hidden way into the file.

The bugs a real phone found

Two came only from testing on an actual device:

Camera callbacks after close. Leaving the scanner the moment it opened crashed with "CameraDevice was already closed". The screen closes the camera on the main thread while Camera2 callbacks are still arriving on the camera thread. The fix is a generation counter: every open() increments it, and every callback checks it still belongs to the current opening before touching anything.

The crop handles you couldn't drag. On my Xiaomi, dragging a corner near the screen edge triggered the system back gesture instead. setSystemGestureExclusionRects is the documented fix, and HyperOS ignores it. I moved the handles 40 dp inward instead. It's less elegant, and it works on every phone.

Was it worth it?

It took longer than wiring up libraries would have. But every piece of the pipeline is now code I can read, test and change, and the APK doesn't carry an image-processing library for one screen.

Keepscan is on Google Play: free to scan, edit and share with no watermark, and Pro is a one-time payment. If you've built something similar and solved detection differently, I'd like to hear how.

Turning bank notifications into expenses on Android, without a bank login

Rao Asad — Tue, 13 Oct 2026 13:00:00 +0000

Every time I pay for something, my bank sends a notification: "You spent Rs. 1,250 at ‚Ä¶". The expense tracker on the same phone has no idea it happened, and later I'm expected to type it in by hand.

That gap is the reason Onetap exists. You pick which banking or wallet apps it should watch, and when one of them posts a payment notification, it becomes an expense entry. There's no bank login and no bank API. It only reads notifications you already get, from apps you chose.

It sounds like a weekend feature. It took a lot longer, mostly because of what has to happen before any text leaves the phone. Here is how it works and what I got wrong along the way.

1. Listen to everything, read almost nothing

The entry point is a NotificationListenerService. Once the user grants notification access, Android hands it every notification on the phone: chats, emails, OTPs, all of it.

So the very first thing the handler does is look at the package name, and nothing else:

fun onPosted(context: Context, sbn: StatusBarNotification) {
    val packageName = sbn.packageName ?: return
    if (packageName == context.packageName) return
    scope.launch {
        // Only apps the user explicitly added. Nothing else about any
        // other notification is ever read.
        if (!bankApps.contains(packageName)) return@launch
        capture(sbn)
    }
}

A WhatsApp message is dropped before its text is ever touched. I considered auto-detecting finance apps instead, but an explicit list is easier to explain and easier to trust.

Then a few cheap filters: group summaries repeat their children, and ongoing, foreground-service and progress notifications are status, not events. All of those are skipped.

2. One-time codes are never stored or sent

Banking apps send OTPs through the same channel as payment alerts, and an OTP is the most sensitive thing a phone receives. Those are dropped on the device, before anything is saved.

The naive check ("does it contain 'OTP'?") is wrong in both directions:

Lots of real payment alerts end with "Never share your OTP with anyone." A keyword check throws those away.
"Rs 5000" is a 4-digit number, but it's an amount, not a code.

So a message counts as a one-time code only when both are true: it names a code (OTP, verification code, MPIN‚Ä¶) outside a safety reminder, and it contains a bare 4‚Äì8 digit number that isn't preceded by a currency mark.

fun isOneTimeCode(text: String): Boolean {
    val lower = text.lowercase(Locale.ROOT)
    val withoutReminders = lower.replace(REMINDER, " ")   // "never share your otp‚Ä¶"
    if (!CODE_WORD.containsMatchIn(withoutReminders)) return false
    return BARE_NUMBER.findAll(lower).any { number ->
        val before = lower.substring(maxOf(0, number.range.first - 6), number.range.first)
        !CURRENCY_BEFORE.containsMatchIn(before)          // "rs 5000" is money
    }
}

It's all pure functions, so every real notification that ever confused it became a unit test.

3. Mask account numbers before anything leaves

The text of a payment alert does need to be read by a language model: bank formats vary far too much for regexes alone. But the model doesn't need your card number. Card, account, IBAN and phone numbers are masked on the phone first, keeping the last four digits:

Before: Rs 2,000 sent from a/c 01234567890123 to 0300 1234567
After:  Rs 2,000 sent from a/c ****0123 to 0300 1234567

Wait, the phone number survived. That's the interesting part: the rules have to mask long identifiers without masking amounts, dates or times. What I settled on:

9 or more digits written together ‚Üí masked
12 or more digits in groups of 3+ separated by spaces or dashes (4111 1111 1111 1234) ‚Üí masked
IBAN-shaped strings ‚Üí masked
1,250,000 (commas) and 15-09-2026 14:32 (short groups) ‚Üí left alone

A local 11-digit phone number written as 0300 1234567 is two groups, so it isn't caught by the grouped rule. Written as 03001234567 it is. That's a known gap I'd rather tell you about than hide. Every rule is a test case, and each new bank format adds more.

4. Don't let the model guess what it can't know

The model gets the masked text plus the user's categories, and returns structured JSON: amount, merchant, category, date. That part works well.

What went wrong was currency. A real alert read "You spent Rs. 5,930.18" and was recorded as $62.00 in a USD list. The model had been asked which currency "Rs" was, and it said INR. The correct answer was Pakistani rupees: $21.40.

"Rs" is written by Pakistan, India, Sri Lanka and Nepal. The model was reading the same two characters I was, with no extra information. Its answer looked like knowledge and was really a coin flip. I'd even written a function that refused to trust it, and then the very next line fell back to the model's answer anyway.

The lesson I took: a model's answer to an ambiguous question isn't evidence. Tie-breakers have to come from something that actually knows. For a rupee, that's the list's own currency, then the SIM's country (not the phone's language: my phone runs English on a Pakistani SIM). And if nothing knows, ask the user rather than guess.

For now I've gone further and switched conversion off: Onetap records the amount the alert states, in the list's currency, and you keep a rupee bank on a rupee list. The cleaner fix, which I haven't built yet, is binding each bank app to its own list, so conversion is never needed in the first place.

5. Never lose a payment

A notification shows up once. If the app drops it, that payment is gone from the record and the user won't know. So:

Write to disk first. Each kept notification goes into an encrypted inbox before any network call.
Retry with WorkManager. No network in the metro? The entry waits, and a worker tries again when connectivity returns, however long that takes.
De-duplicate with a fingerprint. Banks sometimes post the same alert twice, and retries can overlap. A SHA-256 of the package, the normalised words and the post time means the same payment is never recorded twice, even if the process dies halfway through.
Catch up on reconnect. While the listener isn't bound, nothing is heard. When it reconnects, it reads the bank notifications still sitting in the shade from the last three days, skipping ones it has already handled.

6. The phone that kills your listener

On my Xiaomi (HyperOS), the first real test failed silently. From logcat:

Swiping the app away from recents kills the process, listener included.
With "Autostart" off, the system refuses to rebind the notification listener, so nothing is heard until the user opens the app again.
After an app update, the listener can stay unbound even though access is still granted. Calling requestRebind() and toggling the listener component's enabled state brings it back.

Onetap now asks for Autostart only on Xiaomi, Redmi and POCO phones, inside the bank-automation setup, with an explanation of why. With it on, a real wallet payment of Rs 1 was recorded 1.2 seconds after its notification arrived.

Testing it without spending money

You don't want to make a real payment for every test. Debug builds also accept notifications posted from the shell:

adb shell cmd notification post -S bigtext -t "HBL" test-1 \
  "PKR 1,250.00 debited from a/c 01234567890123 at FOODPANDA on 06-10-2026"

These come from com.android.shell, which the debug build treats as a bank app (never in release). That gave me a repeatable way to run real-looking bank text, OTPs and odd formats through the whole pipeline on a real phone.

What I'd tell anyone building this

Filter by package before reading content. It's the difference between "reads my bank alerts" and "reads my messages".
Decide what must never leave the device, and enforce it in pure, tested functions.
Treat model output as a suggestion, not a fact, wherever the input is ambiguous.
Assume Android will kill you, and write things down before doing anything slow.

Onetap is on Google Play with a 3-day free trial if you want to try it with your own bank. If yours sends a format it misreads, I'd really like to see it (with the numbers removed).

5 Android bugs my tests didn't catch while shipping an expense tracker

Rao Asad — Tue, 06 Oct 2026 10:58:27 +0000

I've spent the last few months building and shipping Coinly, an expense tracker for Android. It's a normal Kotlin app: MVVM, coroutines and Flow, Room, Gson, R8 in release.

It also had a reasonable test suite. None of these five bugs failed a single test. Every one of them reached a real build, and a couple of them reached real users.

Here they are, with the fix for each, in case they save you an evening.

1. Gson + R8: fields that silently come back as defaults

Exchange rates stopped working in the first release build. No crash, no error. Rates just came back empty, and Drive backup quietly decided there was no existing backup to restore.

The cause: when a field has no @SerializedName, Gson matches JSON keys by field name. R8 renames fields in release builds. So the JSON key rates no longer matched a field called rates, because that field was now called a. Gson didn't complain. It left the field at its default.

// Works in debug, silently broken in release
data class RatesResponse(
    val result: String = "",
    val rates: Map<String, Double> = emptyMap()
)

// Works in both
data class RatesResponse(
    @SerializedName("result") val result: String = "",
    @SerializedName("rates") val rates: Map<String, Double> = emptyMap()
)

Two things made this nasty:

Debug builds aren't minified, so every test on my phone passed.
Default values turn a crash into a wrong answer. emptyList() for "files in Drive" reads as "no backup exists", so a release build would have happily written a second backup next to the one it couldn't see.

A -keep rule alone isn't enough either: it stops the class from being removed, but its fields can still be renamed. I now put @SerializedName on every field of every Gson class, including the ones whose Kotlin name already matches the key. Those are exactly the ones people leave bare.

The general lesson: a release smoke test that checks "the app opens and the screens render" proves very little. R8 breaks data paths, not layouts.

2. `StateFlow.value` that is forever the initial value

This one showed up three separate times.

val history: StateFlow<List<Period>> = repo.observeHistory(id)
    .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), emptyList())

fun onDeleteClicked() {
    if (history.value.isNotEmpty()) showTwoWayDialog() else showSimpleDialog()
}

WhileSubscribed only starts the upstream flow when something collects it. Nothing collected history. It was only ever read as .value from a click handler. So .value was always emptyList(), and a budget with three months of history reported "no history".

The worst instance was on the Delete Account dialog: a user who was connected to Google Drive was told "you're not connected, so nothing is stored outside this device". The deletion itself was correct; the sentence was false.

The rule I use now: if a StateFlow is only read through .value and never collected, it must be SharingStarted.Eagerly. To audit, grep every stateIn(... WhileSubscribed ...) for .collect. If there are zero collectors and any .value reads, that's the bug.

3. The splash screen that hung forever

For my first five releases, Coinly could get stuck on its splash screen until you force-stopped it. I never saw it in testing.

// ViewModel
private val _destination = MutableSharedFlow<Destination>()   // replay = 0
val destination = _destination.asSharedFlow()

// Activity
lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.destination.collect { navigate(it) }
    }
}

repeatOnLifecycle(STARTED) cancels the collector whenever the activity is stopped. A SharedFlow with replay = 0 drops anything it can't deliver right now. So if the ViewModel decided where to go while the app wasn't in the foreground, the event was gone, and the splash waited for a second event that never came.

That sounds rare until you notice how often it happens: tapping a notification on a locked phone, opening the app during a call, switching away during the splash animation. Coinly's daily reminder opens the splash screen, so this was on a real path.

You can reproduce it deterministically with adb:

adb shell input keyevent 26        # screen off
adb shell am start -n com.example/.SplashActivity
sleep 8                            # the ViewModel emits with no collector
adb shell input keyevent 224       # wake, then unlock and look

The fix is one argument: MutableSharedFlow<Destination>(replay = 1). A late collector still gets the value, and since the splash finishes itself after navigating, there's nothing to re-navigate. Leave a comment next to it, because replay = 1 on a "one-shot event" looks wrong and someone will revert it.

4. The in-app language picker that worked everywhere except Google Play

Coinly ships in English, Spanish, Portuguese and Indonesian, with a language picker inside the app. On my test phone it worked perfectly. For people who installed from Play and picked a language other than their phone's, it showed English text with, say, Spanish number formatting.

The reason: with an Android App Bundle, Play only installs the language resources that match the phone's system languages. My test installs were APKs, which carry every language, so the bug couldn't happen on my device.

The fix is in build.gradle.kts:

android {
    bundle {
        language {
            // The app has its own language picker, so every language must be installed.
            enableSplit = false
        }
    }
}

The alternative is downloading languages on demand with Play Core. I didn't find this bug by testing. Lint found it (AppBundleLocaleChanges). If you have an in-app language picker, check your bundle config today.

5. A crash on a device nobody owns

Crashlytics reported an InflateException on the onboarding screen, caused by NoSuchMethodError in Material's FocusRingDrawable. The device was sdk_gphone_arm64 on Android 11.

That's not a user. It's Google Play's pre-launch test robot, which crawls every new release. It loads its own un-shrunk copy of Material inside your app's process, and R8 had renamed a method that the robot's copy expected by its original name. Real users weren't affected, but a crash in pre-launch reports is noise you don't want, and it can hide a real one.

-keep class com.google.android.material.focus.** { *; }

I got the same crash in my second app a few days later, from a slider this time, and widened the rule for that app.

What I changed in how I work

None of these were exotic. They were all "the build I test isn't the build people install":

Test a minified release build, not just debug, and exercise the network and storage paths, not just the screens.
Install from Play (internal testing track) at least once per release. APKs hide bundle problems.
Test with the app not in the foreground: locked screen, notification taps, switching away mid-launch.
Read Crashlytics device names before panicking. sdk_gphone is a robot.

Coinly is free on Google Play if you want to see the app these came out of. I'd like to hear the bug your tests missed.