[BUG] android_native_app_glue APP_CMD_WINDOW_RESIZED / APP_CMD_WINDOW_REDRAW_NEEDED / APP_CMD_CONTENT_RECT_CHANGED

[tsuoranta]

Description

android_native_app_glue.h has a few APP_CMDs which are never created by android_native_app_glue.c:

• APP_CMD_WINDOW_RESIZED
• APP_CMD_WINDOW_REDRAW_NEEDED
• APP_CMD_CONTENT_RECT_CHANGED

Looking at base/core/jni/android_app_NativeActivity.cpp and base/core/java/android/app/NativeActivity.java it seems callbacks such as code->callbacks.onNativeWindowResized would be called, if android_native_app_glue.c would bother to set up such callback function.

How should I deal with these APP_CMDs? I could use modified android_native_app_glue and wire them. Or is it safe to ignore these?

Environment Details

• NDK Version: 20.1.5948944
• Build system: gradlew - see ndk_samples
• Host OS: Linux, Ubuntu 19.10
• ABI:
• NDK API level: platformVersion = 12, compileSdkVersion 28, targetSdkVersion 28
• Device API level: N/A

[enh-google]

oops. i can't explain that from the history --- onContentRectChanged, for example, has been there since 2012.

I could use modified android_native_app_glue and wire them.

yes, feel free to do that.

i don't know what @DanAlbert thinks, but i'm torn about fixing this. it's obviously wrong, but i'm wary of suddenly sending folks messages they didn't receive in the past.

[DanAlbert]

but i'm wary of suddenly sending folks messages they didn't receive in the past.

Can we do this in a targetSdkVersion gated manner?

[enh-google]

no, that's the kicker --- all of this stuff is actually ancient, it's just a bug that it's still not wired up here in the NDK glue. (so although we could make it depend on targetSdkVersion, but that would be weird and mostly pointless. we may as well just say "yeah, fork your own copy".)

given that you'd have to rebuild your app with a newer NDK to start seeing this stuff work like the docs claim it should work, maybe it's okay to change?

[enh-google]

dan explained in person that what he meant was checking target sdk version at run-time, which makes this a run-time behavior difference (of the kind that app developers expect when incrementing target sdk version) rather than a build-time difference ("because i used a newer NDK") which app developers expect to manifest as a compile-time difference (aka build break :-) ).

anyway, https://android-review.googlesource.com/c/platform/ndk/+/1180321 is a possible implementation (without the run-time check). i still need to find the time to actually work that into a sample app and test it properly though...

[DanAlbert]

@tsuoranta any thoughts on whether we should gate the new behavior behind targetSdkVersion, or whether using a newer NDK is a sufficient enough opt-in barrier?

[magestik]

@DanAlbert I think the proposed fix is fine and adding run-time check would make the fix harder to get and add more confusion. We all know that we should thoroughly test our apps after upgrading the NDK anyway.

For what it’s worth I've been using this workaround successfully :

void android_main(struct android_app* state)
{
	state->onAppCmd = handle_cmd;
	state->onInputEvent = handle_input;

	state->activity->callbacks->onContentRectChanged = myOnContentRectChanged;

	...
}

[DanAlbert]

SGTM. Thanks for the feedback.

[Andreyogld3d]

@DanAlbert, will be this fix included in NDK 21 ?

[DanAlbert]

No. The sidebar on the right shows which release a bug is triaged for, btw.

[enh-google]

https://android-review.googlesource.com/c/platform/ndk/+/1180321 merged for r22.