Table of Contents
Introduction
Maintaining dependencies in modern mobile applications can be challenging, especially when key packages become outdated and incompatible with the latest framework updates. We encountered this problem while working on a client project that relied on an essential location-tracking package, background_locator_2, which hadn’t been updated in nearly two years.
When compatibility issues with the latest Android Gradle Plugin (AGP) caused build failures, we had two options: replace the package entirely or modify it ourselves. To avoid costly delays, we chose to fork and update the existing code to restore compatibility. In this blog, we’ll walk through how we revived an abandoned Flutter package and kept the app running smoothly.
The Challenge of Abandoned Flutter Packages in Production Apps
Keeping dependencies updated is a constant challenge in today’s mobile development cycle. While updating a client’s application, our team encountered a critical issue with a location-tracking package that hadn’t been maintained in over two years. The app relied heavily on background_locator_2, which meant removing it would have significantly disrupted core functionality.
Like many abandoned Flutter packages, this one was no longer compatible with newer Android Gradle Plugin (AGP) versions. When building with AGP 8.0+, we ran into this error:
Namespace not specified…
We also faced JVM compatibility conflicts between Java and Kotlin code:
Inconsistent JVM-target compatibility…
These issues blocked our update path and risked delaying delivery. We had to decide between replacing the package entirely or finding a way to revive it—something many developers in the ecosystem have likely faced.
Reviving Outdated Flutter Packages with Strategic Forking
After evaluating the options, we determined that a complete replacement would require:
- Researching alternative packages
- Implementing and testing a new solution
- Refactoring existing code that interacted with the original package
- Additional regression testing across the entire application
This approach would have delayed our delivery by weeks and increased costs for our client. Instead, we chose a more efficient path: forking the package and implementing the necessary fixes ourselves.
Optimize Your Flutter Development Process
AlphaBOLD helps you implement smarter, long-term solutions to optimize your flutter packages.
Request a ConsultationThe Implementation Process
Step 1: Fork and Branch
First, we created a fork of the background_locator_2 repository on GitHub and established a dedicated branch for our changes:
git clone https://github.com/our-account/background_locator_2_fork.git
cd background_locator_2_fork
git checkout -b fix/gradle-compatibility
Step 2: Fixing the Namespace Issue
The primary issue was the missing namespace in the Android build configuration. Starting with AGP 8.0, all Android modules must explicitly declare a namespace.
Here’s what we changed in the android/build.gradle file:
android {
+ namespace ‘yukams.app.background_locator_2’
compileSdkVersion 29
sourceSets {
main.java.srcDirs += ‘src/main/kotlin’
}
// …
}
This seemingly simple addition was critical—the namespace had previously been defined only in the AndroidManifest.xml, which is no longer sufficient for newer AGP versions.
Step 3: Resolving JVM Target Compatibility
Next, we must ensure consistent JVM targets between Java and Kotlin code. We added explicit kotlinOptions to match the Java compatibility level:
android {
// …
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
+ kotlinOptions {
+ jvmTarget = ‘1.8’
+ }
}
This ensures that both Java and Kotlin code target the same JVM version, resolving the inconsistency error.
Step 4: Updating Dependencies and Gradle Configurations
We also updated several dependencies to ensure broader compatibility with Flutter packages:
buildscript {
– ext.kotlin_version = ‘1.6.10’
+ ext.kotlin_version = ‘1.7.20’
repositories {
google()
– jcenter()
+ mavenCentral() // jcenter is deprecated
}
dependencies {
– classpath ‘com.android.tools.build:gradle:4.1.0’
+ classpath ‘com.android.tools.build:gradle:7.3.0’
classpath “org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version”
}
}
rootProject.allprojects {
repositories {
google()
– jcenter()
+ mavenCentral()
} }
Step 5: Cleaning Up the AndroidManifest.xml
In the original package, the AndroidManifest.xml contained a package attribute, which is now deprecated in favor of the namespace in build.gradle. We simplified the manifest to avoid conflicts:
<!– Before –>
<manifest package=”yukams.app.background_locator_2″>
<!– contents –>
</manifest>
<!– After –>
<manifest>
<!– contents –>
</manifest>
Step 6: Testing and Creating a Pull Request
After implementing these changes, we thoroughly tested the forked package in our client’s application to ensure all location-tracking functionality worked correctly. Once validated, we:
- Created a new version tag
- Updated the plugin’s documentation
- Submitted a pull request to the original repository
Implementing the Forked Package
To use our fixed version in the client’s app, we updated the pubspec.yaml:
dependencies:
background_locator_2:
git:
url: https://github.com/sultan18kh/background_locator_2_fork.git
ref: fix/gradle-compatibility
Planning for the Future
While our fork successfully solved the immediate problem, we’ve recommended a more sustainable approach to our client for the future:
- Transition to an actively maintained package: Libraries like flutter_background_geolocation or background_location_tracker offer similar functionality with regular updates.
- Implement a custom solution: Creating a dedicated implementation using Method Channels would give the client full control over this critical functionality.
We proposed implementing this transition during a future optimization phase, which would allow us to meet current deadlines while planning for long-term maintainability.
Lessons Learned
This experience reinforced several key principles for handling dependency challenges:
- Evaluate the scope of changes before deciding on an approach. Sometimes, a targeted fix is more efficient than a complete replacement.
- Document technical debt created by temporary solutions. While our fork fixed the immediate issue, we ensured the client understood the long-term implications.
- Contribute back to the community. By addressing issues in Flutter packages, we potentially helped other developers facing the same challenge.
- Balance immediate needs with long-term sustainability. Our solution met the urgent deadline while providing a roadmap for a more robust approach in the future.
By taking a strategic approach to this dependency challenge, we maintained our delivery timeline, preserved the client’s budget, and ensured their application could continue to leverage modern development tools and practices.
You may also like: Flutter vs React Native | Choose the Best Mobile Framework
Experiencing Build Failures? We've Got You Covered!
Struggling with dependency issues in your project? Let AlphaBOLD assist you in fixing and modernizing outdated Flutter packages.
Request a ConsultationConclusion
Reviving abandoned Flutter packages is not just about applying quick fixes—it requires a strategic approach that balances immediate needs with long-term sustainability. By forking and updating background_locator_2, we maintained project timelines while minimizing costs.
However, this experience highlighted the importance of choosing actively maintained dependencies and planning for future transitions. Whether dealing with outdated libraries or considering a custom-built solution, understanding your options can help you make informed, cost-effective decisions. If you’re struggling with abandoned Flutter packages, our experts can assist in forking, updating, or finding the best alternative.
Explore Recent Blog Posts
