Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] Inconsistent handling of app identifiers containing hyphens when building for Android #9707

Open
Almost-Senseless-Coder opened this issue May 8, 2024 · 0 comments
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@Almost-Senseless-Coder
Copy link

Describe the bug

Like most app development frameworks, Tauri uses reverse domain notation for the app identifiers.

Tauri only allows letters (a-z, A-Z), digits (0-9) and hyphens (-) in app identifiers. However, Android only allows underscores (_) in app identifiers, not hyphens; iOS, on the other hand, does allow hyphens, but no underscores.

Right now, this means that running cargo tauri android init panics if the app identifier contains hyphens or alternatively only contains of two parts (I think the latter is unintended, anyway).

To illustrate, let's assume I have an app identifier like tech.almost-senseless.jack-point. Trying to build this app for Android fails with a panic due to the hyphen in almost-senseless. Renaming it to tech.almostsenseless.jack-point or tech.almost-senseless works fine, though: In the first case, the generated Android package name and identifier would be tech.almostsenseless.jack_point, and in the latter case it would be tech.jack_point.

Evidently, the last part of the app identifier gets silently dropped and replaced with the product name, and in the product name, hyphens get replaced with underscores.

This has the side effect that running cargo tauri android init when the app identifier is com.tauri.dev works, by the way, because it becomes com.tauri.jack_point - I think that's not intended that way, is it?

So my problem boils down to that

  • Having hyphens in your app identifier shouldn't lead to a panic; rather, the hyphens should get replaced with underscores in the generated Android project.
  • The handling of the identifier should be more consistent, with the last part not getting silently dropped and replaced with the product name.

Reproduction

  • Create a Tauri project from any template, for instance using cargo create-tauri-app --beta. Please make sure mobile support was enabled.
  • Open tauri.conf.json and change the identifier to com.some-domain.some-app.
  • Run cargo tauri android init.

Expected behavior

The command should complete successfully, generating an Android project with the identifier com.some_domain.some_app.

Full tauri info output

WARNING: no lock files found, defaulting to npm

[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 124.0.2478.80
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.80.0-nightly (e82c861d7 2024-05-04)
    ✔ cargo: 1.80.0-nightly (05364cb2f 2024-05-03)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: nightly-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.11.0
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.17
    - tauri-build [RUST]: 2.0.0-beta.13
    - wry [RUST]: 0.39.3
    - tao [RUST]: 0.27.1
    - tauri-cli [RUST]: 2.0.0-beta.16
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.16

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/


### Stack trace

```text
thread 'main' panicked at C:\Users\timjb\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tauri-cli-2.0.0-beta.16\src\mobile\mod.rs:322:6:
called `Result::unwrap()` on an `Err` value: DomainInvalid { domain: "almost-senseless.tech", cause: NotAsciiAlphanumeric { bad_chars: ['-'] } }

Additional context

No response

@Almost-Senseless-Coder Almost-Senseless-Coder added status: needs triage This issue needs to triage, applied to new issues type: bug labels May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
None yet
Development

No branches or pull requests

1 participant