{
  "id": 2964322,
  "title": "SSKCore: Turning Production Pain Into an Android Platform [PART-2]",
  "url": "https://urgent.news/2026/08/24/sskcore-turning-production-pain-into-an-android-platform-part-2",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-24T06:42:59.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/shubhamnanche/sskcore-turning-production-pain-into-an-android-platform-part-2-8p7"
  },
  "original_language": "en",
  "account": "Part 2: SskCore - Turning Production Pain Into an Android Platform\n\nIn this part, the author recounts several incidents that led to the creation of SskCore, a set of tools designed to address the challenges of building multiple Android apps that share code.\n\nThe author describes a crash in their Android app with a grey screen, caused by a stale Gradle build cache file after a major refactor. The root cause was mismatched compiled resource IDs and inflated ViewBinding layouts, leading to a silent NullPointerException that went undetected in CI and only appeared in specific rebuild scenarios. This incident taught the author that the fix is not complete until the lesson is automated.\n\nAnother incident involved a Floating Action Button disappearing from consumer apps, with debug menus being inaccessible and secure screens incorrectly enabled. The author discovered that the shared library's BuildConfigUtils was reading its own BuildConfig, which is baked as \"release\" at publish time. An AAR cannot know the consumer's build type, resulting in 25 files across 34 call sites being silently broken.\n\nIn a third incident, an app depending on core-base suddenly gained the AD_ID permission, initializing Google Mobile Ads unconditionally, even for users who wouldn't see an ad. This happened because core-base hard-depended on play-services-ads, causing every consumer to inherit the permission. The fix was to extract the ad code into an opt-in module, with apps requiring ads explicitly adding the dependency.\n\nThese incidents led the author to recognize the larger problem: building multiple Android apps that share code is genuinely hard. The author then explains SskCore, which consists of 18 published library modules and over 60 custom Gradle tasks, all built by one developer from real production pain points. SskCore's key features include automatic source/binary switching, 60+ custom Gradle tasks, catalog-driven module discovery, and documentation with incident context.\n\nThe author emphasizes that SskCore was built by a solo developer, highlighting the challenges and benefits of this approach. They argue that simplicity is often overrated and that complexity exists because simpler approaches fail in production. The author concludes by considering open-sourcing the build-logic separately, as the 60+ tasks and composite-build infrastructure are genuinely useful for any multi-module Android project.",
  "summary": "📚 This is part 2 of a series. Part 1: The Origin Story Part 2: [Current Article] Part 3: Coming soon... Let me tell you about the day my crash reporting UI crashed. The Grey Screen One afternoon, my Android app's crash screen rendered all-grey. No content. No report button. Just a blank slate where the app's last line of defense should have been. The root cause? A stale file from Gradle's build…",
  "key_points": [
    "SskCore created to address Android app sharing code challenges",
    "Author recounts three incidents leading to SskCore development",
    "SskCore includes 18 library modules and 60+ custom Gradle tasks"
  ],
  "editors_take": "The development of SskCore signifies a shift in addressing the complexities of building multiple Android apps that share code, moving from reactive fixes to a comprehensive platform that automates solutions to common pain points.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}