DEV Community: Shubham Nanche

SSKCore: Turning Production Pain Into an Android Platform [PART-2]

Shubham Nanche — Mon, 24 Aug 2026 06:42:59 +0000

📚 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 cache after a major refactor. The compiled resource IDs no longer matched the packaged resource table. ViewBinding inflated the wrong layout, and a silent NullPointerException killed the crash screen itself.

It was invisible in CI. It only appeared in specific rebuild scenarios. And it took hours to trace.

That bug taught me something important: The fix isn't done when the patch ships. It's done when the lesson becomes automated.

So I wrote a build-time task that reads the compiled class files directly, compares them against the final packaged resources, and verifies every constant matches. It runs automatically after every packaging step. You never have to remember to invoke it.

That was the first of many incident-driven tools I built.

The FAB That Disappeared

A few weeks later, a developer tools Floating Action Button vanished from consumer apps. Debug menus inaccessible. Secure screens incorrectly enabled.

Turns out, my shared library's BuildConfigUtils was reading the library's own BuildConfig—which is baked as "release" at publish time. An AAR can never know the consumer's build type. 25 files across 34 call sites were silently broken.

I built a Gradle plugin that generates a SskBuildConfig object per consumer module, per variant, using AGP's onVariants callback. It registers generated source via KotlinCompile.source()—not reflection, which broke across AGP versions. It detects Android plugins by extension type, not hardcoded IDs, so it works with com.android.application, com.android.library, com.android.dynamic-feature, and any future Google plugin.

Same package as the deprecated BuildConfigUtils. Migration was just renaming the receiver. Zero import changes.

The Permission That Leaked

An app depending on core-base suddenly gained AD_ID permission and started initializing Google Mobile Ads unconditionally—even for users who'd never see an ad.

The root cause? core-base hard-depended on play-services-ads. Every consumer inherited it.

The fix: extract the ad code into an opt-in module. Apps that need ads explicitly add the dependency. Apps that don't, don't inherit the permission.

That structural separation taught me: Modularization isn't just about code organization. It's about controlling what your consumers accidentally inherit.

The Platform That Emerged

These incidents weren't isolated. They were symptoms of a larger problem: building multiple Android apps that share code is genuinely hard. Not "write a library and import it" hard. "Gradle composite builds shadow your settings classpath, build-cache serves stale intermediates, AAR limitations hide variant information, and module extraction silently leaves resource shadows that AGP resolves by merge priority" hard.

So I built SskCore. 18 published library modules. 60+ custom Gradle tasks. All built by one developer—me—from real production pain points.

What Makes It Different

Automatic Source/Binary Switching

Non-release branches compile SskCore from source. Release branches use published AARs. Detected from .git/HEAD. No flags, no manual configuration.

60+ Custom Gradle Tasks

Each task exists because a real bug or real pain point was encountered:

Resource-ID drift detection
Secret scanning
Accessibility auditing
Security auditing
Navigation graph analysis
Translation gap analysis
Build matrix visualization
Release checklists
Bundletool automation
Dependency freshness checking
Obfuscation mapping collection

ModuleMap Architecture

Crosses Gradle composite build session boundaries for holistic analysis—one command catches duplicates across the library and app boundary, which includeBuild normally isolates.

Catalog-Driven Module Discovery

Adding a new SskCore module requires one line in the consumer's version catalog. No republish of build-logic needed.

Documentation With Incident Context

Every design decision is documented with the incident that caused it. Not "we decided to do X" but "on Aug 10, the crash screen rendered all-grey because of a stale R.jar. Here's the evidence chain. Here's the fix. Here's the prevention."

The Solo Developer Perspective

Here's the thing: I built this alone. Every module, every Gradle plugin, every task, every documentation file—all from one person's keyboard.

That changes the calculus. You don't have a team to rely on. Every complexity tradeoff is yours to own. The upside? You can move fast, make architectural decisions unilaterally, and build exactly what the apps need without organizational friction. The downside? The learning curve is steep, and the cognitive load is real.

But I learned something important: It's not about scale. It's about leverage. Each tool I build saves me days across multiple apps. Each automated check prevents a future debugging session. Each documentation file preserves a lesson I'd otherwise forget.

The Real Engineering Lesson

The 60+ tasks sound like overkill until you've debugged a stale-R crash at 2am. The composite build setup is complex until you've shipped a release with the wrong variant checks because you forgot a flag. The documentation is extensive until you're the one who has to re-derive why something was done a certain way.

Every piece of complexity exists because a simpler approach failed in production.

What's Next

I'm considering open-sourcing the build-logic separately. The 18 modules are app-specific enough that they need context, but the 60+ tasks and the composite-build infrastructure are genuinely useful for any multi-module Android project. The Resource-ID drift guard alone would have saved me days.

Why This Matters to Enterprise applications

SskCore demonstrates work beyond feature delivery:

Turning repeated app work into platform APIs
Designing Android module boundaries
Building Gradle plugins and custom tasks
Improving release confidence
Managing binary/source consumption tradeoffs
Debugging production-like failures
Designing reusable components with host-app contracts
Writing documentation that preserves engineering decisions

This is relevant to teams working on Android platform engineering, mobile infrastructure, build systems, developer productivity, internal SDKs, release engineering, and app quality automation.

One developer. 18 modules. 60+ Gradle tasks. 20+ documentation files.

This is SskCore—the platform I built from production pain.

If you've built similar shared infrastructure for Android, I'd love to hear how you approached the composite-build / binary-mode switching problem. Or if you've hit the stale-R.jar bug—I now have a very thorough write-up.

📚 This is part 2 of a series.

Part 1: The Origin Story
Part 2: [Current Article]
Part 3: Coming soon...

SskCore: Turning Production Pain Into an Android Platform

Shubham Nanche — Sun, 23 Aug 2026 15:33:29 +0000

I started with Android apps.

Eventually, I realized I was solving many of the same engineering problems again and again.

Themes. Localization. Notifications. Crash handling. File access. Play integrations. Storage. Build configuration. Release checks. Reusable UI infrastructure.

At first, sharing code between apps feels straightforward.

Then the applications evolve.

One copy gets a bug fix. Another doesn't.

A release requirement changes, so the same logic needs to be updated in several places.

A build-system problem appears in one application, gets fixed locally, and disappears from memory until something similar happens months later.

The code isn't necessarily difficult.

The accumulated engineering knowledge is.

That was the motivation behind SskCore.

SskCore is an internal Android engineering platform I built to turn repeated production lessons into reusable infrastructure, build automation, release safety, and developer tooling across multiple applications.

This article is not a tutorial for building another Android library.

It is a case study in how a collection of recurring application problems gradually turned into a platform.

From shared code to a platform

The first instinct when multiple applications need the same thing is usually to extract it into a library.

That's a good start.

It is not necessarily the end state.

A reusable platform has a different responsibility from a collection of utility functions.

It needs to answer questions like:

Which application capabilities belong together?
Which dependencies should remain optional?
How should consumers integrate the platform?
How should changes be released?
How can developers iterate quickly without sacrificing release stability?
How can recurring mistakes become automated checks?
How do you preserve the reasoning behind architectural decisions?

SskCore evolved around those questions.

Instead of copying infrastructure from application to application, shared capabilities became reusable modules with defined boundaries and consumer-facing contracts.

The platform eventually grew to 18 Android modules, supported by shared build logic, custom Gradle automation, release tooling, and extensive documentation.

The important part isn't the number 18.

The important part is why the boundaries exist.

The platform is more than an SDK

At a high level, SskCore can be thought of as several layers.

Foundation

This contains common utilities and lower-level Kotlin support that can be reused without pulling in higher-level application behavior.

Services

These modules provide reusable infrastructure around areas such as:

Notifications
Play ecosystem integrations
Media
Storage
Search
Data utilities
Security-aware utilities

UI infrastructure

This layer contains reusable UI and presentation infrastructure, including:

Compose utilities
XML view helpers
Theme and design systems
Localization support

Feature components

These are larger reusable capabilities rather than simple helper functions.

Examples include:

Text-to-speech orchestration
Crash reporting and recovery UX
File browsing
Task monitoring
Other opt-in application capabilities

Build platform

This is where the project starts to look less like a traditional Android SDK.

The build layer provides convention plugins, publishing support, dependency visibility, release checks, and custom quality automation.

The architecture isn't simply "many modules."

The module boundaries exist to control ownership, dependency shape, optional capabilities, and release risk.

That distinction matters.

A large number of modules can just create fragmentation.

Good modularization should instead make the consequences of a dependency more predictable.

The problem with treating every bug as an isolated bug

One of the biggest changes in my thinking came from production debugging.

A traditional debugging loop is:

Something broke → find the cause → fix it → move on.

That works.

But it misses the opportunity to improve the system itself.

With SskCore, I started asking a different set of questions:

Why was this possible?

Why didn't we detect it earlier?

Can the build system identify this class of problem next time?

Can the prevention be reused across every consumer?

Can the lesson be documented so it survives context loss?

That changed the role of the build system.

Instead of being the machinery that turns source code into an APK, it became a place where engineering knowledge could be encoded.

Production bugs should become tools

This became one of the guiding principles behind SskCore:

The most valuable bug fix is often the automated check that prevents the same class of problem from returning.

Some Android failures are difficult to catch through normal development workflows.

They can involve things such as:

Resource and packaging interactions
Build caching
Variant differences
Dependency shape
Localization gaps
Release configuration
Cross-module integration

A manual checklist can help.

But a checklist depends on somebody remembering it.

Automation doesn't.

SskCore grew to include 60+ custom build and quality tasks covering areas such as:

Release readiness
Resource and packaging safety
Localization analysis
Accessibility checks
Dependency visibility
Build health
Security posture
Artifact and bundle workflows
Other release and quality checks

These weren't designed as an arbitrary collection of developer tools.

They were largely driven by problems that had already consumed engineering time.

That leads to a principle I now use whenever I encounter a difficult production issue:

Fix the issue. Then encode the lesson.

A build system has to support two different needs

Internal SDKs have an interesting tension.

During active development, engineers want fast feedback.

During release, engineers want stability and reproducibility.

Those goals can pull in different directions.

SskCore was designed around both.

During active work, applications can consume the platform in a way that supports source-level iteration.

For release workflows, the same platform can be consumed through versioned artifacts.

The important thing is not the specific mechanism.

The important thing is the boundary:

developers should be able to move quickly without turning the release dependency graph into something unpredictable.

This became one of the more interesting parts of the platform because it pushed Android build engineering beyond ordinary dependency management.

It required thinking about:

Development workflow
Artifact versioning
Release stability
Consumer integration
Dependency boundaries
Reproducibility

The lesson was broader than Android:

Developer experience and release engineering are not opposing concerns. A good platform has to design for both.

Reusable code is not just extracted code

One of the easiest mistakes in shared infrastructure is assuming that reusable code is simply application code moved into a library.

It isn't.

Application code can make assumptions.

It knows its host.

It knows its screens.

It knows its configuration.

It knows which other components are present.

A reusable platform component doesn't have that luxury.

It needs explicit contracts.

It needs sensible defaults.

It needs predictable integration points.

It needs documentation.

And eventually, it needs a migration story.

That became especially important for larger SskCore capabilities such as text-to-speech orchestration, crash recovery UX, file browsing, localization flows, and task monitoring.

The engineering challenge wasn't simply making them reusable.

It was making them configurable enough for different consumers without forcing every application to understand the platform's internal complexity.

That led to another principle:

Reusable code is not just extracted code. It is code with a contract.

Modularization is about consequences

"Make everything a module" is not an architecture strategy.

The useful question is:

What consequence does this dependency have when an application adopts it?

A monolithic shared module can become convenient in the short term.

It can also accumulate unrelated dependencies and capabilities over time.

SskCore instead separates optional capabilities so that applications can opt into the infrastructure they actually need.

That produces a cleaner dependency graph and makes the relationship between an application and its shared infrastructure easier to reason about.

This is particularly important for Android because the cost of a dependency isn't always limited to another library appearing in a Gradle file.

Dependencies can influence:

Build complexity
Packaging
Application size
Permissions
Runtime behavior
Release risk
Maintenance ownership

Good modularization therefore becomes a form of risk management.

Not because every module is inherently safer, but because smaller, intentional boundaries make accidental consequences easier to see.

Documentation became part of the platform

There is another problem that appears once a platform becomes sufficiently complex.

The original author becomes the documentation.

That is not sustainable.

If only one person knows why a particular design exists, the platform carries a hidden operational dependency on that person.

SskCore therefore includes extensive documentation covering areas such as:

Architecture
Module boundaries
Release behavior
Recovery
Build behavior
Troubleshooting
Reusable feature integration
Engineering decisions

The purpose isn't documentation for documentation's sake.

It's to preserve context.

A future engineer shouldn't have to rediscover the entire reasoning chain behind a design decision simply because the original incident happened months ago.

For me, this changed the definition of developer infrastructure.

Documentation is part of the platform because engineering judgment is part of the platform.

What SskCore changed about how I think about Android

Building SskCore gradually changed my view of Android engineering.

I used to think primarily in terms of application features:

What does this application need to do?

Now I think much more often in terms of platform questions:

What should be reusable?

What should be isolated?

What should the build system know?

What should be automatically verified?

Which assumptions should become contracts?

Which production lessons deserve to become tooling?

That shift is probably the most valuable outcome of the project.

SskCore isn't valuable merely because it contains reusable code.

It is valuable because it captures engineering decisions that otherwise would have been repeatedly rediscovered.

The bigger lesson

The deeper I got into the project, the more I realized that applications are only one layer of software engineering.

Underneath the application are:

Build systems
SDKs
Dependency graphs
Release pipelines
Quality checks
Developer tooling
Documentation
Operational knowledge

When those layers are designed well, application development becomes easier.

Not because the platform eliminates complexity.

It moves the right complexity into a place where it can be handled once and reused.

That is the real idea behind SskCore.

Turn repeated pain into infrastructure.

Turn infrastructure into contracts.

Turn production lessons into automation.

Turn engineering decisions into documentation.

And then make the next application benefit from everything learned by the previous one.

Where I want to take this thinking

SskCore started as a solution to problems I was repeatedly encountering while building Android applications.

It evolved into something that made me increasingly interested in a different class of engineering work:

Android platform engineering
Build systems
Internal SDKs
Developer productivity
Release engineering
Production debugging
Engineering automation

That intersection is what makes the project interesting to me.

The platform beneath an application may not be visible to users.

But it can have an enormous effect on how reliably and efficiently engineers can build what users actually see.

And that is ultimately what SskCore represents:

A collection of hard-earned engineering lessons, turned into reusable infrastructure.