How to Resolve “Broken Functionality” Rejections: A Step-by-Step Manifest & Deep Link Audit

Receiving a “Broken Functionality” rejection from Google Play can be frustrating, particularly when an application installs successfully on your own device. However, an app may still fail review if important screens do not load, buttons do not respond, links open incorrectly, or essential features behave unexpectedly.

One effective way to investigate these problems is to perform a structured audit of the Android manifest, app navigation, deep links, network requests, and critical user journeys.

This guide explains how to identify common causes, test the application systematically, and prepare a reliable fix before submitting another release.

What Does “Broken Functionality” Mean?

Google Play expects apps to provide a stable, responsive, and meaningful user experience. Applications that crash, freeze, fail to load, or contain nonfunctional features may violate its functionality requirements.

Common examples include:

• An app that crashes immediately after launch.
• A login screen that never completes authentication.
• Buttons that do not perform their advertised actions.
• A page that remains blank because an API request fails.
• Deep links that open the wrong screen or display an error.
• Features that work only with a particular test account.
• A navigation flow that leaves users unable to return to the main screen.

The exact cause depends on the app and the review findings. A manifest or deep-link problem is only one possible explanation, so begin with the specific issue reported in Play Console.

Step 1: Read the Rejection Details

Open Google Play Console and select your application.

Review the policy status and the latest review communication. Identify the affected feature, screen, or behavior, and determine whether Google provided reproduction steps or other useful details.

Create a short investigation record containing:

• The reported problem.
• The steps that trigger it.
• The affected app version.
• The expected behavior.
• The observed behavior.
• The suspected cause.
• The fix and retest result.

Avoid changing unrelated parts of the application before reproducing the reported problem.

Step 2: Audit AndroidManifest.xml

The Android manifest declares important application components, permissions, intent filters, and other system-facing configuration.

Open AndroidManifest.xml in Android Studio and inspect the activities, services, receivers, permissions, and intent filters associated with the affected feature.

For Android 12 and later, components that declare intent filters generally need an explicit android:exported value.

For example:

<activity
    android:name=".MainActivity"
    android:exported="true">

    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>

</activity>

This example declares a launcher activity. The correct exported value for another component depends on whether it must be accessible to other applications or the Android system.

Check for these common issues:

Incorrect activity declarations: A screen may not be accessible through the intended navigation flow.

Missing permissions: A feature may fail when it attempts to use a protected system resource.

Unnecessary permissions: Remove permissions that the application no longer needs, after checking their actual use.

Incorrect service configuration: Background tasks may fail because a service or its permissions are declared incorrectly.

Conflicting intent filters: Multiple activities may match the same URL or action, producing unexpected navigation.

Incorrect component names: Renamed classes or package changes can leave manifest references pointing to nonexistent components.

Also inspect the merged manifest, because libraries and build variants can contribute configuration that is not obvious from the main manifest file.

Step 3: Audit Deep Links and App Links

Deep links allow users to open a specific screen in an application from a URL, notification, email, advertisement, or another app.

For example, a shopping app might support links to product pages, while a digital marketplace might use links to open a particular product or category.

A deep link can fail if the URL pattern is incorrect, the receiving activity does not process the incoming intent, or the application routes the user to a screen that does not exist.

Check the Intent Filter

An Android App Link can be declared in the manifest using an HTTP or HTTPS URL pattern.

<activity
    android:name=".ProductActivity"
    android:exported="true">

    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />

        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />

        <data
            android:scheme="https"
            android:host="example.com"
            android:pathPrefix="/product/" />
    </intent-filter>

</activity>

Replace example.com and the path with your own website domain and supported route.

This is an illustrative configuration. If your app supports several URL patterns, organize the intent filters carefully and test each supported route. The manifest should not claim to handle URLs that the app cannot process.

Verify the Website Association

Verified Android App Links require a Digital Asset Links file at:

https://example.com/.well-known/assetlinks.json

The file must identify the correct Android application ID and the SHA-256 fingerprint of its signing certificate.

Check that:

• The file is valid JSON.
• It is accessible over HTTPS.
• It does not require authentication.
• It does not redirect to another URL.
• The application ID matches the release package.
• The certificate fingerprint matches the certificate used for the installed release.

If you use Google Play App Signing, verify the app signing certificate fingerprint in Play Console. It may differ from the upload key or the certificate used for a local debug build.

A mismatch can prevent Android from verifying the website association.

Step 4: Test Every Deep Link

Do not assume that a link works because the app opens from the launcher.

Test each URL using a physical device or emulator with the release build installed.

For example, ADB can be used to test a product URL:

adb shell am start \
  -a android.intent.action.VIEW \
  -d "https://example.com/product/123"

Replace the sample URL with a route supported by your app.

Confirm that the application opens the correct screen, displays the expected content, and handles invalid or missing identifiers gracefully.

Also test:

• Links opened from a browser.
• Links opened from email or messaging apps.
• Links opened when the app is already running.
• Links opened when the app is not running.
• Links opened after a fresh installation.
• URLs containing query parameters.
• Unsupported paths and expired content.

If the app opens the wrong screen, inspect the incoming intent and routing logic. A valid manifest filter alone does not guarantee that the application handles the destination correctly.

Step 5: Inspect Crash Logs and Network Failures

A feature may appear broken because its API request fails or its activity crashes while processing a response.

Connect the device to Android Studio and inspect Logcat while reproducing the issue.

Look for:

• FATAL EXCEPTION messages.
• ActivityNotFoundException.
• SecurityException.
• HTTP errors such as 401, 403, 404, and 500.
• JSON parsing errors.
• Null references.
• Network timeouts.
• Missing configuration values.

Verify that the backend is accessible from a clean installation and that the release build uses the correct production API endpoint.

Never include API secrets, passwords, authentication tokens, or sensitive user data in publicly shared logs.

Step 6: Test the App Like a New User

A common mistake is testing only on a developer’s device, where saved sessions, cached content, or local configuration hide defects.

Install the release build on a clean device or emulator and walk through the app from the beginning.

Test account registration, login, logout, password recovery, main navigation, primary actions, content loading, and any purchase or subscription flow that the application supports.

If a feature requires an account, ensure that the required setup is functional and that review instructions accurately explain how to access it.

Test both successful and unsuccessful paths. For example, a failed login should display a useful error rather than leave the interface frozen.

Step 7: Check Permissions and Runtime Behavior

Some features work during development but fail on a clean installation because runtime permissions have not been granted or are handled incorrectly.

For each permission-dependent feature, confirm that:

1. The required permission is declared when appropriate.
2. The permission is requested at the correct point in the user journey.
3. The app handles denial without crashing.
4. The feature explains why access is needed when necessary.
5. The application does not attempt restricted operations without authorization.

Test location, camera, microphone, notifications, and media access only when relevant to your app.

Also review target SDK behavior changes that may affect foreground services, background activity launches, or other platform operations.

Step 8: Retest the Release Build

After applying a fix, generate a new release build and repeat the same reproduction steps.

Do not rely exclusively on a debug build. Release builds may differ because of signing configuration, build variants, minification, network settings, or missing production resources.

A practical regression checklist includes:

• Fresh installation and first launch.
• Login and account creation.
• Every major screen.
• All primary buttons and forms.
• Deep links and App Links.
• API and content loading.
• Permission requests and denial handling.
• Background operations.
• Crash and ANR checks.
• Correct behavior on supported Android versions.

Record the result of each test so that the team can demonstrate which issues were fixed.

Step 9: Submit the Corrected Version

Once the problem has been resolved, update the app version as required by your release process, upload the corrected Android App Bundle, and complete the relevant Play Console submission steps.

Review any additional policy issues before submitting. Fixing a deep link does not automatically resolve unrelated problems involving privacy, permissions, app content, or store listing declarations.

If the rejection remains unclear, use the available Play Console support channels to request clarification. Provide accurate reproduction steps and technical details without making unsupported claims about the cause.

Common Mistakes to Avoid

Changing the manifest without reproducing the problem: Diagnose the failing feature before editing configuration.

Testing only the launcher: Test every entry point, especially links and notifications.

Using the debug signing certificate: Verify website associations against the correct release signing certificate.

Ignoring backend errors: A broken screen may be caused by an API or server issue rather than Android configuration.

Submitting without regression testing: A targeted fix can unintentionally affect another navigation route or feature.

Making unverified fixes: Confirm the corrected behavior on the release build before resubmission.

Conclusion

Resolving a “Broken Functionality” rejection requires a methodical investigation of the behavior reported by Google Play. Start with the review details, audit the manifest, verify deep links, inspect crash and network logs, and test the complete user journey on a clean installation.

A structured release checklist helps developers identify problems before resubmission and maintain a more reliable Android application.

Need help preparing your app for Google Play? Play Console Store offers developer-focused resources for Android publishing, app testing, and release preparation.