Difference Between native Android and ANE

[Apocalyptic0n3]

I'm trying to build an ANE that will display the native MediaPlayer object on top of my Flex Mobile app. So far, I have successfully done it. The issue is that it won't show up until after the app state changes (most easily by turning the screen off and back on). I was able to create a MediaPlayer in a native Android app using the exact same method (in this case, using a button to delay the creation). and it works exactly as it should.

It would be great if someone knew why this was happening (it seems to be isolated to SurfaceView and VideoView), but I would really like to know what the difference is between the AIR app and the Native App. I was under the impression that the AIR app was just a single Activity class that acted as a container of sorts for the AIR app. Is this not the case? The getActivity() from FREContext seems to provide a completely valid activity, yet there seems to be little issues all over the place with interacting with that activity and a great deal many things it does not like to do.

Could anyone explain the differences please?

[esdebon]

AIR is like the Java Virtual Machine,  is a program runing on your device natively, but an app Runing on AIR is no a native App.

[Apocalyptic0n3]

That is what I assumed. The resulting app is, in Android's case, a single Activity that runs as a window to the AIR app. What I'd like to figure out is why modifying that Activity using native Java is different than using a native app. I'm not modifying the AIR app itself, just the activity the AIR app is using.

[BigBobsky]

I've got exactly the same problem : did you found a solution ?

If I observe the view hierarchy created after adding a VideoView, I get :

android.widget.FrameLayout

|-android.widget.FrameLayout (a different one)

   |-com.adobe.AIRWindowSurfaceView

   |-android.widget.VideoView

I tried a lot of things : invalidating the views on Java side, refreshing on Actionscript side, bringing the VideoView to front in Java code ... But nothing works : when the VideoView is starting, the sound begins but the VideoView seems to be behind the AirWidnowSurfaceView until I perform a standby.

I've tried to place the VideoView just above the root FrameLayout, but it changed nothing.

According to his name, I think AIRWindowSurfaceView is derivating from SurfaceView so I can't add any child.

More ideas ?

Regards

[Apocalyptic0n3]

I spent three days trying to fix that very issue. Ended up having to call it quits and move on to another idea to fix Android video. That's about all I can offer you. Sorry.

[BigBobsky]

I finally found the right solution this morning and my native VideoView is shown as soon as the ANE call is returning, and the VideoView can be managed as wanted, and now I can play H264 mp4 and HLS more easily.

[Apocalyptic0n3]

How were you able to do it?

[BigBobsky]

I created a native implementation function in Java to create a VideoView. In this function I get the first child of the android.R.id.content view :

			FrameLayout root = (FrameLayout)act.getWindow().getDecorView().findViewById(android.R.id.content);
			ret = (FrameLayout)root.getChildAt(0);

It should be a FrameLayout containing a com.adobe.AIRWindowSurfaceView.

I call setZOrderOnTop(true) on this VideoView, then I add my VideoView to the FrameLayout.

I set FrameLayout.LayoutParameters to define the size and position of the video.

It's the first implementation I described in my initial post and which didn't not work. I just added the setZOrderOnTop(true) in place of my initial bringToFront().

[heartgoon]

can you show us your code？

[heartgoon]

i want to ask u another question，if u jump from the flex to ane，would it be slow？

if u return from the ane to flex，and than go back to ane，would the activity recreate or keep？