Badudeal Call Logger: From Spec to an Installed Field App in One Session
A native Android app for hotline call logging, built, debugged on real hardware, and shipped the same day
Knovik designed, built, and shipped a native Android app that prompts Badudeal's hotline agents to log customer details the moment a call ends, then syncs every entry to Google Sheets in the background — spec to installed app, verified on real hardware, in one session.
Overview
Badudeal runs a company hotline where agents need to capture the caller's number, name, and what they were calling about, without slowing down the call itself. Knovik built a purpose-fit Android app rather than adapting a generic form tool: it detects the call automatically via Android's Call Screening API, prompts the agent the moment the call ends with a full-screen form, writes every entry to an on-device database first so nothing is lost if the network drops, and syncs to a Google Sheet in the background. The whole loop, spec to installed app, was completed and verified on a real device in a single working session.
Our Approach
What we delivered
Call Detection, Not Data Entry
Built on Android's CallScreeningService role, paired with a process-level TelephonyManager listener to reliably catch the moment a call ends, since the screening service itself isn't kept alive by the system for the call's duration. The agent never opens the app manually; the log prompt appears as soon as the call is over.
Offline-First, Not Sync-Dependent
Every entry writes to a local Room database before any network call is attempted, so a dead connection on a hotline device never means a lost lead. A WorkManager-backed sync layer pushes queued entries to a Google Apps Script endpoint with automatic retry and backoff, guarded against the concurrent-worker and double-tap edge cases that would otherwise duplicate rows.
Verified on Real Hardware, Not Just Compiled
Every fix in this build, from a Hilt/WorkManager wiring bug to a live Sheets column mismatch, was reproduced and confirmed fixed on an actual connected Android device: real permission grants, a real network round-trip to a live Apps Script deployment, and a direct SQLite read of the on-device database to confirm data correctness before shipping.
The People Behind This Work
Our experts behind this case study
Madusanka Premaratne
Founder & CEO
Author of the EICON 2026 paper on agentic systems; leads Knovik's edge AI and automation practice, including EdgeTal.
View ProfileDinithi De Silva
Partner, Mobile Engineering
10+ years in mobile engineering and an Apache Software Foundation committer; leads Flutter and AI-integrated mobile builds at Knovik.
View ProfileDelivered & Verified
Results, as of July 2026
This was a same-day build-to-device delivery, not a staged rollout — what's below is what shipped and was verified in that window.
3 releases in one session (v1.0.0 → v1.0.2)
Each triggered by a real bug found through on-device testing, not code review alone.
Two production-grade bugs root-caused and fixed on hardware
A WorkManager/Hilt initialization race that silently broke background sync, and a live Google Sheets column mismatch caught by directly reproducing the failing request.
Zero data loss by design
Write-ahead local persistence means the sync layer can fail, retry, and even race with itself without ever dropping a logged call.
Deployed without an app store
Signed APK sideloaded directly to the hotline device — appropriate for an internal single-device tool with no public distribution need.
Related Services
The services behind this work
Frequently Asked Questions
Got questions? We have answers
Want field software built and verified the same way?
Talk to our team about a native app built for a real device, real conditions, and real verification before it ships.