# App Bundle Debug Symbols Warning: Safe to Ignore

You uploaded your build to Play Console and got a yellow warning about native code and missing debug symbols. It reads like something you have to fix before you can release. You do not. Here is what the warning means, why most apps can leave it exactly as it is, and the narrow case where uploading symbols is actually worth doing.

## What the warning actually says

This is the message on the bundle:

> This App Bundle contains native code, and you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug.

Read the verb: recommend. This is advisory, not a rejection. Native debug symbols are a file that lets Play Console translate native crash stack traces, the ones from compiled C and C++ libraries, into readable function names and line numbers in Android vitals. Without them, a native crash shows up as raw memory addresses instead of names. That is the entire scope of what the file changes. It does not affect how the app runs, installs, or passes review.

## It is a warning, not an error

The clearest tell is that your bundle already went through. In the screenshot both version codes uploaded and both carry the same warning, and neither is blocked. The yellow triangle sits next to a bundle Play has accepted. It gates nothing. You can publish today and the warning stays a warning.

## Why most apps do not need it

Debug symbols only help you read one thing: crashes that happen inside native code. That matters when the native code is yours and a symbolicated trace tells you which of your functions failed.

In a Despia app the native layer is the runtime and the WebView, not code you wrote. Your app's logic lives in JavaScript, and a JS error surfaces in your own error tooling and the browser console, never in Play's native crash reports. So symbolicating the native layer would hand you readable traces for code you do not own and cannot change. You would be paying to make framework crashes legible, and framework crashes are our problem to fix, not yours. That is why skipping the file costs the typical app nothing.

The native code in the bundle is expected. Any app with a WebView, a payments SDK, a push SDK, or an ad SDK ships native libraries. The warning fires on the presence of native code, not on anything wrong with your build.

## When uploading symbols is worth it

There is one real case. If you exported the Android Studio project and added your own native modules, NDK code you wrote and want to debug, then symbolicated native traces in Android vitals become actionable, and you should include the symbols. In the exported Gradle project that is one line in the release build:

```gradle
android {
    buildTypes {
        release {
            // bundle native debug symbols so Play can symbolicate crashes
            ndk { debugSymbolLevel 'SYMBOL_TABLE' }
        }
    }
}
```

`SYMBOL_TABLE` gives you function names, which is enough for most debugging. `FULL` adds line numbers and a larger file. If you did not add native code of your own, neither is worth the build weight.

## Best practice: ship and watch the crash rate

Leave the warning and publish. Then watch your crash rate in Android vitals like you would anyway. If native crashes you cannot explain never show up, you never needed the symbols, which is the outcome for nearly every web-based app. Only revisit this if you add native code you own and want to trace. Chasing a non-blocking recommendation before launch is time spent on a number that was never going to stop you.

## Ship it and move on

The warning does not gate your release. Publish the bundle, keep an eye on Android vitals, and only touch debug symbols if you add native code of your own. Everything up to the store runs from the browser, no Android Studio required.

[See the setup docs at setup.despia.com](https://setup.despia.com)