DEV Community: Shubham Nanche

SskCore: Turning Production Pain Into an Android Platform [PART-7]

Shubham Nanche — Mon, 31 Aug 2026 06:52:24 +0000

Text-to-Speech Is Not a `speak()` Call

The challenge 🧪

If you have ever assumed Text-to-Speech on Android is straightforward, this article is for you.

But first, let us test your skills.

Think you can make this speak on Android?

🙏 अव्यक्तोऽयमचिन्त्योऽयमविकार्योऽयमुच्यते ।

"Invisible, beyond thought, unchanging." — Krishna describing the nature of the self.

Today is World Sanskrit Day, so the timing is fitting. 🕉️

Try playing it on the plain TextToSpeech API that Google provides — but specifically with a Sanskrit voice.

Build a minimal Android app, initialize the TTS engine, set the language to Sanskrit, and call speak() on this string.

Chances are it will not speak anything. Not even a single letter would be uttered. 🔇

That is the moment when a developer realizes that TTS is not a simple API call.

The twist 🔄

Use a Marathi or Hindi voice instead. Same engine. Same text. Same API call.

It plays perfectly. 🗣️

Same engine. Same verse. Different voice. Completely different result.

The boundary between "speakable" and "not speakable" is not at the engine level. It is at the voice level within the engine.

The Sanskrit voice within Google's TTS engine cannot handle this verse. But the Marathi voice — which shares much of the same Devanagari character set — handles it without issue.

This changes how you think about TTS integration.

What happened in production 🏭

This is not a theoretical exercise. This is what we actually hit.

In Bhagavad Gita, the player screen uses TTS to read verses aloud. The experience is designed to feel like playing a media file: continuous, flowing, uninterrupted.

But certain words — especially compound words and special conjunct characters — were being silently skipped. Not errored. Not logged. Just... silent.

The engine would skip the entire word if it couldn't speak something in it.

So a verse that should take 15 seconds to read would finish in 8. The user would hear a flowing recitation with missing pieces and never know what was lost. 😶

The worst kind of bug. The system appears to work. The output is incomplete. Users never know.

This is NOT just a Sanskrit problem 🌍

Sanskrit is the most visible example, but the problem shows up everywhere.
Take two Unicode characters that look nearly identical:

ृ — vocalic r, short ✅ (speakable by Google TTS)
ॄ — vocalic r, long ❌ (silence)

They differ by a single Unicode code point, but one produces audio and the other produces silence. And the engine does not tell you — it just stays quiet.

Different TTS engines handle complex characters differently. But even within a single engine, different voices handle the same characters differently. A voice that speaks Tamil conjuncts correctly may skip Burmese tone marks. A voice that handles Thai stacking may fail on Tibetan.

And it gets worse. 📱

Voice compatibility varies across Android versions, TTS engine versions, and device manufacturers. A voice that works perfectly on Android 13 may fail silently on Android 14. An engine update can break character handling that previously worked. A Samsung device may ship a different engine version than a Pixel on the same Android version.

None of this is documented in a way that developers can rely on. There is no voice capability matrix. There is no API to ask an engine "can you speak this character correctly on this device?"

You discover the problem when users report missing audio on a device you never tested. 🔇

Even within widely-supported language families, edge cases exist. A Marathi verse containing Sanskrit compound words can fail silently on one voice but work on a different voice. A Hindi sentence with certain Devanagari conjuncts can produce gaps on one voice and read correctly on another.

The line between "supported" and "unsupported" is not clean. It is a gradient. And the standard API gives you no tools to navigate it.

The assumption that breaks everything ⚠️

The standard Android TextToSpeech API makes a quiet assumption: the engine you select will handle the language you request.

For English, French, German, or Mandarin, that assumption holds well enough. The engines have been tuned for these languages, the character sets are well-supported, and the output is predictable.

For languages with complex scripts — Sanskrit, Tamil, Tibetan, Thai, Khmer, or many others — that assumption collapses. And as the Sanskrit test showed, even when the engine nominally supports the language, the specific voice may not handle all characters.

Adding the version dimension makes it worse. Even the voice that worked last month may not work after an engine update. The API gives you no tools to discover this at runtime. There is no method to ask an engine whether it can speak a specific character correctly. There is no voice capability profile. The engine accepts the input, and you discover the problem only when the output is silent or incomplete.

If you have only integrated TTS for well-supported languages on a single test device, you may never encounter this. The moment you need a complex script across a range of devices and OS versions, the entire integration model breaks.

The problem gets worse with continuous playback 🎵

Now add another requirement: the app does not just need to speak one sentence. It needs to play a continuous sequence of content — verse after verse, section after section — with smooth transitions, role-appropriate voices, and uninterrupted flow.

In Bhagavad Gita, the player screen plays TTS in a continuous loop. It behaves like a media file: the user starts playback, and the audio flows without manual intervention. Transitions between verses are smooth. Voices can shift by role. The experience is designed to feel like listening to a recording.

Except there are no pre-recorded files for most of the content. The audio is generated at runtime from text, voices, and a sequence-driven orchestration layer.

Combine that with the voice-level and version-level variability problems and you have a genuinely hard engineering challenge:

✅ The content is continuous and sequenced
⚠️ Some voices can't speak certain characters in the content
🔇 The engine does not reject bad input — it just stays silent
📱 Different devices have different engines with different voices
🔄 Even within the same engine, different voices produce different results
🔢 Voice behavior can change across Android versions and engine updates
🌍 The same content needs to work across many languages
🎧 The experience must feel like media playback, not a series of disjointed TTS calls

Standard TextToSpeech does not solve any of those problems. It gives you a sentence-level API and assumes the engine handles the rest.

The multi-engine, multi-voice approach 🔀

SskCore's TTS architecture addresses this by treating engine AND voice selection as first-class problems.

Instead of relying on a single TTS engine with a default voice, the platform manages multiple engines and multiple voices, and selects the appropriate combination based on the language, the script, and the actual speaking capability of each voice on the specific device.

This is not a simple wrapper around TextToSpeech. It is a multi-engine, multi-voice orchestration layer that:

Evaluates voice capabilities per language and script. 🎯 Not all voices support all scripts. Not all voices within the same engine handle the same characters. The platform needs to know, or discover, which voice-engine combinations actually speak the text correctly.
Selects the voice that works, not just the voice that claims to. 🗣️ The platform does not blindly pick the "Sanskrit voice" for Sanskrit text. It evaluates which voice actually handles the characters in the content — which may be a Marathi voice, a Hindi voice, or another voice that shares the relevant character set.
Falls back gracefully across voices and engines. 🛡️ If the selected voice produces silence or garbled output for a specific character, the platform can route that segment to a different voice or engine that handles it correctly. The fallback is per-segment, not per-app.
Adapts across versions. 📱 Because voice behavior can shift with Android or engine updates, the platform does not hardcode a single voice as "the solution." It discovers and re-evaluates capabilities, so a voice that stops working after an update can be replaced without an app update.
Maintains sequencing across voice switches. 🔄 Switching voices mid-sequence is risky — the voice quality, pacing, and tone may change. The platform must manage these transitions so the user experience remains coherent.
Handles the silence problem. 🔇 The hardest bug in complex-script TTS is silent failure. The engine does not error. It does not throw an exception. It just does not speak. Detecting and recovering from this requires the platform to understand what "no output" means and route the content accordingly.

Once this infrastructure is built, it works for any language. You do not need a special solution for Sanskrit, a different solution for Thai, and another for Tibetan. The same orchestration layer handles them all. The language and content determine which voices to try. The platform handles the rest.

Sequence-driven, role-oriented playback 🎭

The multi-voice approach solves the character and version problems. But continuous playback requires more.

When content flows as a sequence — verse after verse in a long reading session — the platform needs to own:

Segment boundaries. 📏 Where does one verse end and the next begin?
Transition timing. ⏱️ How much pause between segments? How does the audio feel continuous rather than choppy?
Role-based voice assignment. 🎭 Not every segment should use the same voice. Narration, dialogue, attributed text — these may need different voice profiles.
Interruption and resumption. ⏸️ If the user pauses, leaves the app, or receives a notification, the platform must resume from the correct position without restarting the sequence.
Looping. 🔁 In Bhagavad Gita's player, the sequence can loop continuously. The platform must handle the transition from the last segment back to the first smoothly.

These are not sentence-level problems. They are systems-level problems. And they are the reason TTS is not a speak() call — it is a product capability that requires orchestration infrastructure.

What the UI actually needs: highlight and progress ✨

Media-like playback is not enough. A reading app needs the UI to track the audio.

SskCore's TTS layer exposes two first-class signals that most wrappers miss:

Highlight — where are we speaking right now? A real-time character range [start, end) in the original text, updated as each word is spoken. The range stays accurate even when the text is normalized before speaking (for example, a display form replaced with a speakable form) and even when long text is chunked for the engine. Per-role and global streams are available, so a Sanskrit step and a translation step each highlight independently.
Progress — how far are we through? A 0.0 → 1.0 fraction derived from the last spoken character, again per-role and global. This drives seek bars, verse progress, and precise pause/resume.

Two details make this hard and why it belongs in the platform:

Transformation-aware mapping. If the spoken text differs from the displayed text, the highlight must map back to the original character positions. Otherwise the UI highlights the wrong word.
Network-voice timing. Network voices (like Google WaveNet) have a 200–600ms gap between onRangeStart and audible audio. Without compensation the highlight runs ahead of the sound. The platform applies a tunable delay so highlight and audio stay in sync — zero for local voices, compensated for network voices.

On top of that, the platform owns the surrounding lifecycle that apps otherwise reimplement badly: chunking long text at sentence boundaries, computing a precise resume offset so pause/resume never repeats or skips a word, handling audio focus and headphone-unplug (becoming noisy) by pausing gracefully, and detecting stalls where an engine accepts an utterance but never produces audio (watchdog → clean failure instead of infinite silence). Background cues like a looping conch can be attached to the sequence with declarative lifecycles — the platform guarantees they never outlive the sequence.

Once, trial and error. Afterwards, every screen reuses it.

Why this is a platform problem 🏗️

It is tempting to solve the TTS problem at the application level. The app needs audio, so the app manages engines, voices, sequences, and fallbacks.

But when TTS is needed across multiple content domains — not just one screen in one app — it becomes infrastructure. And infrastructure has different design requirements:

Scaling across languages is automatic. 🌐 Once the multi-voice approach and sequence-driven playback are configured, they work across every supported language. Adding a new language does not require rewriting the playback logic. You configure the content and the language. The platform handles voice selection, fallback, and sequencing.
Content grows without asset multiplication. 📚 Adding a new verse does not require recording new audio. The text is the source of truth. Every new piece of content is playable in every supported language without additional audio assets.
Engine and voice improvements flow to all consumers. ⬆️ When the platform improves voice selection or fallback logic, every application that uses the platform benefits automatically.
Version changes are absorbed once. 🔢 When a new Android version or engine update shifts voice behavior, the platform adapts — and every consumer app inherits the fix without code changes.
UI stays honest. ✨ Because highlight and progress are part of the platform contract, every consumer gets word-accurate highlighting and reliable progress without rebuilding the mapping, chunking, and timing logic.

The scaling argument is worth emphasizing: a TTS integration scales with the number of languages times the number of content pieces times the number of device versions. A TTS capability scales with the content only. The language and version dimensions become configurations, not multiplications.

The recording trap 🪤

The assumption that "serious audio requires pre-recorded files" is the most common limitation in mobile audio design.

Recorded audio is consistent. It sounds the same on every device. For premium audiobooks or studio-produced content, recording is the right choice.

But for applications where content volume is high, languages are numerous, and the content itself is text — scripture, literature, educational material — recorded audio creates a maintenance problem that grows faster than the content.

If your app supports multiple languages and each language requires a full set of recorded audio files, you have multiplied your content pipeline by the number of languages. Every correction or addition requires re-recording in every language.

A sequence-driven, multi-voice TTS approach sidesteps that entirely. The text is the source. The device provides the voice. The platform handles orchestration. The result scales with content volume, not with the number of audio engineers available.

For Sanskrit specifically, this is especially powerful. Recording Sanskrit audio correctly requires a native speaker with precise pronunciation knowledge. A TTS-based approach can leverage engine and voice improvements over time without re-recording everything.

The trade-offs ⚖️

This approach is not without costs.

Voice quality varies by device, engine, voice selection, and version. 📱 Pre-recorded audio sounds the same everywhere. Device TTS voices vary in naturalness, pronunciation, and prosody. Multi-voice selection and version adaptation add more variables.

Voice capability is opaque and shifting. 🔍 There is no standard API to ask a voice "can you speak this character correctly?" and no guarantee the answer will be the same after the next OS update. The platform may need to discover capabilities empirically and re-evaluate them over time.

Sequencing complexity is real. 🧩 Managing a continuous queue of segments with multi-voice fallback, role-based voice assignment, version adaptation, and smooth transitions is genuinely complex infrastructure.

Content must be structured. 📋 Sequence-driven TTS works best when content has clear segment boundaries and role metadata.

These are the trade-offs the design accepts. The alternative — pre-recorded audio — trades scalability and language coverage for voice consistency. SskCore's approach trades some voice consistency for massive scalability, automatic language coverage, version resilience, and the ability to handle complex scripts that standard voices refuse to speak.

A safe thought experiment 🧪

If you maintain an Android application that uses TTS, try this:

Pick a language with a complex script — Sanskrit, Tamil, Tibetan, Thai, or any language with conjunct characters or stacked vowel marks.
Initialize the standard TextToSpeech API and attempt to speak a sentence containing edge-case Unicode characters.
Try it with the "native" voice first. Then try it with a related language's voice (Hindi for Sanskrit, Malayalam for Tamil, etc.).
Observe the difference. You may find that the "wrong" voice speaks the text better than the "right" one.
Now test on a different Android version or device manufacturer. You may find that a voice that worked on one device fails silently on another.
Ask yourself: if this language were required for your app, how would you decide which voice to use? And what happens when the voice you chose silently skips a word — or stops working after an OS update?

The question is not "does my app need Sanskrit?" The question is "what happens when a user speaks a language your chosen TTS voice handles poorly — on a device you never tested, running an Android version you did not anticipate?" For most apps, the answer is silence. For a platform that treats TTS as infrastructure, the answer is a fallback that keeps the audio flowing.

TTS is infrastructure 🏗️

Most mobile applications treat text-to-speech as a feature they integrate. A few lines of code, a voice selection, a speak() call.

SskCore treats TTS as infrastructure: a sequence-driven, multi-engine, multi-voice, role-oriented, version-adaptive capability — with word-accurate highlight and reliable progress as part of the contract — that can serve any content domain, including languages where the standard API's own voices fail silently, and where voice behavior shifts across devices and OS versions.

The platform owns the hard problems — engine selection, voice selection, character handling, version adaptation, sequencing, transitions, continuity, highlight mapping, progress, focus handling, and stall detection — so consumer applications can offer rich audio experiences without rebuilding the orchestration layer.

That is why the architecture is reusable. It does not solve "speak this sentence." It solves "play this entire sequence correctly, in any language, with the right voice, on any device, without silently skipping words — and keep the UI perfectly in sync."

When the engineering problem shifts from a single API call to a systems-level capability, the design has to follow. 🎯

Try the production result: Bhagavad Gita: The Song of God on Google Play — 4.6★, 10K+ downloads, 24 languages, built on this TTS platform.

SskCore is an internal Android engineering platform built from recurring production lessons across multiple applications. This article discusses the general engineering principle of multi-voice TTS orchestration and sequence-driven playback as reusable platform capabilities; it does not disclose internal class names, module structures, engine-selection algorithms, voice-selection logic, character-mapping configuration, or repository locations.

SskCore: Turning Production Pain Into an Android Platform [PART-6]

Shubham Nanche — Sat, 29 Aug 2026 06:57:52 +0000

Reusable Code Is Not Reusable Until It Has a Contract

Most Android teams discover the difference between shared code and reusable infrastructure at the worst possible moment: after a change to shared behavior breaks more than one application.

The pattern is familiar. A utility module, a shared component, or a common layer gets copied or referenced by a second application. It works. A third application joins. It works too. Then the platform team changes a default, renames a public surface, or shifts an integration expectation, and two separate teams file bugs on the same day.

Nothing was wrong with the code. What was missing was a contract: a clear statement of what the shared infrastructure promises, what it owns, and what the consumer is allowed to decide for itself.

The gap between shared source and reusable infrastructure

Shared code is a starting point. It removes duplication, and that is valuable. But shared code without a contract is just a dependency with undocumented assumptions.

When there is one consumer, those assumptions feel harmless. The platform author and the consumer author are often the same person, or sitting in the same conversation. Every default is understood implicitly because only one team depends on it.

That changes as soon as a second and third application enter the picture. Now there are:

Multiple sets of expectations about what the platform provides.
Different opinions about which defaults are sensible.
Different release schedules and different risk tolerances.
Different levels of experience with the shared infrastructure.

Without a contract, every implicit assumption becomes a latent incompatibility. The platform author does not know which behaviors consumers are relying on. Consumers do not know which behaviors are guaranteed versus accidental.

That is how shared code quietly stops being reusable: not because it breaks, but because no one can safely evolve it.

What a contract actually means

A contract for shared Android infrastructure is not a legal document or a ceremony. It is a small set of intentional decisions that make integration predictable.

A useful contract answers these questions:

1. What does the platform own?

The platform must be explicit about which behavior it maintains and guarantees. That might include:

A default configuration or resource set.
A particular lifecycle expectation for a component.
A specific integration surface that consumers are meant to call.

If the platform owns a behavior, it must be prepared to evolve that behavior deliberately and to communicate what changed. Owning a default means owning the migration path when that default shifts.

2. What does the consumer own?

A consumer that integrates shared infrastructure should know exactly which parts it is allowed to override, configure, or replace.

This is where a lot of shared code fails. The platform provides a default, but there is no clear boundary between "the platform ships this" and "the consumer controls this." As a result, two consumers override different parts, and neither team knows whether the override is safe, supported, or going to survive the next platform update.

A contract separates what is provided from what is customizable. That separation is what makes a component reusable rather than merely shared.

3. What defaults exist, and what do they mean?

Defaults are design decisions. They are choices the platform author made for a reason, usually because a particular behavior works well across most expected use cases.

But defaults carry an implicit promise: if a consumer does not override the behavior, the platform will handle it predictably.

If the platform later changes that default without notice or migration support, it has broken that promise. The consumer trusted the default, and now the consumer's behavior has changed without its team's involvement.

A good contract says:

Here is the default.
Here is what it means.
Here is how to override it safely.
Here is what happens when the platform evolves and this default shifts.

4. How does migration work?

This is the question most shared-code arrangements avoid until it is urgent.

If the platform is going to change a behavior, a consumer must be able to migrate deliberately. That requires:

Knowing that a change is coming.
Understanding which parts of the consumer's integration are affected.
Having a clear path to adapt without a forced emergency upgrade.

Migration is not a nice-to-have. It is part of the contract. A platform that changes without providing a migration path is not reusing its own lessons; it is imposing them.

The ownership problem

The hardest part of designing a contract is not writing defaults. It is deciding who owns the consequence when things change.

Consider a platform that provides a default theme or resource set. The platform author chose those defaults because they fit the original use case. A consumer adopted the platform and relied on those defaults because that is what the platform offered.

Now the platform evolves. The defaults shift to accommodate a new requirement from a different application.

Who is responsible for the impact on the first consumer?

Without a contract, the answer is ambiguous. The platform author may assume consumers should have overridden the default if they cared. The consumer may assume the platform would not change defaults without notice. Both assumptions are reasonable. Both are undocumented.

A contract resolves this by making ownership explicit:

If the platform owns a default, the platform owns migration support.
If the consumer overrides a behavior, the consumer owns keeping that override compatible with future platform versions.
If a default is intentionally unstable or experimental, that must be stated.

This is what separates reusable infrastructure from shared source: someone has decided who owns the consequences of change.

The trade-off: flexibility versus predictability

There is a real tension here.

If the platform is too rigid, consumers feel restricted. They cannot adapt shared behavior to their specific needs, and the platform becomes an obstacle instead of a convenience.

If the platform is too flexible, consumers lose predictability. Every application integrates the same shared code differently, and the platform team cannot reason about its own behavior across consumers.

The answer is not to choose one extreme. It is to design a contract that provides a stable core with clearly defined customization points.

A useful mental model:

Guaranteed behavior: what the platform provides reliably, and what consumers can depend on across versions.
Customizable behavior: what consumers are explicitly allowed to change, with documented boundaries.
Unsupported behavior: what consumers might technically be able to modify but should not, because the platform will not preserve compatibility for it.

That last category is important. Most shared code does not distinguish between "customizable" and "unsupported." Everything looks like it can be changed, until a platform update breaks the change and neither side recognizes it as a contract violation.

Why this matters beyond the first consumer

The value of a contract grows non-linearly.

With one consumer, implicit understanding works.

With two consumers, different assumptions start to surface, but the teams can usually negotiate informally.

With three or more consumers, informal understanding breaks down. Each team has made different choices about defaults, overrides, and integration patterns. The platform team cannot predict the impact of a change because it does not know which implicit assumptions each consumer is relying on.

At that point, the lack of a contract does not cause a single incident. It causes a pattern of small, recurring surprises that slowly erode trust in the shared infrastructure.

The fix is not more communication or more meetings. The fix is making the contract explicit enough that each consumer can reason about its own integration independently.

A safe thought experiment

If you maintain or depend on shared Android code, try this:

Identify a shared component or module that more than one application uses.
Ask whether you can describe, in one paragraph, what the platform guarantees, what the consumer controls, and what happens when the platform changes.
Ask whether a new team, reading that paragraph, could integrate the component without relying on the author's memory.

If the answer is unclear in any of those steps, the shared code has a contract gap.

The fix does not have to be elaborate. A short document that states defaults, customization boundaries, ownership, and migration expectations is a significant improvement over undocumented assumptions.

The goal is not documentation for its own sake. The goal is making shared infrastructure safe to adopt, safe to use, and safe to evolve.

Reusability is a design property

Shared code becomes reusable when someone designs it to be reused.

That means:

Defaults are chosen intentionally and documented.
Integration boundaries are explicit.
Consumer overrides are supported and scoped.
Platform evolution includes migration awareness.
Ownership of consequences is clear.

Without those properties, shared code is a convenience with a shelf life. It works until it does not, and when it stops working, no one is sure whose responsibility it is to fix.

SskCore was built with the assumption that reusable infrastructure needs a contract, not just a source tree. The platform makes integration boundaries, defaults, ownership, and migration expectations part of the design rather than an afterthought.

That is what makes it possible for a shared platform to evolve without turning every update into a surprise for the applications that depend on it.

SskCore is an internal Android engineering platform built from recurring production lessons across multiple applications. This article discusses the general engineering principle of integration contracts for shared infrastructure; it does not disclose internal defaults, class names, module structures, migration scripts, repository locations, or platform configuration details.

SskCore: Turning Production Pain Into an Android Platform [PART-5]

Shubham Nanche — Fri, 28 Aug 2026 06:38:22 +0000

A Release Is a Historical Claim, Not a Successful Local Build

Here is a useful test for any Android application that depends on shared code:

Take an older release of the application and ask whether it can be rebuilt on a clean machine without guessing.

Not merely compiled after updating a few dependencies. Not rebuilt with whatever the shared library happens to contain today. Rebuilt from the same meaningful inputs that produced the artifact users received.

If that answer is uncertain, the release is not fully reproducible.

That may sound like a build-system detail. It is not. It is a statement about whether a team can trust its own history.

SskCore was designed around a tension that appears in most internal Android platforms:

Developers need the speed of working against current source. Releases need the certainty of immutable, versioned inputs.

Both needs are legitimate. The failure comes from treating them as the same workflow.

The experiment: can you explain an old release?

Pick a release from any mobile application you own or maintain. In a clean, disposable environment, see whether the project itself can answer these questions:

Which application revision was released?
Which shared-library revision was part of that release?
Which build inputs and dependency versions were expected?
Can another engineer recreate that state without depending on a developer's current workstation?

The point is not to create a perfect archival system in one afternoon. The point is to notice where uncertainty enters.

If a build silently compiles whatever shared source happens to be available locally, then the artifact is tied to a workstation state rather than a clear release contract. That can be convenient during development and deeply confusing later.

Why local source is still valuable

The answer is not to ban local source.

When engineers are building shared infrastructure, fast source-level iteration is one of the best feedback loops available. A platform change can be tested in a real consumer application before it is published as a release. Developers can diagnose integration behavior without waiting for a new artifact at every small step.

That speed matters. It is how platform work stays connected to the applications it is meant to serve.

But source-level iteration has a property that makes it unsuitable as the default shipping input: it reflects the current local state, not a stable historical identity.

That is excellent for experimentation. It is weak evidence for a release.

The two promises a platform must make

SskCore therefore treats development and release as different promises.

The development promise: move quickly

During active work, a consumer application can use current platform source. The engineer sees a change in the context where it matters, gets immediate feedback, and can iterate across the application-platform boundary without unnecessary ceremony.

The question being answered is:

Does this change work in the consumer we are actively improving?

That is a present-tense question. It is about learning.

The release promise: rebuild confidently

During release, a consumer uses an explicit, versioned platform input. That makes the relationship between the application and its shared infrastructure a documented fact rather than an accidental property of a machine.

The question being answered is different:

Can we explain and recreate what we shipped?

That is a historical question. It is about confidence.

Both workflows are useful. Confusion begins when a team allows an artifact intended for users to inherit the uncertainty of an in-progress local checkout.

Why the distinction matters after release day

The value of reproducibility often becomes visible only when something goes wrong.

Imagine investigating a bug reported against an older application version. If the application is rebuilt against today's shared platform source, the investigation is already compromised. A behavior may have changed, a dependency may have moved, or an unfinished fix may have altered the result.

Now the team is not comparing the report with the original product. It is comparing the report with a new, partly unknown combination of inputs.

That slows debugging and weakens conclusions.

With pinned, versioned release inputs, an older tag is more than a snapshot of application code. It is a coherent statement of the platform relationship at the time of release. Engineers can ask a more useful question:

What did this version actually contain?

That is the foundation for trustworthy reproduction, targeted fixes, and meaningful regression checks.

The risk of invisible mixing

The most dangerous case is not an obvious build failure. It is a successful release build that quietly mixes stable application inputs with unshipped shared-platform changes.

Everything may work on the developer's device. The resulting artifact may even look correct in testing. But the team has lost a critical boundary: nobody can point to a published platform version and say, with confidence, "This is what users received."

SskCore protects that boundary by making the difference between local iteration and release consumption explicit. The public idea is straightforward:

Current source is for learning and development.
Versioned artifacts are for releases.
A workflow should make accidental crossover difficult to miss.

