How to Combat Android Manifest Decay: Best Practices and Tools

Engineering decay is a subtle but pervasive problem in app iteration that can affect development efficiency, product quality, stability, package size, and performance. Unlike a one‑time fix, it requires a sustainable governance approach.

Why Manifest Matters

The AndroidManifest.xml file is the core manifest of an APK, containing critical information that influences build‑time processing, runtime behavior, and app‑store filtering.

Manifest Merge Process

During the build, manifest files from the app module, AAR sub‑projects, and external dependencies are merged into a single AndroidManifest.xml. The merge proceeds from low to high priority, considering source priority, module declaration order, build variant, build type, and product flavor dimensions.

Conflicts are resolved by preferring higher‑priority values; developers can also add tools namespace attributes to control the merge.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapplication"
    xmlns:tools="http://schemas.android.com/tools">

Merge Control

By adding tools: attributes to XML nodes or attributes, developers can explicitly dictate how elements are merged.

Manifest Placeholders

Placeholders allow values to be injected from build.gradle into the manifest.

# In build.gradle
android {
    defaultConfig {
        manifestPlaceholders = [customKey:"customValue"]
    }
}

# In AndroidManifest.xml
<intent-filter ... >
    <data android:scheme="https" android:host="${customKey}" />
</intent-filter>

<meta-data android:name="sampleMeta" android:value="${customKey}"/>

The default placeholder ${applicationId} is bound to the applicationId defined in the Android DSL.

Merge Decision Log

The merge decision log records the origin of every node and attribute in the final manifest, aiding debugging.

activity#com.example.myapplication.MainActivity
ADDED from /path/to/AndroidManifest.xml:18:9-24:20
  android:name
    ADDED from /path/to/AndroidManifest.xml:18:19-47
intent-filter#action:name:android.intent.action.MAIN+category:name:android.intent.category.LAUNCHER
ADDED from /path/to/AndroidManifest.xml:19:13-23:29
...

Global Configuration Checks

Key global settings such as minSdkVersion and targetSdkVersion are validated against a whitelist. Mismatches can abort the build.

[absent] [uses-feature] android.hardware.camera    # missing feature
[conflict] [uses-sdk]
|-- com.youku.arch:testlib:0.1-SNAPSHOT
|   |-- [attr] targetSdkVersion
|   |   |-- [whitelist] 29
|   |   |-- [current] 28
|   |-- [attr] minSdkVersion
|   |   |-- [whitelist] 14
|   |   |-- [current] 21

Permission Management

Permissions must be strictly aligned with privacy policies. Two detection capabilities are provided:

Module‑level permission listing.

Bidirectional whitelist checking for excess or absent permissions.

[excess] [uses-permission] android.permission.CALL_PHONE    # not in whitelist
|-- project:app:1.0
[absent] [uses-permission] android.permission.ACCESS_NETWORK_STATE    # missing in manifest
|-- com.youku.arch:testlib:1.0

Component Export Governance

Components with android:exported="true" can be invoked by other apps. Implicit export rules require explicit declaration when targetSdkVersion is 31 or higher; otherwise builds may fail.

Export control rules include:

Close export for unnecessary self‑written components.

For third‑party components, set android:exported="false" via merge rules.

Keep export for necessary self‑written components during debugging, but centralize them in a shared toolbox.

For production‑ready self‑written components, route through a unified routing center.

Whitelist necessary third‑party exported components.

Component Detection

Three detection capabilities are offered:

Component‑to‑module mapping, highlighting duplicates or missing declarations.

Missing component reference detection, with optional build‑stop.

Exported component detection, with optional “ban implicit export” rule that flags implicit exports regardless of whitelist.

# Duplicate component example
[duplicate] [activity] com.example.myapplication.MainActivity
|-- project:app:1.0
|-- project:library-aar-1:1.0

# Deleted component example
[deleted] [service] com.example.myapplication.FirstService
|-- project:app:1.0

# Exported component example
[activity] com.youku.app.NPageActivity
|-- com.youku.android:YoukuHPage:1.9.43.8
[ignored][activity] com.ali.MIPreviewActivity
[implicit] [activity] com.youku.fbiz.RPageActivity

Overall Governance Landscape

Youku’s practice combines detection tools, build‑gate mechanisms, and a whitelist to protect manifest integrity, gradually reducing technical debt while ensuring compliance and security.