It all started when a friend of mine messaged me in a panic.

The Panic Message

“Broooo, Google Play just rejected my app! They’re saying I requested permissions like READ_MEDIA_IMAGES and READ_EXTERNAL_STORAGE... but I never added those! What is going on!?"

I’ve seen a lot of strange Flutter issues before, but this one caught my attention.
He was convinced he didn’t declare those permissions, and honestly, I believed him. So, we decided to investigate it together.

Let the Debugging Begin

We started by checking the obvious:

Step 1: Open AndroidManifest.xml (in android/app/src/main/)

Nothing.
No sign of those permissions.

Step 2: Search the whole project

Maybe they were added somewhere else?
Still nothing.

Then I asked:

“Are you using packages like image_picker, file_picker, or anything related to media?”

He replied:

“Yeah, I’m using file_picker and also a PDF viewer.”

Boom. That was it.
I had a hunch, and it led us straight to the answer.

The Hidden Truth About Flutter Packages

Here’s what many developers don’t realize (including my friend):

Some Flutter plugins include their own AndroidManifest.xml files, which declare permissions.*During the build process, all manifests get merged into one your app’s, plus every package’s.*

So even if you didn’t explicitly write them, they still end up in the final APK/AAB.

How We Confirmed It

We followed these steps to confirm what was going on:

flutter clean
flutter pub get
flutter build apk --release

Then we opened:

build/app/intermediates/merged_manifests/release/AndroidManifest.xml

And there they were:
READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_EXTERNAL_STORAGE injected by plugins.

My friend was stunned.
“I had no idea the final manifest includes stuff from packages too!”

Yup. Welcome to the world of manifest merging in Android.

The Solution: Take Back Control

Luckily, there’s a clean way to stop those unwanted permissions from making it into your final build.

Step 1: Add the tools namespace at the top of your manifest:

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

Step 2: Explicitly remove the unwanted permissions like this:

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" tools:node="remove" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" tools:node="remove" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" tools:node="remove" />

This tells the build system:
“Even if some library tries to add this permission, just skip it.”

What You Can Learn From This

This wasn’t just about fixing a rejection. It was a lesson.
My friend like many of us trusted that only his manifest defined what went into the app.

But here’s the truth:

If you’re using Flutter packages, you need to treat the build output like a black box and always inspect what’s inside.

Pro Tips for All Flutter Devs

• Always inspect your merged manifest before uploading to Play Store.

• Run flutter clean && flutter build apk --release to get a fresh build.

• Open the merged manifest file and search for unintentional permissions.

• Use tools:node="remove" to clean up permissions you don’t want.

• Make sure your declared permissions match your privacy policy.

The Ending

My friend fixed the issue, reuploaded the app, and it got approved a day later.

And me?
Well, I learned that sometimes the best way to understand something… is to help someone else fix their headache.

Final Words

App rejections are frustrating especially when they happen because of things you didn’t even add. But with the right tools and a bit of digging, they’re fixable.

Hope this story helps you or someone in your team avoid the same trap.

Happy building, and may your permissions always be under control.