Package name change not reflected in downloaded Android code

[morslinu-spec]

Can we access your project?

• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

My FlutterFlow project package name is set to:

app.veil.match

in App Settings > App Details.

I regenerated the Firebase config files, and Firebase now contains the Android app:

app.veil.match

However, every newly downloaded source code still contains:

namespace "com.veil.app"
applicationId "com.veil.app"

The generated Android release configuration also contains:

signingConfig signingConfigs.debug

Because of this, Google Play rejects the generated AAB because it is signed in debug mode.

I have regenerated the Firebase config files and downloaded the source code again, but the generated Android code still uses the old package name and debug signing configuration.

This appears related to #7154, but that issue was closed as "can't reproduce". The issue is still reproducible in my current project, and I have provided project access and screenshots showing the generated code and Google Play rejection.

Expected Behavior

Downloaded/generated Android source code should use:

namespace "app.veil.match"
applicationId "app.veil.match"

Release builds intended for Google Play should also use the configured release signing key instead of signingConfigs.debug.

Steps to Reproduce

1. Set the Package Name in App Settings > App Details to app.veil.match.
2. Regenerate Firebase Config Files.
3. Confirm that Firebase contains an Android app with package name app.veil.match.
4. Download the project source code using Developer Menu > Download Code.
5. Open android/app/build.gradle.
6. Observe that namespace and applicationId are still com.veil.app.
7. Observe that the release buildType uses signingConfig signingConfigs.debug.

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

ITESzfHl5YxgodtC+c/pKvpQhQMkQzM6bZI7ku1EdwEhNZT1Pe0iYffsUBdLYteUews+MU20rEcD0vCPhvHtEvoEKSmVbIBY+IRXQRWUZEGuR8jQBbWBPHN7GeNTG2qz0aSv3whBOfhtcmAe3WGmHPCdG3qCf9qOYwx5e6fDbOY=

Visual documentation

Attached screenshots show:

1. FlutterFlow App Details with package name app.veil.match.
2. Firebase Android app registered as app.veil.match.
3. Downloaded Android source still using com.veil.app and signingConfigs.debug.
4. Google Play rejecting the generated AAB because it is debug-signed.

Environment

- FlutterFlow version: Latest Version (Unpinned)
- Platform: Web
- Browser name and version: Google Chrome 142
- Operating system and version affected: Windows 11 25H2

Additional Information

This issue is currently blocking the Google Play release of my app.

I changed the Android package name from com.veil.app to app.veil.match because the previous package name could not be used on Google Play.

FlutterFlow correctly shows app.veil.match in App Settings, and Firebase has also been regenerated with app.veil.match.

However, downloaded Android source code still uses the old package name com.veil.app and release builds are configured with signingConfigs.debug.

As a result, Google Play rejects the generated AAB as debug-signed, and I cannot proceed with the initial internal testing release.

I would appreciate help resolving this as soon as possible because the app is ready for release and this issue is currently blocking deployment.

[Juansarmi]

Hi! Sorry to hear you’re experiencing this issue.

Unfortunately, I’m not able to reproduce the error on my end. However, I can confirm that the issue is present in your project, so I’d recommend reaching out to our support team via the in-app chat or by email at support@flutterflow.io . They have the tools and access needed to investigate your specific case in more detail and help identify the cause of the issue.

Best regards

[mathewmljourney93]

There may be a practical route around this in the exported Android project. I’d compare FlutterFlow’s stored package setting with the Gradle configuration, Firebase files and release signing setup in one clean export.

If you want hands-on help, I can inspect the export and tell you whether this can become a repeatable release process without changing the app itself.