How not to fuckup with building SDK and make clients happy
summary
Build process focuses on concrete fixes: use AAR manifest merging to avoid manual manifest edits, add a Gradle plugin auto-config that pulls app ID from the dashboard at build time, and use a ContentProvider auto-initialization to eliminate manual Application wiring. Stop crashes with strict vs safe execution modes and centralized error handling, run integration tests as a spec, track library size and method count in CI, expose debug logs and error codes for fast support. Library serves ~30M monthly users; average game ships 17 SDKs.
AI-written summary · about
chapters (17)
- 0:00Start
- 2:30SDK Lifecycle
- 7:10DROP IT!
- 10:54Gradle plugin
- 15:12Make API of your library as boring as possible
- 23:29What is important to developers?
- 24:22SIZE
- 24:41Method count
- 26:39COMPATIBILITY
- 29:10SUPPORT
- 30:12Get ready to repetitive questions
- 30:30DOCS
- 31:27Product guides
- 34:01Google Developer Documentation Style Guide
- 35:05DEMOS
- 46:27To sum up
- 48:25Put yourself in your customers shoes
related talks
22mBest Practices When Building Mobile SDKs
32mHow to successfully shift from app development to SDK development
43mLibrary Developer Confidential
34mSuccessfully publishing a tested, upgradeable and documented Open Source Library
27mSDK or Not
32mBest Practices in SDK Development
09mDeveloping and supporting 12 SDKs with a team of three
34mWhy SDK Docs Matter — And What I’m Doing About It!