* feat(cli): detect Android env and install SDK and NDK if needed
changes the Android setup to be a bit more automated - looking up ANDROID_HOME and NDK_HOME from common system paths and installing the Android SDK and NDK if needed using the command line tools
* fix windows
* clippy
* lint
* add prmopts and ci check
* also check ANDROID_SDK_ROOT
currently we only install Rust targets for mobile when initializing the projects.
Users can commit the Android/iOS projects, so running the init command is not a requirement to develop mobile apps. This change ensures the Rust targets are installed before trying to compile them.
* fix(cli): read original identifier to fix mobile options reading
the iOS and Android CLI commands leverage an android_studio_script/xcode_script that is executed by the native IDE or build tool. This script reads the Tauri configuration to find the app identifier used to communicate with the parent Tauri CLI process to read CLI options.
The communication is broken when the `--config` arg is used, since the IDE script does not have access to that value before reaching the parent process, which is impossible without knowing the actual identifier used.
To bypass this we'll agree on using the original identifier. This obviously won't work if the original tauri.conf.json do not have an identifier, so we error out in this case
* fix build, lint
* feat(cli): allow merging multiple configuration values
Currently the dev/build/bundle commands can only merge a single Tauri configuration value (file or raw JSON string), which imposes a limitation in scenarios where you need more flexibility (like multiple app flavors and environments). This changes the config CLI option to allow multiple values, letting you merge multiple Tauri config files with the main one.
* fix ios build
* feat(cli): enhance Android dev port forwarding, closes#11137
this changes the `android dev` port forwarding (that is actually handled by the `android-studio-script` command - triggered by our Gradle plugin) with some enhancements:
- make the whole process more resilient by checking if the port was actually forwarded and rerunning the `adb reverse` command until it tells us the forward is ready
- if the `adb devices` list is empty, retry a few times (waiting a few seconds) to tolerate devices being booted - slows down "raw builds" (Build Project Android Studio menu for instance) that shouldn't happen often anyway - if you're running `android dev` you're usually running the app on a device instead of simply testing builds
* use host IP to run on android physical device
