On Android, how do you get the height of top and bottom bars of system icons and buttons?

[rnikander]

I've got an Android app working, sort of. When I render my UI it appears superimposed with the system stuff at the top and bottom of the phone screen. I mean the clock, battery, and other icons at the top, and the back/home/menu buttons at the bottom. The inner_size and outer_size of the Window are the same. I don't see any properties that I can use to get the dimensions of these system areas, so I know how much to offset my content.

I see some dicussion here about a safe_area but I don't see it in the crate docs for the latest release.

I'm using a NativeActivity, configured in my AndroidManifest.xml, and apparently that calls the android_main(app:AndroidApp) function, from which I call winit to create Window, etc.

In some apps I would like to get rid of the system bars, to have more area, for a game, for example. But in normal apps, I want to keep those and render my content in the smaller area (same width, less height) between them.

[madsmtm]

From my understanding, inner_size/outer_size being equal is intentional, and safe_area should indeed be the solution to your problem, except that it isn't implemented on Android yet, see #3910. PRs welcome.

[rnikander]

I'd be interested in submitting a PR, if I can figure out how to do this. I can't even find where the information is, in Android with or without Rust. Do you have any pointers about that?

I thought maybe the AndroidApp::content_rect() would be it, but that is returning (0,0,0,0). I don't see anything on NativeWindow. (?) It looks like the jni crate is not a dependency of winit at the moment. I've been using jni in my app for other things, but even with that, I don't know how to get this margin-size info, because I don't know where it is in the Java APIs.

I'm surprised this is so hard to find!

[madsmtm]

Don't know much about Android myself, maybe @MarijnS95 has a better clue?

[madsmtm]

Though a quick search did reveal this, might be it?

[rnikander]

That looks promising. I'm using NativeActivity now, with no Java code, just the setup in the manifest xml file. But this WindowInsets stuff may require some setup of Jetpack Compose. I'll look into it.

[MarijnS95]

There has been a lot of prior art on hiding those bars, for example:

https://github.com/fornwall/wgpu-game-of-life/blob/d7295accf97f8e87efdf43d13d0380c8e96cf184/src/android.rs#L49-L83
https://github.com/MarijnS95/android-support/blob/cc03005d2f5b8c4036685d17ee986de5406e5e4f/java/Activity.java#L8-L19

[rnikander]

That is for hiding the bars, which I want to do sometimes. Do you also know how to get their size, so that you can not hide them, and correctly render your window content so that isn't underneath them?

[MarijnS95]

IIRC WindowInsets, but I haven't used these myself yet.

Unfortunately that requires Java types and callbacks that aren't available in NativeActivity. Funnily enough we keep discussing our pipe dream of building a special RustActivity subclass (as recently as 30 minutes ago, and also the intent of my android-support proof-of-concept repo linked above) where we can build our own callbacks and abstractions and hook them directly into Rust, without going to lengths - and many horrible bugs - of forcing everyone to use GameActivity with a massive and error-prone C++ stack (not to mention how hard it is to compile and bundle GameActivity Java code with it, using Rust-only tools).

[rnikander]

I have a couple Apple/Swift apps that I've been trying to rewrite to be cross-platform, using a single native codebase. First I tried C++, now I'm trying Rust. I don't mind using Xcode and Android Studio for a bit of wrapper/shell code for each product. So maybe I can create a normal Activity in Android Studio with Java/Kotlin, and set up a few things (like this window insets info) and then call into Rust for the rest of the app. I need fast graphics (Vulkan or WGPU) and fast event handling for touches/stylus. For iOS I have a Rust library and literally a one-line main() in Objective-C that calls into it. Xcode can handle the app packaging and uploading. So far I haven't figured out Android...

[MarijnS95]

There are unfortunately about a million ways to set up, build and package your app on Android, all depending on very specific needs. Here are a few of the top of my head (that I'm using):

• Pure Rust app with NativeActivity: look at cargo-apk/xbuild;
• The same, optionally with custom Java code, built by gradle / Android Studio:
  • either use cargo ndk to compile and bundle your Rust code, or;
  • use the unfortunately-deprecated rust-android-gradle package from Mozilla;
  • (Notice that xbuild can also use gradle under the hood to make AABs for Google Play releases, but it's a bit tedious).
• Or leave all Android event and lifecycle handling in Java/Kotlin (i.e. not using winit/android-activity, and only call into Rust code for very specific functionality: https://github.com/MarijnS95/AndroidNativeSurface (this example uses rust-android-gradle to compile and bundle Rust code);
• The previous mentioned RustActivity, where your app is still built with cargo-apk but build tools under the hood compile or provide Java/Kotlin code or classes for the final APK: Fix GameActivity touch inputs in the presence of a stylus rust-mobile/android-activity#185 (comment).

For your case specifically, if you wish to keep using winit, see how https://github.com/rust-mobile/rust-android-examples sets up a NativeActivity subclass to handle some extra code. If you're doing any abstracting in Java and wrapping things in JNI on the Rust side, feel free to contribute them to https://github.com/MarijnS95/android-support so that I can ensure it'll end up in the impending RustActivity.