🚫 Don’t Panic Over Lint Errors in Flutter Plugins: A Scalable Solution Explained

If you’ve recently upgraded some of your Flutter plugins and run into Android Lint warnings or build failures like this:

Missing permissions required by NotificationManagerCompat.notify

Many developers hit the panic button here, but take a deep breath. This isn’t always a problem with your code.

🔍 Why This Happens

Let’s look at a real-world example with the Geolocator plugin. You see the warning:

⁣Missing permissions required by NotificationManagerCompat.notify

But here’s the kicker: the plugin intentionally doesn’t include this permission in its AndroidManifest.xml. Why? Because Android cleverly merges plugin-level manifests into your final app manifest. If a plugin like geolocator_android added POST_NOTIFICATIONS, every app using it would end up with that permission—even if they never touch notifications!

Plugin maintainers often say, “This should be an explicit choice of the app developer, and therefore the developer should manually add the permission.” This is totally valid and aligns with best practices. However, for app developers who aren’t using that specific feature, it just creates unwanted Lint noise.

✅ Your Options

So, what can you do?

Option 1: Explicit Permission (when you actually use the feature)

If your app genuinely uses the feature that requires the missing permission (like notifications in this example), the solution is straightforward: Add the permission directly to your app level:AndroidManifest.xml

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>

✅ Best Approach: Scalable Lint Handling via Gradle

What if you don’t use the feature, and adding a permission just to silence a Lint error feels wrong? This is where a scalable Gradle-based solution comes in, helping you avoid that panic.

This snippet goes into your project-level android/build.gradlefile:

subprojects {
    afterEvaluate { project ->
        if (project.hasProperty("android")) {
            project.android {
                lintOptions {
                    checkReleaseBuilds false
                    abortOnError false
                }
            }
        }
    }
    project.buildDir = "${rootProject.buildDir}/${project.name}"
}

But be careful, disabling lint globally is not a good practice

Turning off lint checks for all Android projects might seem like a quick fix, but it hides potential issues in your app or libraries.

A better way is to target lint disabling selectively, for example:

Disable lint only for a specific plugin or module

If you want to silence lint errors for just one plugin (say flutter_downloader), you can do:

subprojects {
    afterEvaluate { project ->
        if (project.name.contains("flutter_downloader") && project.hasProperty("android")) {
            project.android {
                lintOptions {
                    checkReleaseBuilds false
                    abortOnError false
                }
            }
        }
    }
}

This way, only the flutter_downloader module has relaxed lint rules, while other modules remain strict.

Disable lint or specific lint tasks by language (e.g., Kotlin)

Sometimes you want to disable Kotlin linting tasks (ktlint) for certain modules without affecting Java or other languages:

subprojects {
    afterEvaluate { project ->
        if (project.name.contains("flutter_downloader")) {
            project.tasks.matching { it.name.contains("ktlint") }.all {
                it.enabled = false
            }
        }
    }
}

This disables only the Kotlin lint tasks for flutter_downloader, keeping lint intact elsewhere.

Why This Is Better Than Traditional Lint Bypass

Compare that with the more common snippet:

✅ Scalability: My version not only disables error abortion but also organizes the build folders. This avoids clutter and centralizes your build artifacts.

✅ Better Debugging: By setting checkReleaseBuilds to false, we avoid surprises during production builds while still being able to lint during development.

✅ Customizability: You can fine-tune this per project if needed by modifying project.name.

🔚 Final Thoughts

Not every warning is a deal-breaker, especially in a fast-evolving ecosystem like Flutter. Sometimes, packages trigger errors that simply aren’t relevant to your current use case. When you encounter these:

1. Understand why the error is appearing.
2. Decide if you truly need the permission or feature it’s complaining about.
3. Choose a scalable way to suppress or resolve the error.

So, next time a Lint warning pops up, breathe. Think. And perhaps, instead of panicking, just drop in that handy Gradle snippet.