Three ways to use AI on Android: The Good, the Bad and the Ugly
summary
A simple Android app prototype hardcodes a Gemini API key, gets the APK reverse‑engineered, the key is stolen and bills spike, proving hardcoded API keys fail. Obfuscation or Base64 and native libs only delay attackers. Moving model calls to a proxy server with Firebase App Check attestation and Firebase Functions keeps keys server‑side, enables prompt control and fallbacks, and prevents most abuse; it works but adds latency and hosting cost, so set usage limits.
AI-written summary · about
chapters (9)
- 0:00AI on Android intro
- 3:32Demo AI reply generator
- 6:22Bad: hardcoded API keys
- 10:16Ugly: remote encryption
- 14:50Protecting backend with App Check
- 17:17Good: proxy server approach
- 23:38Summary of AI methods
- 28:00Security best practices
- 30:48Final thoughts
related talks
41m[REDACTED]: How to keep your app's secrets, secret
39mAndroid App Security Fundamentals
01h 07mHow to attack (and secure) an Android app: an introduction
33mHacking and protection of Mobile Apps and backend APIs
42mHow to Steal a JWT and How to Protect From It
51mThe Next Application Security Frontier: AI-Ready API Defense
24mModern Android App Security: Protecting Code, Keys, and Data
34mSecuring Android: Tackling Advanced Threats and Enhancing App Security