The details vary across organizations and tooling. The principle does not.

Release engineering is a developer-experience concern

It is easy to frame this as compliance or process overhead. I think that misses the point.

Good release engineering improves developer experience because it reduces guessing.

It gives developers a fast path when they are experimenting and a dependable path when they are shipping. It prevents the false choice between moving quickly and being able to explain the result later.

The better design is to support both deliberately.

For SskCore, this matters because the platform serves multiple applications. A change to shared infrastructure should be easy to test in the present while older consumers remain able to rebuild from the past. That is what allows a shared platform to evolve without turning every release into a memory test.

A release is evidence

A production artifact is not just a file that successfully passed through a build pipeline.

It is evidence of a specific engineering decision: these were the sources, dependencies, and shared-platform inputs that became the product users received.

When that evidence is reproducible, teams can debug with less ambiguity, upgrade more deliberately, and retain confidence in the history of their own software.

That is why “it works on my machine” is not a release strategy.

It is a useful development observation.

SskCore exists in part to preserve the distinction.

SskCore is an internal Android engineering platform built from recurring production lessons across multiple applications. This article intentionally discusses release-engineering principles and outcomes only; it does not disclose private build logic, repository structure, release commands, artifact locations, or security controls.

SskCore: Turning Production Pain Into an Android Platform [PART-4]

Shubham Nanche — Thu, 27 Aug 2026 05:53:23 +0000

When Background Work Outlives the Screen That Started It

Start a download in an Android app, then leave the screen that started it.

That small action exposes a design question that many applications postpone for too long:

Who owns the task once the user no longer owns the screen?

The answer is often accidental. A download begins inside a dialog, a screen shows a progress indicator, and everything appears reasonable while the user stays exactly where the developer expected. Then the user navigates back, rotates the device, starts something else, or simply returns later.

The operation may still be active. The UI that explained it may not be.

This is not merely a progress-bar issue. It is an ownership issue.

SskCore treats long-running work as a reusable product and platform concern. The goal is to make an operation understandable throughout its lifecycle without coupling the underlying operation to one particular screen or presentation style.

The experiment

The next time you use an Android application that downloads optional content, installs a capability, exports data, or synchronizes something substantial, try this:

Start the operation.
Leave the initiating screen.
Return later.
Look for an answer to four questions.

Is the work still visible?
Can the user understand its current state?
Is there an appropriate cancel or retry path?
Does the application preserve a useful record of the result?

Many applications handle the happy path well: the user watches the loading indicator and waits. The difficult part is designing for ordinary interruption.

People do not interact with mobile software as a linear script. They switch screens, respond to notifications, rotate devices, lose connectivity, and revisit an app after attention has moved elsewhere. A task experience that exists only inside the initiating screen is fragile because it assumes the screen and the task share a lifecycle.

They usually do not.

Why a screen-local progress indicator is not enough

Screen-local progress is useful. It tells a user that an action has begun, and it provides immediate feedback in the moment.

The problem starts when it becomes the only representation of the work.

Consider a few common cases:

A user begins downloading optional language content and closes the picker.
A user requests an on-demand experience and returns to the home screen while it is prepared.
A user starts an export, then needs to answer a message.
A sync encounters a temporary failure after the original screen is gone.

In each case, the operation matters independently of the screen. If the application has no shared task model, developers often rebuild the same state management, copy similar progress UIs, and make slightly different decisions about cancellation, retry, and completion in every feature.

That is how background work becomes inconsistent.

The SskCore idea: lifecycle and presentation have different owners

The key architectural decision in SskCore is simple to describe:

The platform owns the lifecycle of a long-running task. The consuming application owns how that task is presented to its users.

This separation is more valuable than it first appears.

The lifecycle side needs to answer questions that should behave consistently across product features:

When is work considered active?
How is progress updated?
What counts as completion, failure, or cancellation?
When should a task stop being active but remain discoverable in history?
How is duplicate representation of the same work avoided?

The presentation side is necessarily product-specific:

What should the task be called?
Which wording is useful in this app and language?
Does the user need a detailed view or a compact status?
Which actions make sense for this operation?
Where should status be visible without interrupting the current screen?

Combining those responsibilities tightly creates a familiar problem: a shared service becomes full of UI assumptions, or every feature has to recreate lifecycle behavior for itself.

Separating them allows the same platform behavior to support different user experiences without forcing one visual design onto every consumer.

What users should be able to expect

Users do not care whether work is implemented through a service, a library, or an external platform integration. They care about whether the application is honest about what it is doing.

A coherent task experience should make a few things predictable:

Work remains visible after navigation

Leaving a screen should not turn a real operation into a mystery. A user should be able to find an active task without retracing the exact path that started it.

States have a consistent meaning

Pending, running, completed, failed, and cancelled should not be interpreted differently in every feature. Consistency reduces both user confusion and engineering repetition.

Actions match the task state

When cancellation is possible, it should be discoverable while the task is active. When retry is meaningful, it should be available after a recoverable failure. Completed work should not continue to look active simply because a view was not updated.

Finished work can leave a useful trace

Some operations are important enough that users should be able to understand what happened after the immediate moment has passed. A lightweight history is not just an implementation detail; it is a way of respecting the user's time and attention.

Why this is platform work rather than one feature

It would be easy to build a progress experience for a single language download or a single feature installation. It would be much harder to keep that experience consistent as more long-running operations appear across several applications.

That is the point at which a reusable platform earns its place.

SskCore turns the shared part of the problem into infrastructure: lifecycle expectations, status consistency, active-task handling, and task history. Consumers then bring their own product language and user-facing meaning.

The result is not a one-size-fits-all UI. It is a reusable contract:

Operations remain decoupled from presentation.
Applications can use appropriate language for their users.
Similar work follows familiar lifecycle rules.
New capabilities do not need to reinvent the entire task experience.

This is a small example of a larger platform-engineering principle: shared infrastructure should own the concerns that need to remain consistent, while applications retain the choices that need to remain distinct.

A real-world way to test the principle

In Bhagavad Gita, available language downloads provide a user-facing way to observe this idea. Start a download and leave the language-selection surface while the operation is underway. The test is not whether a single progress indicator animates correctly.

The test is whether the task remains understandable after its original UI context is gone.

That is a better standard for background work because it reflects how people actually use mobile applications.

The broader lesson

The difficult part of Android engineering is often not invoking a platform API. It is deciding where the responsibility should live after the initial feature is over.

Long-running work is one example. It can start in a feature, continue beyond that feature, affect the user's expectations elsewhere, and later become something every new application has to solve again.

SskCore exists to capture those recurring decisions as reusable infrastructure.

In this case, the lesson is straightforward:

A background task should not disappear because its first screen did.

When an application treats ongoing work as something users can still see, understand, and act on, it feels more dependable. When the engineering model is reusable, the next application does not have to rediscover that lesson from scratch.

SskCore is an internal Android engineering platform built from recurring production lessons across multiple applications. This article intentionally discusses principles and public behavior only; it does not reveal private implementation details, task identifiers, delivery configuration, or application controls.

SskCore: Turning Production Pain Into an Android Platform [PART-3]

Shubham Nanche — Tue, 25 Aug 2026 06:09:52 +0000

Modularization Is Risk Management, Not Folder Organization

When teams discuss modularization, the conversation often begins with a technical question:

How should we split the codebase?

That question matters, but it is not the most useful place to start.

The more useful question is:

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

That is the lens that gradually changed how I approached modularization while building SskCore, an internal Android engineering platform used across multiple applications.

This is not a guide to a particular folder structure, a fixed module count, or a universal architecture. It is a reflection on why dependency boundaries are a form of risk management, and why that matters especially in Android development.

A module is a promise about consequences

It is tempting to think of a module as a folder with a Gradle file. But that description misses its real role.

A module is a boundary. It tells an application, in effect: "If you adopt this capability, these are the responsibilities, trade-offs, and relationships you are choosing."

That makes module design less about rearranging code and more about making consequences visible.

For an application, bringing in a capability can affect much more than the functions it can call. It may influence:

Build complexity and feedback time
The dependency graph
Packaging behavior
Application size
Runtime behavior
Permissions and policy considerations
Testing surface area
Release confidence
Long-term ownership

None of those consequences is automatically bad. The problem begins when they are hidden inside a broad shared dependency and only become visible after adoption.

Good boundaries do not eliminate complexity. They make complexity easier to locate, discuss, and own.

Why one shared library eventually becomes uncomfortable

At the beginning, a single shared module is often a sensible choice. Several applications need common behavior, and centralizing it reduces duplication.

Over time, however, that convenience can create a quiet problem.

One application needs a user-interface concern. Another needs a platform integration. A third needs a data-related utility. The shared dependency grows because adding one more capability is easier than reconsidering the boundary.

Eventually, consumers can inherit things they did not consciously choose.

This is not a failure of shared code. It is a sign that the needs of the consumers have become more varied than the original boundary assumed.

That is the moment to stop asking, "Where can this code live?" and start asking, "Who should have to care that this exists?"

Optionality is a design decision

An application should be able to adopt the infrastructure it needs without inheriting unrelated behavior simply because both pieces of code happened to be shared.

In SskCore, that led to separate, intentional capabilities rather than a single all-encompassing dependency. The aim was not modularity for its own sake. The aim was optionality.

Optionality is valuable because it lets a consumer make a deliberate choice:

Does this application need this capability now?
Is its cost appropriate for this application?
Who owns integration and future change?
Can it evolve independently from unrelated infrastructure?

Those are product and operational questions as much as they are architecture questions.

For a user-facing application such as BhagavadGita, the result should not feel architectural at all. Users should experience a focused, dependable product. The platform work exists underneath that experience, helping each capability remain intentional as the product evolves.

Android makes dependency consequences more visible

Every ecosystem has dependency management challenges, but Android gives those decisions a particularly wide surface area.

A dependency can influence build behavior, resource processing, packaging, application size, device compatibility, release behavior, and runtime experience. A change that looks small in source code can therefore have effects that only emerge later in integration or release workflows.

That does not mean dependencies should be feared. It means they deserve to be treated as engineering decisions with visible consequences.

The practical shift is simple:

Do not ask only whether a dependency is useful.

Ask what adopting it changes for the application.

That question encourages better conversations before a dependency becomes difficult to undo.

More modules are not automatically better

There is an equal and opposite mistake: treating a high module count as evidence of good architecture.

It is not.

Splitting every small piece of code into an independent module can create fragmentation, extra coordination, and an architecture that is harder to navigate than the original codebase. A boundary that has no meaningful purpose only creates another place for developers to look.

The goal is not maximum separation. The goal is meaningful separation.

A boundary is worth considering when it clarifies one or more of the following:

Capability ownership
Consumer choice
Dependency cost
Release scope
Change isolation
Lifecycle and maintenance responsibility

If a proposed module does not make one of those things clearer, it may not be solving a real problem.

A decision framework for boundaries

There is no universal module map, but a small set of questions can make the decision more deliberate.

1. Is the capability genuinely reusable?

Reuse is not the same as similarity. Two applications can have related needs while still requiring different behavior, product decisions, or ownership. A capability belongs in shared infrastructure when the shared contract is clearer and more durable than copying the code.

2. Can a consumer adopt it intentionally?

A consumer should be able to understand what it is choosing. If adopting a capability silently brings in unrelated responsibilities, the boundary may be too broad.

3. Does it have a coherent lifecycle?

Capabilities change. They need versioning, ownership, documentation, and a migration story. A useful module boundary gives those changes a place to happen without making every consumer absorb every decision.

4. Does it reduce the blast radius of change?

Isolation is not about pretending that systems are independent. It is about making the likely impact of a change easier to reason about before release.

5. Can an unfamiliar engineer understand why it exists?

If a boundary only makes sense to the person who created it, it is not yet doing enough work. Architecture should preserve reasoning, not hide it.

The connection to release confidence

Modularization is often treated as a code-organization concern. In practice, it also shapes release confidence.

When capabilities are intentionally separated, a team can have a clearer conversation about what changed, which consumers are affected, and where verification should be focused. That clarity is valuable even when the final release still involves many moving parts.

The point is not to claim that boundaries make releases risk-free. They do not.

The point is that unintentional coupling creates surprises, and surprises are expensive near release time.

Thinking in terms of dependency consequences helps move that discussion earlier, when decisions are easier to change.

The connection to developer experience

There is also a developer-experience benefit.

Developers move more confidently when the capabilities they use have understandable integration points, clear documentation, and predictable behavior. They spend less time reconstructing hidden assumptions and more time making deliberate changes.

That is why modularization cannot be separated from documentation and tooling. A clean boundary without context still leaves a developer guessing. A well-documented boundary turns structure into a usable contract.

This was one of the lessons that shaped SskCore: platform work is not only about making code shareable. It is about making shared decisions understandable to the next person.

The bigger lesson

Modularization is not an end state. It is an ongoing way of asking whether the shape of a system still reflects the shape of its responsibilities.

The most useful boundaries are not the most numerous ones. They are the ones that make ownership, adoption cost, and change consequences easier to see.

That is why I think of modularization as risk management.

Not because every module makes a system safer, but because intentional boundaries make accidental consequences more visible.

And in a growing Android codebase, making consequences visible is often the first step toward making them manageable.

SskCore is an internal Android engineering platform built from recurring production lessons across multiple applications. This article intentionally discusses principles and outcomes only; it does not describe private implementation details or release mechanisms.

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.

DEV Community: Shubham Nanche

SskCore: Turning Production Pain Into an Android Platform [PART-7]

Text-to-Speech Is Not a speak() Call

The challenge 🧪

The twist 🔄

What happened in production 🏭

This is NOT just a Sanskrit problem 🌍

The assumption that breaks everything ⚠️

The problem gets worse with continuous playback 🎵

The multi-engine, multi-voice approach 🔀

Sequence-driven, role-oriented playback 🎭

What the UI actually needs: highlight and progress ✨

Why this is a platform problem 🏗️

The recording trap 🪤

The trade-offs ⚖️

A safe thought experiment 🧪

TTS is infrastructure 🏗️

SskCore: Turning Production Pain Into an Android Platform [PART-6]

Reusable Code Is Not Reusable Until It Has a Contract

The gap between shared source and reusable infrastructure

What a contract actually means

1. What does the platform own?

2. What does the consumer own?

3. What defaults exist, and what do they mean?

4. How does migration work?

The ownership problem

The trade-off: flexibility versus predictability

Why this matters beyond the first consumer

A safe thought experiment

Reusability is a design property

SskCore: Turning Production Pain Into an Android Platform [PART-5]

A Release Is a Historical Claim, Not a Successful Local Build

The experiment: can you explain an old release?

Why local source is still valuable

The two promises a platform must make

The development promise: move quickly

The release promise: rebuild confidently

Why the distinction matters after release day

The risk of invisible mixing

Release engineering is a developer-experience concern

A release is evidence

SskCore: Turning Production Pain Into an Android Platform [PART-4]

When Background Work Outlives the Screen That Started It

The experiment

Why a screen-local progress indicator is not enough

The SskCore idea: lifecycle and presentation have different owners

What users should be able to expect

Work remains visible after navigation

States have a consistent meaning

Actions match the task state

Finished work can leave a useful trace

Why this is platform work rather than one feature

A real-world way to test the principle

The broader lesson

SskCore: Turning Production Pain Into an Android Platform [PART-3]

Modularization Is Risk Management, Not Folder Organization

A module is a promise about consequences

Why one shared library eventually becomes uncomfortable

Optionality is a design decision

Android makes dependency consequences more visible

More modules are not automatically better

A decision framework for boundaries

1. Is the capability genuinely reusable?

2. Can a consumer adopt it intentionally?

3. Does it have a coherent lifecycle?

4. Does it reduce the blast radius of change?

5. Can an unfamiliar engineer understand why it exists?

The connection to release confidence

The connection to developer experience

The bigger lesson

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

The Grey Screen

The FAB That Disappeared

The Permission That Leaked

The Platform That Emerged

What Makes It Different

Automatic Source/Binary Switching

60+ Custom Gradle Tasks

ModuleMap Architecture

Catalog-Driven Module Discovery

Text-to-Speech Is Not a `speak()` Call