Surviving and fixing bugs in 3rd-party libraries
summary
Step‑by‑step options for third‑party crashes: reproduce with real data, use composite builds to edit and debug a library locally, then either publish a frozen snapshot to private Maven (avoid snapshots in prod) or maintain a fork/submodule; preserve POMs to avoid binary incompatibility like NoSuchMethodError; add logging into the library and wire it to Crashlytics or Sentry (Crashlytics log entries 64 KB, 64 key/value metadata limits; Sentry breadcrumb 8,000 chars); for small fixes patch bytecode with recaf or use reflection as a last resort.
AI-written summary · about
chapters (21)
- 0:00Third-party dependency issues
- 1:06Third-party bugs are your responsibility
- 2:10Check GitHub for fixes
- 4:24Snapshot versions safely
- 5:49Debug with composite builds
- 8:19Debug production with logging
- 10:31Fork libraries for fixes
- 12:00Host fork in Maven
- 13:50Prevent version conflicts
- 16:47Preserve POM files
- 18:32Choose Maven repository
- 21:29Git submodules for changes
- 23:16Git subtree alternative
- 24:22Contribute fixes upstream
- 26:51Maintain fork long-term
- 27:12Closed-source library issues
- 28:16Android component issues
- 30:45Library issues with reflection
- 33:36Edit bytecode for fixes
- 37:12Fix ProGuard conflicts
- 38:38Conclusion
related talks
36mNasty Dependencies: Surviving and fixing bugs in 3rd-party libra…
43mLibrary Developer Confidential
01h 17mDevelopment strategies: You've written a library - now what?
39mThe definitive guide to Android library development
53mHow not to fuckup with building SDK and make clients happy
38mBuilding libraries for the next 25 years
46mTaking over someone else's codebase
16mMaven - Taming the Beast