A Flutter Plugin Secretly Injected Permissions Into My App — Google Rejected It 4 Times Before I Found It

Davis | UNTRAPD — Thu, 09 Apr 2026 22:03:27 +0000

Google Play rejected my Flutter app 4 times. Same reason each time: sensitive permissions I never asked for.

I grepped every file. READ_SMS, SEND_SMS, READ_CALL_LOG — none of them in my AndroidManifest.xml.

Because they weren't in my manifest. They were in my compiled bytecode.

The culprit

permission_handler. One of the most popular Flutter plugins. 8,000+ likes on pub.dev.

Here's what nobody tells you: it compiles string constants for every Android permission it supports into your DEX bytecode. Not because you request them. Not because you use them. Because the plugin's internal mapping references them all.

Google's automated review doesn't just read your manifest. It scans compiled bytecode for permission-related strings. permission_handler puts them there. Every single one.

You didn't request them. You don't use them. Google still flags them.

The trap nobody warns you about

Here's what made this worse: Google Play testing tracks don't enforce the same permission policies as Production.

I uploaded builds with SMS permissions to Internal Testing. Approved. Closed Testing. Approved. Pre-registration. Approved. 172 countries. Everything green.

Then I submitted to Production. Rejected.

The testing tracks let everything through. You build confidence. You think your permissions are fine. Then Production applies a completely different set of rules — and you're back to zero with no warning.

If you're testing sensitive permissions on Internal or Closed Testing and it "works" — that tells you nothing about Production approval.

What didn't work

Removing permissions from AndroidManifest.xml — scanner reads DEX, not just manifest
tools:node="remove" — removes from merged manifest, strings survive in bytecode
ProGuard/R8 rules — some references survive optimization
Permission declaration form — Google rejected it because I wasn't using those permissions

What worked

Removed permission_handler entirely. Replaced with a native Kotlin method channel — one file, exactly the permissions I need, zero baggage.

Next submission: zero phantom permissions. Approved.

The lesson

Two things bit me at once:

Flutter plugins have compiled consequences. permission_handler ships references to every Android permission into your binary. Google can't tell the difference between "string exists in code" and "app uses this permission."
Testing tracks are not Production. Don't assume approval on Internal/Closed Testing means anything for Production. The policy enforcement is different.

Two commands that would have saved me two weeks:

# What you installed
flutter pub deps

# What actually shipped
apkanalyzer dex packages your-app.apk | grep permission

They don't show the same thing.

The timeline

4 rejections over 5 days. 1 plugin. Now live on Google Play in 172 countries.

Has anyone else been bitten by this? I'm curious — does Google intentionally skip permission checks on testing tracks, or is it a gap in their review system? And is permission_handler the only Flutter plugin that does this?

I built an AI marketing army. It delivered content to nobody.

Davis | UNTRAPD — Mon, 30 Mar 2026 10:57:38 +0000

I'm a solo Android developer. I built a phone recovery app with Claude as my only teammate. 14 versions shipped in 110 days. Live on Google Play in 172 countries.

Building was the fun part. Marketing was where I learned the most painful lesson of my career.

The setup

I solved my marketing problem the way any developer would: by building more software.

Custom automation system from scratch:

Native Twitter API (OAuth 1.0a, no third-party tools)
Native Meta API (Facebook + Instagram, OAuth 2.0)
Cron-based scheduling with rate limiting
Token refresh pipeline
Content generation via Claude
A/B tested formats and timing

40 hours of infrastructure. Genuinely impressive engineering. I was proud of it.

The 81-post experiment

15-day holiday campaign. 81 posts scheduled across Twitter, Instagram, and Facebook.

Results:

31 posts actually went through (rest got blocked — platforms fighting back)
361 total impressions
0 beta signups
Followers: 26 → 21 (lost five)

Best performing tweet: "The 9-to-5 was designed in 1926" — 87 impressions, 24% of the entire campaign's reach. Had nothing to do with my app.

What went wrong

Posting to 26 followers = 0-5 views per post. The algorithms have nobody to show your content to. Then the high volume + zero engagement trains the algorithm you're spam. Each post gets suppressed harder than the last.

I was actively teaching Twitter to hide me. 81 posts out, zero comments on anyone else's stuff. Broadcasting to empty rooms on a schedule.

AI didn't solve the distribution problem. It just made it faster to confirm I had one.

The lesson

Content without distribution is invisible. Every marketing guide assumes you have a baseline audience. At zero, the rules are different and nobody tells you that.

The failure story turned out to be more interesting than anything I posted in those 81 scheduled posts. I'm documenting the full journey with raw data — every campaign, every pivot, every failure with actual numbers.

If you're at zero right now — what actually worked for getting your first handful of users?

Forem: Davis | UNTRAPD

A Flutter Plugin Secretly Injected Permissions Into My App — Google Rejected It 4 Times Before I Found It

The culprit

The trap nobody warns you about

What didn't work

What worked

The lesson

The timeline

I built an AI marketing army. It delivered content to nobody.

The setup

The 81-post experiment

What went wrong

The lesson