Should we remove NativeActivity?

cocos2d-x C++
#1

Hi all,

We found a problem that, when using NativeActivity and set orientation to landscape, then application will be black at first time, and will be ok next time on some Android devices. Now these devices are reported to has the problem

  • xiaomi 1
  • xiaomi 1s
  • htc-leo
  • and may be other devices.

This problem also exists in NDK native-activity sample. If you change orientation to landscape, it also has the problem. So the problem caused by the following two effects

  • use NativeActivity
  • set orientation to landscape

We don’t know how to resolve it when using NativeActivity. So if we can not find a way to resolve it before releasing stable version. Then we have to remove NativeActivity, and use GLSurfaceView as v2.x did. Then we will lost the benefit of NativeActivity: handle touch message more smoothly.

Any thoughts?

#2

With “smoothly” we are talking about performance?
How much performance is gained using NativeActivity?

#3

This is a common problem. Some devices change their hardware at runtime and need restart the activity. You can cache somethings and get after it reload to keep state.

This behavior happen when you change orientation to landscape.

#4

I prefer to use Java Activity to NativeActivity. It allows to use WebView!
So I’ve created the pull request for removing NativeActivity :slight_smile:
It includes a fix for multithread JNI call problem.

#5

same here, I prefer Java Activity other than NativeActivity,
not only I also do webview overlay, I do my own textedit and ads as well.
so far I’ve found a way to build my own custom view on top without stopping the frame rate, but it is not a perfect solution.
Thanks, and I want more freedom, like the beta2 we can still edit the project settings and not forced the command line.

#6

NativeActivity to my knowledge handles touches much more responsive.

for a fast paced touching game, you really need NativeActivity to match the touch response of an iphone

#7

@Chano
Yep. It is about performance. We haven’t exactly data.

@prchakal
So you agree to remove NativeActivity, right?

@ splhack
Thanks. We try to resolve the issue first with NativeActivity, then if not found any method, then we will remove NativeActivity. What do you think?

#8

I prefer Java Activity other than NativeActivity.

NativeActivity is, as you may have noticed, buggy.

Have you reported this to Google? What is the issue number so we can +Star and “me too!” on it.

#9

I have just reported it to Google https://code.google.com/p/android/issues/detail?id=67448&thanks=67448&ts=1395374087.

#10

I prefer Native activity.
It has issues.
Few devices crash with java.lang.IllegalArgumentException: Unable to find native library: game, because of Native activity. And Asus devices have problems with orientation too.

But Java activity had issues too, especially with sleep mode. I found that on some devices I can turn off screen during game and GLSurface will continue work and drain battery. And there are some other problems. So it’s not perfect.

I think it’s ok to don’t support few old devices. It’s like 0.01% of them, who cares.
Java activity has more serious issues.

I hope that you will keep Native activity or maybe make choice between them.

#11

@ondesly
We don’t know how many devices have the problem with orientation problem. So it is a potential problem. About Java activity, i think we haven’t meet big problems since v1.x. Could you please describe the problem of java activity in more detail?

And we will not remove NativeActivity if we can find a way to resolve the problem.

#12

Maybe we can ignore these old devices. I think htc-leo was a windows phone from 2009.

On pressing home and then launching app again, cocos2dx reloads all resources etc… maybe on these devices we just need to reload all resources once again after app is full launched.

My guess is that maybe on these devices, app is always launched as portrait and then changed to landscape orientation after launch. In v3.0 we have support for orientation change events using native activity. Maybe check if that event (or some other native activity event) is received at end and we can then need to reload/reinit resources. That might give us same effect as pressing home and launching app again.

#13

Another possible solution can be to just mention ‘android:configChanges’ with ‘orientation’ and ‘screenSize’ options. This will stop android from re-creating the activity if an internal orientation change event is happening.

(I am just guessing, don’t know if any of this will actually work as I don’t have a test device with this bug).

#14

@schngrg
Thanks for you suggestion.
We will try it.

#15

No. I prefer keep the actual version and wait google solution. If the user have problem only need lock orientation on manifest.

Cocos2dx focus is to touch devices and you want remove nice touch features because a bug?

Im trying find a solution on web.

#16

Just curious. How to measure the smoothness of handling touch messages?

I mean I don’t feel any difference of touch sensibility between Java Activity and NativeActivity. I double checked AOSP NativeActivity code, it seems actually the event handling overhead of NativeActivity is less than Java Activity. However I’m not sure that we can feel the difference in touch sensing.

#17

For iOS, we can use any UIKit libraries seamlessly on Cocos2d-x 3.0.

But for Andorid, we can not use any Java View libraries seamlessly on Cocos2d-x 3.0.

So, how about providing a compile-time option for selecting NativeActivity or Java Activity? Unity does that.

#18

The less Java to C++ calls that are made, the faster the game will be.
It is going to easier to maintain as well.
Not only for touches, but also for glview, etc.

As an example:

  • For desktop we are using GLFW. It is a nice abstraction to all the GL / events for desktop.

We need something similar for mobile as well:

  • Currently the code for handling GL / Events in iOS is completely different than Android.
  • If you want to change some of the GL parameters both in iOS and Android, it is almost an impossible task.

So, we need to either add support for iOS and Android in GLFW, or create our own wrapper.
And I think that if we drop support for Native Activity, it will very difficult to do it using the Java activity.

Example:

So,

  • I do think that we need Native Activity
  • We need to fix the current bugs… we know some Android developers (@minggo, you already know them… search for Liquidfun in your email)
  • and then refactor the current way to create GL Views / touches for iOS and Android… something similar to what we have in GLFW.
#19

Interesting,

So, libsdl2 is using the Java Activity… and it is super easy to setup a window in libsdl.

So, forget about what I said:

  • We need a good abstraction of window/GL management, and event management for iOS and Android.
  • And it seems that it is possible to do it using Java Activity as well.

But really, we need that. It is very difficult, if not impossible, to customize a GL window on Android… Just try to crate a game that uses half the screen (not full screen)… I think you can’t because everything is hard-coded. We can learn from the libsdl API, or from GLFW.

Anyway, there is a project that has libsdl working on Native Activity:
http://code.google.com/p/android-sdl-native/

#20

@ricardo wrote:

But really, we need that. It is very difficult, if not impossible, to customize a GL window on Android… Just try to crate a game that uses half the screen (not full screen)… I think you can’t because everything is hard-coded. We can learn from the libsdl API, or from GLFW.

+1!

There are some android devices that aren’t powerful enough to run games at native screen resolution. For example, my tegra 2 tablet runs the DrawNode test at 21fps! Allowing to change internal frame size is very important for these type of devices.