Skip to content

Android support #53

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

Open
wants to merge 26 commits into
base: master
Choose a base branch
from
Open

Android support #53

wants to merge 26 commits into from

Conversation

mzdk100
Copy link

@mzdk100 mzdk100 commented Jul 20, 2025

This is an initial commit that only implements the Runtime on Android.

RUNTIME.set(self, f)
}

pub fn block_on<F: Future>(&self, future: F) -> F::Output {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please refer to winio-pollable and winio-ui-winui for a correct implementation of block_on.

  • We don't alloc for future. We just call spawn_unchecked.
  • We need to poll the driver fd and the app event together. If it's not possible, we poll the driver fd in another thread. Your current implementation is enough for GUI to run correctly, but the IO operations will not complete.

Copy link
Member

@Berrysoft Berrysoft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Please rebase the PR.
  • Please add .idea to .gitignore.

I have left some comments. The runtime needs to be modified to make sure compio works well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a suggestion: maybe better to use Makefile?

// 通过JNI设置TextView的文本对齐方式
RUNTIME.with(|rt| {
let view = self.tv.clone();
rt.vm_exec(|mut env, _act| {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just comment: seems too painful to implement.

@@ -31,7 +31,10 @@ winio-ui-winui = { workspace = true, optional = true }
[target.'cfg(target_os = "macos")'.dependencies]
winio-ui-app-kit = { workspace = true }

[target.'cfg(not(any(windows, target_os = "macos")))'.dependencies]
[target.'cfg(target_os="android")'.dependencies]
winio-ui-android = { workspace = true, optional = true }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't have to be an optional dependency.

@mzdk100
Copy link
Author

mzdk100 commented Jul 20, 2025

Okay, I need some time to study.

@Berrysoft
Copy link
Member

Take it easy. You have done tremendous work. It's just some small problems (and a lot of todo!()s).

Does the java vm have to be executed every time in each method? Could we just execute the vm in block_on?

@mzdk100
Copy link
Author

mzdk100 commented Jul 20, 2025

Does the java vm have to be executed every time in each method? Could we just execute the vm in block_on?

It can run in block_on. However, I found that when calling some Android APIs, they are very strict with thread checking (android_activity::AndroidApp creates a separate sub thread when the application starts, and android_main runs in this separate thread, requiring us to complete UI update operations in this sub thread). In our own block_on method, it seems that it is not this thread (for example, calling the WindowManager.addView method will fail):
E AndroidRuntime: FATAL EXCEPTION: Thread-5
E AndroidRuntime: Process: rust.winio_android_example, PID: 1947
E AndroidRuntime: java.lang.RuntimeException: Can't create handler inside thread Thread[Thread-5,10,main] that has not called Looper.prepare()
E AndroidRuntime: at android.os.Handler.(Handler.java:228)
E AndroidRuntime: at android.os.Handler.(Handler.java:130)
E AndroidRuntime: at android.view.ViewRootImpl$ViewRootHandler.(ViewRootImpl.java:7577)
E AndroidRuntime: at android.view.ViewRootImpl.(ViewRootImpl.java:7995)
E AndroidRuntime: at android.view.ViewRootImpl.(ViewRootImpl.java:1504)
E AndroidRuntime: at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:534)
E AndroidRuntime: at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:426)
E AndroidRuntime: at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:178)
If running in android_main, this situation is impossible (because Looper will be automatically created), so I don't know if the block_on method will be scheduled by Winio to run on another thread.

@Berrysoft
Copy link
Member

I understand about the thread checking. But anyway the future is running on the same thread as block_on. If it's valid to call vm_exec inside the future, it should be valid to call vm_exec inside block_on.

@mzdk100
Copy link
Author

mzdk100 commented Jul 20, 2025

If it's valid to call vm_exec inside the future, it should be valid to call vm_exec inside block_on
That's right, the future and block_on belong to the same thread. But now this thread is not the expected thread for android_activity::AndroidApp.

@Berrysoft
Copy link
Member

If it's not the correct thread, how do you call vm_exec in the correct thread?

@mzdk100
Copy link
Author

mzdk100 commented Jul 20, 2025

I should have investigated thoroughly, it's not a block_on issue.

Copy link
Member

@Berrysoft Berrysoft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the changes not relative to Android support.

@@ -20,7 +20,7 @@ members = [
resolver = "2"

[workspace.package]
edition = "2021"
edition = "2024"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better not. It's not recommended to use edition = 2024 in libs, because it limits the supported rustc version.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's okay, edition2024 will be compatible with older versions of Rustc, and many of the new features it brings are very practical.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain with more details that why do you need edition 2024.

SmileSky added 6 commits July 26, 2025 13:21
…nctionality

refactor(android): cleanup TODOs and implement missing Progress methods
feat(examples): add widgets example for Android and update hello example
fix(layout): fix macro syntax for expr patterns

Signed-off-by: SmileSky <[email protected]>
…onality

refactor(android): cleanup TODOs and implement missing methods for widgets
feat(android): add event handling for ComboBox change and select events
refactor(android): improve widget conversion and add Option<usize> support

Signed-off-by: SmileSky <[email protected]>
…Edit widgets

refactor(android): rename ComboBox event methods to past tense (on_change -> on_changed)
feat(android): add Tooltip implementation with accessibility support
fix(android): implement missing Progress and RadioButton widget methods
feat(android): add text change events for Edit and TextBox widgets

Signed-off-by: SmileSky <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants