Why Download the "Payment" Feature for Users Who Only Browse? Implementing Dynamic Delivery

 A Senior Engineer’s Guide to Reducing App Install Size by 50% Using On-Demand Feature Modules and Navigation Contracts.

Dynamic Delivery

TL;DR

  • Use Dynamic Feature Modules for large, heavy features with low usage or regional constraints.
  • Configure delivery in the feature module’s AndroidManifest.xml, not Gradle.
  • Invert dependencies: Feature modules depend on the Base; use Navigation Contracts and Service Discovery to communicate.
  • Treat downloads like network calls: Wrap SplitInstallManager in a Repository to handle state and idempotency.

You’ve spent months optimizing your Android app. You audited dependencies, converted PNGs to WebP, and fine-tuned R8. Your APK is lean — but then, a new requirement arrives: a heavy 3D rendering engine for a “Virtual Try-On” or a specialized KYC verification flow that only 5% of your users will ever touch.

Suddenly, your 15MB app jumps to 45MB.

For users in regions with expensive data or limited storage, that 30MB increase is a high barrier to entry. Senior engineers don’t accept this bloat; they use Dynamic Delivery.

1. Identifying “On-Demand” Candidates

Modularization for the sake of modularization is a technical debt trap. To find features that truly deserve to be “Dynamic,” look for these three red flags in your monolith:

  • High Weight / Low Frequency: A 10MB “Customer Support Chat” used by 2% of users.
  • Conditional Access: Features locked behind a “Premium” paywall.
  • Distribution Constraints: A payment gateway that only functions in India shouldn’t be downloaded by a user in Brazil.

2. Defining Delivery: Manifest vs. Business Logic

In modern Android Gradle Plugin (AGP) versions, delivery is controlled via the AndroidManifest.xml of the feature module.

Use the <dist:module> tag to define the delivery contract.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:dist="http://schemas.android.com/apk/res-auto"
    package="com.example.photo_editor">

    <dist:module
        dist:onDemand="true"
        dist:title="@string/title_photo_editor">
        <dist:fusing dist:include="true" />
        
        <dist:conditions>
            <dist:device-country dist:code="IN"/>
        </dist:conditions>
    </dist:module>
</manifest>

3. Architecture: Navigation & Discovery

In Dynamic Delivery, the Feature Module depends on the Base Module. This creates a visibility problem: the Base cannot “see” the classes in the Feature.

To avoid fragile, string-based Intents, use a discovery pattern:

  1. Hilt EntryPoints: The gold standard for DI-heavy apps.
  2. ServiceLoader: A clean, standard Java/Kotlin way to discover implementations.
  3. Navigation Contracts: Define an interface in your Base Module that the Feature Module implements.

4. Implementing a Production-Grade Install Flow

Don’t let your UI talk directly to the SplitInstallManager. Instead, encapsulate the logic. This repository becomes the single source of truth for feature installation state across the app.

class FeatureInstallRepository(private val manager: SplitInstallManager) {

    fun installModule(moduleName: String): Flow<InstallState> = callbackFlow {
        // Note: moduleName must match the Gradle module name, not the package name.
        if (manager.installedModules.contains(moduleName)) {
            trySend(InstallState.Installed)
            close()
            return@callbackFlow
        }

        val request = SplitInstallRequest.newBuilder().addModule(moduleName).build()
        val listener = SplitInstallStateUpdatedListener { state ->
            trySend(state.toDomainState())
        }

        manager.registerListener(listener)
        manager.startInstall(request)
        
        awaitClose { manager.unregisterListener(listener) }
    }
}

⚠️ When NOT to use Dynamic Delivery

Dynamic delivery is powerful, but it introduces complexity. Avoid it if:

  • Core Logic: The feature is required for the app to boot or perform its primary function.
  • High Usage: If >80% of your users use the feature, the overhead of the download flow outweighs the size savings.
  • Cold Start Features: Anything needed immediately upon clicking the app icon.
  • Lack of Testing Infrastructure: If your team isn’t prepared to maintain a complex CI/CD pipeline that handles multi-module instrumentation.

🙋‍♂️ Frequently Asked Questions (FAQs)

Can I uninstall a module to save space?

Yes! Use splitInstallManager.deferredUninstall(listOf("onboarding")). Google Play prunes the code during the next background maintenance cycle.

Does this affect Hilt?

Yes. Since the Base doesn’t know about the Feature, you must use Hilt EntryPoints to “peek” into the feature’s component once it’s installed.

What is the “Install Size” benefit?

Google Play case studies report that apps using Dynamic Delivery see an average 20% to 50% reduction in initial install size, which significantly improves conversion rates in emerging markets.

💬 Let’s Discuss!

  • Analyze your APK: Open your latest build in the APK Analyzer. What is the single largest package that isn’t required for the app’s first five minutes?
  • Degraded Navigation: How does your app behave if the user clicks a dynamic feature while offline?
  • Discussion: What has been your biggest hurdle with dynamic modules — DI, navigation, or CI/CD?

Video References

📘 Master Your Next Technical Interview

Since Java is the foundation of Android development, mastering DSA is essential. I highly recommend “Mastering Data Structures & Algorithms in Java”. It’s a focused roadmap covering 100+ coding challenges to help you ace your technical rounds.

Comments

Post a Comment

Popular posts from this blog

No More _state + state: Simplifying ViewModels with Kotlin 2.3

Image
 Clean up your Android code with Explicit Backing Fields—the modern way to handle read-only state without the boilerplate. TL;DR:  Kotlin 2.3 introduces  explicit backing fields , allowing you to replace the classic  _state  +  state  boilerplate with a single, cleaner property—provided you're okay with a few experimental trade-offs. If you’ve been developing Android apps, you know the “Backing Property Dance.” It’s that repetitive ritual where we create a private  MutableStateFlow  and a public  StateFlow  just to ensure encapsulation. The “Old” Way (The Boilerplate) private val _uiState = MutableStateFlow(UiState.Loading) // Exposing a read-only view of the mutable internal state val uiState: StateFlow<UiState> = _uiState.asStateFlow() We’ve done this for years to prevent external classes from mutating our state. While effective, it pollutes our IDE suggestions with underscores and adds unnecessary ceremony to every singl...
Read more

Why You Should Stop Passing ViewModels Around Your Compose UI Tree 🚫

Image
 Master State Hoisting and the "Route-level" pattern to build scalable, testable, and preview-friendly Android apps. If you’ve been building with Jetpack Compose for a while, you know how tempting it is to just pass a  ViewModel  instance down through five layers of UI components. It’s convenient—one object gives you all the data and all the functions you need. But here is the architectural reality:  Passing ViewModel instances deep into your UI tree is an architectural anti-pattern.  It couples your visual components to business logic and makes your code significantly harder to maintain, test, and preview. The Core Problem: Lifecycle and Scoping ViewModels are designed to be state holders tied to a specific lifecycle (usually a Navigation Destination). When you pass a ViewModel into a small UI component, you break the  Unidirectional Data Flow (UDF) . ❌ The “Bad” Way (Tight Coupling) // ❌ BAD: This component is now impossible to preview or reuse @Composabl...
Read more

Is Jetpack Compose Making Your APK Fatter? (And How to Fix It)

Image
 Unpacking the Compose Tax, compiler-driven DEX optimization, and why your resource strategy must evolve for modern UI. TL;DR DEX Bloat:  Compose’s compiler injects “Restartable” and “Skippable” logic for memoization; R8 minification is effectively required. Code vs. Assets:  Moving iconography to  ImageVector  constants allows R8 to prune unused assets as code. Tooling Leak:   ui-tooling  in release builds is the #1 cause of "false" bloat. The Scale Factor:  Compose has a higher “size floor” but a much lower “size ceiling” than the legacy View system. The promise of Jetpack Compose was simple: “Write less code, ship faster.” But as teams migrate, a quiet concern often echoes in code reviews:  “Why did our APK size just jump?” While Compose removes the weight of deep XML hierarchies and the overhead of ViewBinding, it introduces a unique “Compose Tax.” For a senior engineer, the goal isn’t just to accept this tax, but to optimize the runtime...
Read more