You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 inalmost-senseless
. Renaming it totech.almostsenseless.jack-point
ortech.almost-senseless
works fine, though: In the first case, the generated Android package name and identifier would betech.almostsenseless.jack_point
, and in the latter case it would betech.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 iscom.tauri.dev
works, by the way, because it becomescom.tauri.jack_point
- I think that's not intended that way, is it?So my problem boils down to that
Reproduction
cargo create-tauri-app --beta
. Please make sure mobile support was enabled.tauri.conf.json
and change the identifier tocom.some-domain.some-app
.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
outputAdditional context
No response
The text was updated successfully, but these errors were encountered: