Repository navigation
Conversation
* Android: Gradle upgrades
* typos
* bump agp to latest
* Remove all jvmTarget
* clean up unused
* migrate to getByName
* remove `id("org.jetbrains.kotlin.android")` from plugin template
* Try disable `builtInKotlin`
* revert all gradle 9 migrations
* back to JVM_1_8
* remove `org.gradle.toolchains.foojay-resolver-convention` as I still don't understand what it does
* `android.useAndroidx` is true by default
* fix white spaces before first packaging
* Only `consumerProguardFiles` is used for Android libaries
* pickup the right proguard rules
* install cli instead of moving the built one
* bump spin and install locked
* try latest java and ndk
* try to work around missing `consumer-rules.pro`
* Add change files
* more specific about both gradle and plugin versions
* remove unused linux deps installation step
* Revert "try to work around missing `consumer-rules.pro`"
This reverts commit f1afdd9.
* Disable `android.proguard.failOnMissingFiles` instead
* update change file that we don't do the work around in tauri-build anymore
* update gradle wrapper and scripts
* use file helper
reference: https://issuetracker.google.com/issues/463283604#comment10
---------
Co-authored-by: Megh Parikh <meghprkh@gmail.com>
* fix: menu related commands can panic * update change file
…15630) * fix(runtime-wry): query monitors on main thread from runtime handle WryHandle::primary_monitor, monitor_from_point and available_monitors read the event loop's window target directly on the calling thread. That window target is not thread safe, so calling these functions from a background thread races with the UI thread and can segfault or corrupt the heap. Route the three queries through the event loop like cursor_position already does, so the window target is only accessed on the main thread. Closes #15170 * refactor(runtime-wry): use event_loop_window_getter! for monitor queries Reuse the existing event_loop_window_getter! macro (as cursor_position does) instead of hand-rolling the channel + send_user_message boilerplate in primary_monitor, monitor_from_point and available_monitors. These methods return bare Option/Vec, so a small closure absorbs the macro's internal `?`. * Revert "refactor(runtime-wry): use event_loop_window_getter! for monitor queries" This reverts commit fc2078b. * fix(runtime-wry): return no monitors when event loop send fails If send_user_message errors the event loop will never reply, so recv() would block the calling thread forever. Return None / an empty Vec on a send error instead of waiting. * return results * fix mock --------- Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
* feat(cli): warn when Java is too new for the bundled Gradle Installing a very recent JDK (e.g. Java 25/26) while Tauri ships Gradle 8.14 makes Android builds fail with a cryptic 'Failed to assemble APK' error. Detect the active Java feature version during the Android env setup and warn upfront when it exceeds what the bundled Gradle can run, pointing at the Gradle/Java compatibility matrix. Closes #15385 * refactor(cli): detect Java version without spawning a subprocess Read the major version from the JDK's `release` metadata file instead of running `java -version` on every Android command, so the compatibility warning no longer adds process-spawn overhead to init/dev/build. * feat(cli): derive Java/Gradle compat from the project's Gradle version Read the Gradle version from the project's gradle-wrapper.properties instead of a hardcoded template constant, so the warning stays correct when users upgrade Gradle. Skip the warning when the project or Gradle version can't be determined (and for Gradle 9+, which tracks new Java quickly). * refactor(cli): move Android Java/Gradle checks to a dedicated module Extract the Java detection and Java/Gradle compatibility checks out of android/mod.rs into android/java.rs, and recommend the exact supported Java ceiling in the warning instead of a stale LTS list. Addresses @Legend-Master's feedback. * revert ensure java * move the check to get_config the project path is only available after it * check 9.1 and 9.4 --------- Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
* chore: make tauri deps into workspace deps * add change file * fmt * enable default features for example and bench * enable default features for example and bench for tauri-build * Revert "enable default features for example and bench for tauri-build" This reverts commit 5c15412. * re-order deps * use workspace dependencies everywhere * set `default-features` to false for `tauri-build` * fix api example * use exact versions like before * tauri doesn't need to depend on itself * use path `.` for tauri * fix change files * no need to tell the users for the workspace change * bring back default features false to tauri dev dep * fix missing features for sample plugin --------- Co-authored-by: Tony <legendmastertony@gmail.com>
* chore(deps): update rust crate png to 0.18 * fix compile * Add change file --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* fix: add ECMAScript Explicit Resource Management to Resource * Update change file * Regenerate bundle.global.js * `await this.close()` instead of return * Add required libs --------- Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
* docs(api): Explicit Resource Management for `Resource` * Apply suggestions from code review Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com> * separate examples --------- Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* refactor: lock minor versions * pin bundler and macos-sign
* feat(cli): warn when productName is left as the default (fix #14968) The default productName tauri-app is used to derive the default WiX installer upgrade code, so every app published without changing it gets the same upgrade code and collides with unrelated apps in winget. tauri build now warns when productName is still tauri-app, and the config docs for productName and identifier explain what must be changed before publishing. The upgrade code derivation itself is unchanged. * docs(config): document the full surface of productName The productName doc now lists everything the field controls on each platform instead of focusing on the WiX upgrade code. Requested in review of #15895. * fix(cli): broaden the default productName warning The warning and the change file described only the WiX upgrade code, which is one of several things productName controls. Also bump @tauri-apps/cli alongside tauri-cli, matching the other change files. * Update crates/tauri-cli/src/build.rs --------- Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com>
* chore(deps): update rust crate jsonschema to v0.49.9 * bump h2 * bump openssl --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
…15918) * fix(tauri-build): emit absolute capabilities rerun-if-changed path The relative `cargo:rerun-if-changed=capabilities` is resolved by cargo against the package that owns the build script, while the glob in the same branch is resolved against the process working directory. A caller that `set_current_dir`s before `try_build[_context]` — e.g. a crate generating a context byte-identical to the app's — ends up watching `<caller-manifest-dir>/capabilities`, which usually does not exist. A missing watched path is dirty on every fingerprint check, so the build script re-runs on every build and recompiles the whole downstream chain (measured: a zero-change build of a 1.9k-unit workspace app went from ~140s to ~1s after making the watched dir exist). Emit the watch path anchored to the current dir the glob already uses. * chore: add change file for capabilities rerun-if-changed fix
* fix(path): return "." from normalize("")
Match Node.js and the existing join("") contract already documented
in the normalize comment.
* test(path): simplify normalize empty-string assertions
---------
Co-authored-by: Xia Chao <236466140+bun-unsafe@users.noreply.github.com>
* fix(windows): use cached focus states for `is_focused` * fmt * Add change file
Destroying an activity while another one was alive crashed the app:
java.lang.RuntimeException: Unable to destroy activity {MainActivity}
Caused by: java.lang.IllegalStateException: LifecycleOwner MainActivity is
attempting to register while current state is RESUMED. LifecycleOwners must
call register before they are STARTED.
at app.tauri.plugin.PluginManager.onDestroy
`onDestroy` handed the manager's launchers to whichever activity was left
by calling `registerResultLaunchers` on it, but that activity was already
running, and `registerForActivityResult` may only be called before its
owner reaches STARTED. There is no moment during another activity's
teardown at which the call is legal.
So the launchers are no longer a property of the manager that migrates.
Each activity registers its own set while it is being created, which is
the one point where registering is allowed, and `onDestroy` only has to
drop the entry and point at whatever remains — which already has
launchers of its own. `LinkedHashMap` rather than a set, so the activity
taken over is the oldest survivor and not an arbitrary one.
Reproduced on Android 15 by reinstalling an APK over the running app,
which momentarily leaves the new activity resumed while the old one is
being destroyed; fixed with this change.
* fix: support iOS 27 development using Xcode 27 * pin swift-rs to 1.0.8 * fix doc * fix doc * do not UIApplicationSupportsMultipleScenes by default * update tao * update example * update schemas * fix windows build
Bumps [rpassword](https://github.com/conradkleinespel/rpassword) from 7.4.0 to 7.5.4. - [Release notes](https://github.com/conradkleinespel/rpassword/releases) - [Commits](conradkleinespel/rpassword@v7.4.0...v7.5.4) --- updated-dependencies: - dependency-name: rpassword dependency-version: 7.5.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…when the webview is reparented (#15513) The Linux button-press and touch handlers assumed the widget hierarchy webview -> GtkBox -> GtkWindow and unwrapped a downcast of the webview's second ancestor. Embedding applications that reparent the webview into another container (e.g. a GtkPaned) panic the main thread on the first click. Resolve the webview's toplevel window instead - identical behavior for the stock hierarchy, correct at any nesting depth. Co-authored-by: Avi <aviynw6@gmail.com> Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* chore(deps): update rust crate ico to 0.6 * Add change file * fix js audit * fix rust audit * update lock * bump webpki-root-certs --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
* fix(api): type check dev tooling configs * `@rollup/plugin-typescript` doesn't support this of course something breaks... rollup/plugins#1755 * clean up pnpm workspace config * add notes on the node types * prettier
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…) (#14712) * fix: retain merged ExportOptions.plist beyond build command (#14593) * Apply suggestion from @lucasfernog --------- Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
…EM (#16060) * fix(bundler): keep NSIS and WiX out of System32 when bundling as SYSTEM When the cache dir is inside the Windows system directory, as it is for the SYSTEM account, WOW64 redirects the 32-bit NSIS and WiX executables to SysWOW64 and makensis fails with "Unable to start child process, error 0x2". Store the tools in the project output directory in that case. * fix(bundler): fail clearly when the tools dir is still inside System32 The fallback to the project output directory doesn't help when the project or its target directory is itself inside the Windows system directory, for example a Jenkins workspace under the SYSTEM profile, and neither does `useLocalToolsDir`. NSIS and WiX would then fail with the same `error 0x2`, after a warning claiming the tools were moved somewhere safe. Check the final tools directory and return an error that explains the redirection instead. * docs(config): describe where tools go for the SYSTEM account The `useLocalToolsDir` docs still said tools are always cached in the user's cache directory when it's disabled and recommended enabling it for the Windows SYSTEM user because that directory is "restricted". Explain the WOW64 redirection, the new fallback to the build output directory, and what enabling the option still gains. * fix(bundler): log the SYSTEM tools dir warning once The NSIS and MSI bundlers, and their updater variants, each resolve the tools directory, so a single build printed the same warning up to four times. The warning also said `useLocalToolsDir` only silences it, while it actually moves the tools to `target/.tauri`, shared across build profiles and targets. * docs(bundler): only NSIS caches WebView2 installers in the tools dir The MSI bundler downloads the WebView2 installers into its own output directory, not into the tools directory. * fix(bundler): don't move the tools for a 32-bit x86 CLI `processor_architecture()` reports the native architecture, so a 32-bit x86 CLI on 64-bit Windows moved the tools out of the system profile cache, although it is redirected exactly like NSIS and WiX and the cache already worked for it. Check the build's own architecture instead. * fix(bundler): don't panic when there's no cache dir for the tools Now that there is a fallback directory for the NSIS and WiX tools, use it instead of panicking when the cache directory can't be determined, like the AppImage bundler already does for linuxdeploy. * refactor(bundler): rename tauri_tools_path to tools_directory The NSIS and MSI bundlers bind the result to a local tauri_tools_path, and build_nsis_app_installer takes a tauri_tools_path parameter, both shadowing the helper of the same name. * test(bundler): cover the tools directory selection The tests only covered the path prefix check and the system directory lookup. Split the selection into a function that takes the local tools, cache, project output and system directories, and test the precedence, both fallbacks and the System32 error. --------- Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* chore(deps): update rust crate minisign to 0.10 * fix js audit --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Tony <legendmastertony@gmail.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )