fix(cli, breaking): Align Android applicationId with user's `bundle.identifier`

[fontlos]

This PR stems from my questions regarding issue #4098. In my opinion, if a user explicitly specifies an identifier, modifying it during APK build would be unreasonable.

If there is indeed a valid reason for altering the Android applicationId, I’ll close this PR—apologies for any inconvenience caused to the Dioxus team.

This commit fixes the Android applicationId generation to accurately reflect the user-configured bundle.identifier when provided. It also refactors the logic by removing the full_mobile_app_name function, with bundle_identifier now being the direct source for the Android applicationId.

The bundle_identifier function now operates as follows:

1. If bundle.identifier is explicitly set by the user:
   • It validates that the identifier has at least three segments (e.g., com.example.app).
   • The user's identifier is then returned and used directly as the Android applicationId.
2. If config.bundle.identifier is not set by the user:
   • It defaults to com.example.{PascalCaseExecutableName}. The executable_name (e.g., "my-app" derived from a project name like "MyApp") is converted to PascalCase (e.g., "MyApp") for this default.

BREAKING CHANGE:

This change primarily affects Android builds and may alter the final applicationId for users who had a custom bundle.identifier set, particularly if its casing or final segment differed from the PascalCased executable_name.

• Previous Behavior:

  The Android applicationId was derived from full_mobile_app_name. This function effectively used the first two segments of the bundle_identifier (user-configured or default) but then always appended a PascalCased version of the executable_name as the final segment.

  Example Scenario:

  • User project name: "MyApp" (CLI set executable_name to "my-app")
  • User configured bundle.identifier in Dioxus config: "com.custom.myapp"
  • bundled_app_name() (from "my-app"): "MyApp"
  • Old applicationId (via full_mobile_app_name): "com.custom.MyApp"

• New Behavior:

  With the same user configuration ("com.custom.myapp"), the applicationId will now be: "com.custom.myapp"

This change ensures the applicationId respects the user's explicit bundle.identifier string. However, if users were unknowingly relying on the previous behavior where the last segment was always a PascalCased version of the executable_name (potentially mismatching their intended lowercase final segment in bundle.identifier), their applicationId will change upon updating the CLI.

According to Google's Android documentation, the applicationId must not be changed after an app is published, as this causes Google Play to treat it as a new application. Users who have published Android apps and utilized custom bundle.identifier configurations should meticulously verify their applicationId after this update to ensure it remains consistent with their published versions or to take appropriate action if a change is detected.

Closes #4098

[omar-mohamed-khallaf]

Android package IDs are required to be at least 2 segments, why enforcing a minimum of 3? Pascal case is a little odd, a lower case with no underscores following kotlin naming rules is better.

[fontlos]

@omar-mohamed-khallaf Hi, thank you for your review and valuable feedback!

Regarding the 3-segment enforcement (i.e., dot_count >= 2):

My initial check was based on the original mobile_org function's expect message, which referenced 3 segments (e.g., com.example.app). This led me to believe it was a project convention or implicit Android requirement.

After verifying official Android developer documentation, I confirm you're right: only 2 segments are required.

Maybe I should relax the check to dot_count >= 1?

About PascalCase:

This PR ensures custom bundle.identifier fully respects user-provided naming (including lowercase).

The default identifier still uses PascalCase for the last segment (e.g., com.example.MyApp) to minimize scope impact, because bundle_identifier function is referenced in multiple places. We can revisit this in a future PR if needed :)

Thank you again for your guidance!

[omar-mohamed-khallaf]

Yes, dot_count >= 1 seems the way to go.

You are right about reducing the scope impact, but I was thinking 0.7 will be released soon, and it will be breaking anyway, so I thought might fix the naming convention as well. Anyway, it's really not that important, after thinking about it. No one really wants .example. in the application ID, so it must be user provided.

Much appreciated.

[jkelleyrtp]

Thanks for the PR!

If there is indeed a valid reason for altering the Android applicationId, I’ll close this PR—apologies for any inconvenience caused to the Dioxus team.

I think this was just an oversight. We assumed both iOS and Android had similar bundle identifier conventions.

Should we have multiple bundle identifier options - different for each platform? Currently, we get bundle_identifier from the top-level bundle config, but it sounds like we might want a different identifier for each platform?

[nicoburns]

@jkelleyrtp We almost certainly want at least an option for separate bundle identifier's per platform