Things You Didn't Know Third-Party SDKs Could Do
summary
Enumerates concrete ways third‑party SDKs run code and bite apps: using a content provider on main thread to execute at startup (blocking I/O causes slow cold starts), AndroidX Startup still relies on providers, registering activity lifecycle callbacks and storing strong references causes memory leaks, and replacing the window callback must delegate to the original or it breaks touch/key handling. Also covers using reflection, Gradle plugins and bytecode transforms to inject behavior without explicit deps, and recommends kill switches, extensive device testing and CI checks for app size and startup metrics.
AI-written summary · about
chapters (6)
- 0:00Welcome
- 5:44Content providers as hooks
- 9:55Activity lifecycle callbacks
- 12:23Window callbacks
- 15:35Reflection and Gradle tricks
- 17:42Key takeaways
related talks
37mPerforming Due Diligence as Android Developers
38mAdvanced Techniques for Protecting Android Apps
42mAndroid Internals for Developers
46mOpening Keynote: Android Then & Now
19mBuilding Managers Over 3rd Party SDKs for Easy Access
24mMake the Most of Android Vitals
25mWays of using hidden Android APIs in system and vendor development
49mServices: You Can't Live Without Them, So How Do You Cope?