How to keep your app awake in a GSM phone app
summary
Custom GSMR “railcom” app replaces the default dialer and implements InCallService and CallScreeningService plus a foreground service and device admin to stay in memory, uses a partial wake lock combined with REQUEST_IGNORE_BATTERY_OPTIMIZATIONS to stay awake, integrates with an RSM hardware button and tilt/vigilance checks, and handles emergency workflows and call merging. Measured over a 9‑hour test, a permanent wake lock adds only ~2–3% extra battery drain (9h call left battery ~71% vs ~68% with wake).
AI-written summary · about
chapters (8)
- 0:00Introduction
- 3:33Safety-critical GSM use case
- 9:09App architecture
- 13:03Telephony workflows
- 21:01Keeping app awake
- 28:26Battery optimization
- 32:44Battery impact measurements
- 35:16Conclusion
related talks
34mPowering up your app performance & stability using App Vitals
30mApp Standby vs. Doze: Understanding System Sleep
37mHow to survive on Android and don't get killed
34mDon't Kill My App: Android survival guide
22mPower optimization for Android
21mImproving battery life with restrictions
33mIs my application taking up too much power?
35mHow to survive on Android and don't get killed