side-by-side NDK installed as the "(obsolete)" NDK #2689
Comments
|
I accidentally hit enter on this (in the title field, which apparently immediately submits the issue) before I was done working on the report, which I wasn't expecting to be done with until much later today :(. (I didn't even get to the step where I check if the issue is already submitted. I'm sorry.) |
saurik
changed the title
saurik
changed the title
|
FWIW, I've been able to get the NDK install to work a few times now (on builders that have the ndk-bundle copy), so I'm betting it is in fact the SSL issue that is actually the thing blocking the ability to install things, and not the inconsistent NDK installation paths. I feel like I've gotten the SSL error a long time ago also, but very rarely (in contrast to now, where it is causing most of--but apparently not all of--my builds to fail). |
|
Hello, @saurik, thank for your report. We install 2 versions of NDK (21.x and 22.x) side by side and |
LeonidLapshin
added
Area: Android
investigate
|
@saurik I'm going to close the issue since we deployed the images with both the latest NDK (22) and LTS NDK (21) versions. Symlink ndk-bundle points to LTS NDK at the moment. |
|
@miketimofeev Yeah, sorry; I've been having it on my todo list to try to figure out why installing the NDK was failing so often, but haven't done so yet (and it does seem to have cleared up, so it might have been some transient issue for those few days that either you fixed or Google fixed). That said, I think it is at least worth noting that merely making ndk-bundle a symlink to a side-by-side installation of the NDK is incorrect from the Android package manager's perspective: it causes those warnings, and build scripts that attempt to work with that ndk-bundle installation using the android tooling... like, think about what happens if you ask the android package manager to upgrade the "NDK (Obsolete)" package to the latest version... is it going to do it into the folder for the LTS NDK side-by-side? (It might not, as it might entirely delete the folder that's there first, but that isn't a given to me seeing the warning they currently are presenting for upgrades of even other packages.) I guess I personally don't see why you would be shipping this symlink at all: that's for a package Google marks "(Obsolete)" anyway. |
|
@saurik Thanks for the explanation, we made the symlink to provide backward compatibility for those folks who rely on |
|
@dibir-magomedsaygitov @miketimofeev So, this is either still broken or is now broken again after being fixed for a while. To maybe be more blunt about the issue, as I seem to have fully explained the problem before and yet I was still asked to "clarify": you can't arbitrarily symlink these two folders together and expect the result to work, as the contents of the Android SDK folder isn't some "just so" random collection of files but is instead the result of a package manager carefully installing and managing various versions of packages... like, I'm not sure what mental model you have for this folder which makes it OK to just randomly add a symlink for the ndk-bundle folder to something in the ndk folder, but it isn't shared by the people who wrote the Android SDK manager: if I run sdkmanager and ask it what is installed, it screams in pain--as I showed above--because there's this random symlink behind which the wrong package exists; and if I ask it to uninstall or upgrade the package, I can't, because the package is the wrong package in the wrong place and is malformed due to being a symlink instead of a folder full of files :(. |
|
@saurik I agree that the final result produces weird errors but on the other hand, we haven't found any other way to have non-latest ndk as ndk-bundle. If you have any suggestions, please share them as our team doesn't have much experience in Android development. |
|
@miketimofeev If that's your goal -- and I want to be explicit that I do not agree with this goal, as ndk-bundle was explicitly marked as "Obsolete" by Google years ago and is no longer even something Android Studio shows as installable unless you go out of your way to uncheck "Hide Obsolete Packages" (which I doubt many people do), and so I maintain you should NOT be attempting to do anything with ndk-bundle as no one should be using it anymore -- then you need to put a package called ndk-bundle in the ndk-bundle folder that has a package.xml with the correct package name but with the older version number so the package manager knows what is there and can manage it correctly. This isn't really an "Android development" issue but is more of a "how package managers work" issue :(. |
|
@miketimofeev Like, to provide the walkthrough of how the package manager works here: it is downloading a manifest of available packages from various repositories, similar to something like APT on Debian. These packages all have files that are associated with those packages and which have been installed on disk. The package manager knows what packages have been installed and if you ask it to install, upgrade, or delete packages it knows how to do that. Only, you've taken two folders that are from different packages and symlinked them together. So what is supposed to happen if someone asks to uninstall ndk-bundle? Is it supposed to delete all the files in the folder you symlinked it to? If you ask it to upgrade ndk-bundle, does it overwrite the files in that folder? This wouldn't work correctly if you did it on Debian either, as dpkg would go crazy messing with the wrong files for a different package. The one difference is that at least the Android SDK manager knows you did this, as it maintains the metadata embedded in the filesystem tree where the packages were installed, and so when it goes to check what is already installed it is taking the manifest of potential packages and where they would go, then looking to see if that package is installed by opening package.xml from inside of that package... and so it knows ndk-bundle is a package that can be installed to the ndk-bundle folder, looks in ndk-bundle/package.xml, but somehow finds "ndk;23.1.7779620" instead of "ndk-bundle" and so it prints a bunch of warnings and refuses to manage the package. If you want to put an old version of ndk-bundle in the ndk-bundle folder you need to have the metadata and structure match what the package manager expects: a physical folder (not a symlink) with a package.xml file that references ndk-bundle and a revision tag that has the older version in it. |
|
@saurik thanks for all the suggestions and such a detailed explanation. We haven't noticed that ndk-bundle is obsolete for a while so it might be a better solution to announce its deprecation from the images and remove all those weird symlinks after all. We will investigate the possible impact and prepare an announcement. |
It seems the symlink to `ndk-bundle` and this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK. actions/runner-images#2689 actions/runner-images#5926
|
Could this have possibly kept EDIT: After all, it seems this issue is solely about removing the deprecated |
It seems the symlink to `ndk-bundle` and this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK. actions/runner-images#2689 actions/runner-images#5926
It seems the symlink to `ndk-bundle` and this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK. actions/runner-images#2689 actions/runner-images#5926
It seems the symlink to `ndk-bundle` and this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK. actions/runner-images#2689 actions/runner-images#5926
Unify `with_app_id` and `with_class` methods Both APIs are used to set application name. This commit unifies the API between Wayland and X11, so downstream applications can remove platform specific code when using `WindowBuilderExtUnix`. Fixes rust-windowing#1739. Unify behavior of `resizable` across platforms This makes X11 and Wayland follow Windows and macOS, so the size of the window could be set even though it has resizable attribute set to false. Fixes rust-windowing#2242. Fix assigning the wrong monitor when receiving Windows move events (rust-windowing#2266) Fix embedded NULs in C wide strings returned from Windows API (rust-windowing#2264) On Wayland, fix hiding cursors on GNOME `wl_pointer::set_cursor` expects a serial number of the last `wl_pointer::enter` event. However other calls expect latest observed pointer serial, so this commit tracks both and use them as required by specification. Fixes rust-windowing#2273. Bump windows-sys version to 0.36 (rust-windowing#2277) Add new `Ime` event for desktop platforms This commit brings new Ime event to account for preedit state of input method, also adding `Window::set_ime_allowed` to toggle IME input on the particular window. This commit implements API as designed in rust-windowing#1497 for desktop platforms. On Wayland, provide option for better CSD While most compositors provide server side decorations, the GNOME does not, and won't provide them. Also Wayland clients must render client side decorations. Winit was already drawing some decorations, however they were bad looking and provided no text rendering, so the title was missing. However this commit makes use of the SCTK external frame similar to GTK's Adwaita theme supporting text rendering and looking similar to other GTK applications. Fixes rust-windowing#1967. Fix warnings on nightly rust (rust-windowing#2295) This was causing CI to fail: https://github.com/rust-windowing/winit/runs/6506026326 On macOS, emit resize event on `frame_did_change` When the window switches mode from normal to tabbed one, it doesn't get resized, however the frame gets resized. This commit makes winit to track resizes when frame changes instead of window. Fixes rust-windowing#2191. Reorganize `EventLoopBuilder::build()` platform documentation Since there's a "Platform-specific" header, it makes sense to put the Linux-specific part under it. On the other hand, "Can only be called on the main thread." is true for all platforms, not just iOS, so there is no reason to call it out for iOS specifically. [Windows] Avoid GetModuleHandle(NULL) (rust-windowing#2301) Use get_instance_handle() over GetModuleHandle(NULL) On Windows, fix reported cursor position. (rust-windowing#2311) When clicking and moving the cursor out of the window negative coordinates were not handled correctly. Revert "On Wayland, fix resize not propagating properly" This reverts commit 78e5a39. It was discovered that in some cases mesa will lock the back buffer, e.g. when making context current, leading to resize missing. Given that applications can restructure their rendering to account for that, and that winit isn't limited to playing nice with mesa reverting the original commit. Set `WindowBuilder` to must_use Add X11 opt-in function for device events Previously on X11, by default all global events were broadcasted to every winit application. This unnecessarily drains battery due to excessive CPU usage when moving the mouse. To resolve this, device events are now ignored by default and users must manually opt into it using `EventLoopWindowTarget::set_filter_device_events`. Fixes (rust-windowing#1634) on Linux. Prevent null dereference on X11 with bad locale Remove old dialog fix that is superseded by rust-windowing#2027 (rust-windowing#2292) This fixes the run_return loop never returning on macos when using multiple windows Migrate from lazy_static to once_cell macOS: Emit LoopDestroyed on CMD+Q (rust-windowing#2073) override applicationWillTerminate: On Android, use `HasRawWindowHandle` directly from the `ndk` crate (rust-windowing#2318) The `ndk` crate now implements [`HasRawWindowHandle` directly on `NativeWindow`], relieving the burden to reimplement it on `winit`. [`HasRawWindowHandle` directly on `NativeWindow`]: rust-mobile/ndk#274 Run clippy on CI Fixes rust-windowing#1402. Make `set_device_event_filter` non-mut Commit f10a984 added `EventLoopWindowTarget::set_device_event_filter` with for a mutable reference, however most winit APIs work with immutable references, so altering API to play nicely with existing APIs. This also disables device event filtering on debug example. Make `WindowAttributes` private (rust-windowing#2134) * Make `WindowAttributes` private, and move its documentation * Reorder WindowAttributes title and fullscreen to match method order Build docs on `docs.rs` for iOS and Android as well (rust-windowing#2324) Remove core-video-sys dependency (rust-windowing#2326) Hasn't been updated in over 2 years - many open PRs, seems abandoned. Is the cause of several duplicate dependencies in our dependency tree! Fix macOS 32bit (rust-windowing#2327) Documentation cleanup (rust-windowing#2328) * Remove redundant documentation links * Add note to README about windows not showing up on Wayland * Fix documentation links * Small documentation fixes * Add note about doing stuff after StartCause::Init on macOS Add `WindowBuilder::transparent` This is required to help hardware accelerated libraries like glutin that accept WindowBuilder instead of RawWindowHandle, since the api to access builder properties directly was removed. Follow up to 44288f6. Refine `Window::set_cursor_grab` API This commit renames `Window::set_cursor_grab` to `Window::set_cursor_grab_mode`. The new API now accepts enumeration to control the way cursor grab is performed. The value could be: `lock`, `confine`, or `none`. This commit also implements `Window::set_cursor_position` for Wayland, since it's tied to locked cursor. Implements API from rust-windowing#1677. examples/window_run_return: Enable on Android (rust-windowing#2321) Android also supports `EventLoopExtRunReturn`. The user will still have to follow the README to turn this example into a `cdylib` and add the `ndk_glue::main()` initialization attribute, though. Fix doubled device events on X11 Fixes rust-windowing#2332 macOS: disallow_highdpi will set explicity the value to avoid the SO value by default (rust-windowing#2339) ci: Disallow warnings in rustdoc and test private items (rust-windowing#2341) Make sure `cargo doc` runs cleanly without any warnings in the CI - some recently introduced but still allowing a PR to get merged. In case someone wishes to add docs on private items, make sure those adhere to the same standards. Bump smithay-client-toolkit to v0.16.0 Disallow multiple EventLoop creation Fix conflict in `WindowFlags` on Windows Map XK_Caps_Lock to VirtualKeyCode::Capital (rust-windowing#1864) This allows applications to handle events for the caps lock key under X11 Less redundancy and improve fullscreen in examples Remove examples/minimize which is redundant Implement From<u64> for WindowId and vise-versa This should help downstream applications to expose WindowId to the end users via e.g. IPC to control particular windows in multi window systems. examples/multiwindow.rs: ignore synthetic key press events Fix infinite recursion in `WindowId` conversion methods Add 'WindowEvent::Occluded(bool)' This commits and an event to track window occlusion state, which could help optimize rendering downstream. Add `refresh_rate_millihertz` for `MonitorHandle` This also alters `VideoMode::refresh_rate` to `VideoMode::refresh_rate_millihertz` which now returns monitor refresh rate in mHz. On Wayland send Focused(false) for new window On Wayland winit will always get an explicit focused event from the system and will transfer it downstream. So send focused false to enforce it. On Wayland, drop wl_surface on window close web: Manually emit focused event on mouse click (rust-windowing#2202) * Manually emit focused event on mouse click * Update CHANGELOG.md Co-authored-by: Markus Røyset <maroider@protonmail.com> web: Add `EventLoop::spawn` (rust-windowing#2208) * web: Add `EventLoop::spawn` This is the same as `EventLoop::run`, but doesn't throw an exception in order to return `!`. I decided to name it `spawn` rather than `run_web` because I think that's more descriptive, but I'm happy to change it to `run_web`. Resolves rust-windowing#1714 * Update src/platform/web.rs * Fix outdated names Co-authored-by: Markus Røyset <maroider@protonmail.com> Fix changelog entry for `EventLoopExtWebSys` (rust-windowing#2372) android: Hold `NativeWindow` lock until after notifying the user with `Event::Suspended` (rust-windowing#2307) This applies rust-mobile/ndk#117 on the `winit` side: Android destroys its window/surface as soon as the user returns from [`onNativeWindowDestroyed`], and we "fixed" this on the `ndk-glue` side by sending the `WindowDestroyed` event before locking the window and removing it: this lock has to wait for any user of `ndk-glue` - ie. `winit` - to give up its readlock on the window, which is what we utilize here to give users of `winit` "time" to destroy any resource created on top of a `RawWindowHandle`. since we can't pass the user a `RawWindowHandle` through the `HasRawWindowHandle` trait we have to document this case explicitly and keep the lock alive on the `winit` side instead. [`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed web: add `with_prevent_default`, `with_focusable` (rust-windowing#2365) * web: add `with_prevent_default`, `with_focusable` `with_prevent_default` controls whether `event.preventDefault` is called `with_focusable` controls whether `tabindex` is added Fixes rust-windowing#1768 * Remove extra space from CHANGELOG windows: Use correct value for mouse wheel delta (rust-windowing#2374) Make winit focus take activity into account on Windows (rust-windowing#2159) winit's notion of "focus" is very simple; you're either focused or not. However, Windows has both notions of focused window and active window and paying attention only to WM_SETFOCUS/WM_KILLFOCUS can cause a window to believe the user is interacting with it when they're not. (this manifests when a user switches to another application between when a winit application starts and it creates its first window) Fix typos (rust-windowing#2375) Bump sctk-adwaita to 0.4.1 This should force the use of system libraries for Fontconfig and freetype instead of building them with cmake if missing. This also fixes compilation failures on nightly. Fixes rust-windowing#2373. Tidy up "platform-specifc" doc sections (rust-windowing#2356) * Tidy up "platform-specific" doc sections * Unrelated grammatical fix * Subjective improvements Android: avoid deadlocks while handling UserEvent (rust-windowing#2343) Replace `Arc<Mutex<VecDeque<T>>` by `mpsc` Update raw-window-handle to v0.5.0 This updates raw-window-handle to v0.5.0. On macOS, fix confirmed character inserted When confirming input in e.g. Korean IME or using characters like `+` winit was sending those twice, once via `Ime::Commit` and the other one via `ReceivedCharacter`, since those events weren't generating any `Ime::Preedit` and were forwarded due to `do_command_by_selector`. Add method to hook xlib error handler This should help glutin to handle errors coming from GLX and offer multithreading support in a safe way. Fixes rust-windowing#2378. Windows: apply skip taskbar state when taskbar is restarted (rust-windowing#2380) Fix hiding a maximized window On Windows (rust-windowing#2336) Bump `ndk` and `ndk-glue` dependencies to stable `0.7.0` release (rust-windowing#2392) Fix type hint reference for xlib hook Consistently deliver a Resumed event on all platforms To be more consistent with mobile platforms this updates the Windows, macOS, Wayland, X11 and Web backends to all emit a Resumed event immediately after the initial `NewEvents(StartCause::Init)` event. The documentation for Suspended and Resumed has also been updated to provide general recommendations for how to handle Suspended and Resumed events in portable applications as well as providing Android and iOS specific details. This consistency makes it possible to write applications that lazily initialize their graphics state when the application resumes without any platform-specific knowledge. Previously, applications that wanted to run on Android and other systems would have to maintain two, mutually-exclusive, initialization paths. Note: This patch does nothing to guarantee that Suspended events will be delivered. It's still reasonable to say that most OSs without a formal lifecycle for applications will simply never "suspend" your application. There are currently no known portability issues caused by not delivering `Suspended` events consistently and technically it's not possible to guarantee the delivery of `Suspended` events if the OS doesn't define an application lifecycle. (app can always be terminated without any kind of clean up notification on most non-mobile OSs) Fixes rust-windowing#2185. ci: manually point ANDROID_NDK_ROOT to latest supplied version It seems the symlink to `ndk-bundle` and this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK. actions/runner-images#2689 actions/runner-images#5926 Fix changelog entry wrt scrolling The breaking change was put into the wrong release section. Release 0.27.0 version Explicitly specify minimum supported rust version This should help with distributing apps using winit. Fixes rust-windowing#1075. On X11, fix crash when can't disable IME Fixes rust-windowing#2402. Release 0.27.1 version Windows: respect min/max sizes when creating the window (rust-windowing#2393) On X11, fix window hints not persisting This commit fixes the issue with min, max, and resize increments not persisting across the dpi changes. Fix tracking of phase changes for mousewheel on trackpad (rust-windowing#2158) On Windows, add opt-in function for device events (rust-windowing#2409) Add CODEOWNERS file (rust-windowing#2420) * Add CODEOWNERS file This makes it very clear when you're stepping down from the post as a maintainer, and makes it clear for users who is expected to review their PR * Fix grammar * Make @kchibisov receive pings for the X11 platform * Fix typo Implement version 0.4 of the HasRawWindowHandle trait This makes Winit 0.27 compatible with crates like Wgpu 0.13 that are using the raw_window_handle v0.4 crate and aren't able to upgrade to 0.5 until they do a new release (since it requires a semver change). The change is intended to be self-contained (instead of pushing the details into all the platform_impl backends) since this is only intended to be a temporary trait implementation for backwards compatibility that will likely be removed before the next Winit release. Fixes rust-windowing#2415. Fix missleading breaking change on Windows The applications should not rely on not-implemented behavior and should use the right functions for that. Remove redundant steps from CI Tests are already building the entire crate, so no need for a separate builds slowing down the CI. On Wayland, fix `Window::request_redraw` being delayed On Waylnad when asking for redraw before `MainEventsCleared` would result for redraw being send on the next event loop tick, which is not expectable given that it must be delivered on the same event loop tick. Release 0.27.2 version On Windows, improve support for undecorated windows (rust-windowing#2419) Add touchpad magnify and rotate gestures support for macOS (rust-windowing#2157) * Add touchpad magnify support for macOS * Add touchpad rotate support for macOS * Add macOS rotate and magnify gesture cancelled phases * Correct docs for TouchpadRotate event * Fix tracing macros Document `WindowEvent::Moved` as unsupported on Wayland Update `sctk-adwaita` to use `ab_glyph` The crossfont will still be available under the option. Mark new events as breaking change Adding a new enum variant is a breaking change in winit. Co-Authored-By: kas <exactly-one-kas@users.noreply.github.com> Co-Authored-By: Artur Kovacs <kovacs.artur.barnabas@gmail.com> Co-Authored-By: Markus Siglreithmaier <m.siglreith@gmail.com> Co-Authored-By: Murarth <murarth@gmail.com> Co-Authored-By: Yusuke Kominami <yukke.konan@gmail.com> Co-Authored-By: moko256 <koutaro.mo@gmail.com> Co-Authored-By: Mads Marquart <mads@marquart.dk> Co-Authored-By: Markus Røyset <maroider@protonmail.com> Co-Authored-By: Marijn Suijten <marijns95@gmail.com> Co-Authored-By: Kirill Chibisov <contact@kchibisov.com>
Honestly, when reading some of your messages on #2481, I was concerned you were going to think you could do this (lol ;P). The files in the Android SDK are managed by a package manager, and the side-by-side NDK is not exactly the same managed object as the NDK package.
As far as I'm concerned, the correct strategy to is to just not install ndk-bundle and instead just install the intended side-by-side NDK for the LTS. Like, I'm pretty sure the NDK package--the one that goes in ndk-bundle--is literally marked as "Obsolete": do we really need it? ;P
This is causing warnings during install of side-by-side packages, but might also (I'm not sure: I was going to finish investigating this today and then type up a better bug report, but I accidentally hit enter on the title field and that apparently caused the issue to submit) be causing errors installing side-by-side NDKs?
Since I'm getting this SSL error also, I'm not sure (and now my mac builds are all just being queued and aren't going through so I can't even test this this morning to try to better isolate what is happening, but I've been getting this install error over the course of three days now).
The text was updated successfully, but these errors were encountered: