Called unimplemented OpenGL ES API message on emulator - opengl-es

I'm developing an Android application for Android 2.2.
When I run a program that uses OpenGL ES 2.0 on emulator I get the following error:
called unimplemented OpenGL ES API
But if I run the same program on a physical device with Android 2.2 it works perfectly.
What's happening?
Thanks.

Probably that you tried to do something that isn't implemented in the emulator.
Testing stuff on the Android emulator isn't a very nice experience for any kind of application, and for games or other real-time apps, or anything that uses multitouch, you should opt for testing on the device as much as possible anyway, IMHO. So not much lost there.

The emulator doesn't support OpenGL. You need to run and debug the application on a real Android device.

Related

Is it possible to use the ML Kit SDK on Wear OS?

I am wondering if anyone knows if it is possible to use the ML Kit SDK on Wear OS devices? I know Wear OS is based on Android, and I've seen references online to Firebase notifications working on Wear OS.
I have googled combinations of the terms "ML Kit", "Firebase ML Kit" and "Wear OS" but not found any definitive answers.
I don't have code on hand, but I am wondering would it even be possible to import/use the SDK on Wear OS apps in the first place.
Expected results would be being able to instantiate and use some of the machine learning models from the ML Kit API on a Wear OS watch.
Battery usage and efficiency are secondary at the moment, I'm just wondering if it is possible at all.
I have never tied it but I think it is possible. In the end, the Andorid Wear 2.0 (WearOS) is just another regular Android and it supplies direct internet access from the device.
I was able to succesfully use RenderScript on Wear devices but on the other hand I've faced an issue that Google Awareness API was not available on Wear. THis seem not to be the expected state.
Probably in the end you will need to do feasibility study on your own.
You can try to use some android MLKit sample and simply run it on Wear device.

Is golang supported in Android Things?

Can we use golang in Android Things?
I would like to program in golang an IoT app, however I don't find support for golang in Android Things.
From the point of view of Android application developer Android Things is pretty much the same. So if you can write Android apps in Go, you can do the same for Android Things app development.
As far as I know the Android Things offers just a lightweight version of Android.
Go supports mobile platforms such as android and IOS:
https://github.com/golang/go/wiki/Mobile
It still uses java/objective-c bindings though
Also check if you need Android Things, because there is nice framework:
https://gobot.io/#platforms
designed for iot.

Debugging OpenGL ES 2.0 game that runs in Windows through PowerVR emulation

I have small cross platform engine that runs my OpenGL ES 2.0 games on Android and on Windows. To run it on Windows I am using PowerVR emulator (just libraries linked to the project). It all works well.
Now I would like to debug it and inspect in any OpenGL debugger. I tried Intel GPA, AMD CodeXL, gDebugger, glslDevil. But non of them were able to do it. In case of Intel GPA it did not find the running game. In other cases it started the game but failed to pause it or do anything later.
I do not know whether it is because it is OpenGL ES instead of OpenGL. But the PowerVR emulation must work like translating OpenGL ES to OpenGL, I think?
My questions are:
Is there any (utility) way how to debug OpenGL ES 2.0 programs on Windows?
Or is there any better emulation library than PowerVR that will force the app look like OpenGL for other tools (instead of OpenGL ES)?
I am doing all this as none of debuggers work for me on Android device. I am developing with Samsung Galaxy Tab (which is Tegra GPU), but Nvida's PerfHUD ES does not currently support it (and I also do not meet Android 4.0 or higher having only 3.1)
Is there any way how to debug OpenGL ES on Android device that has Android version 3.1 and it is Samsung Galaxy Tab device?
Thanx
You're correct - PVRVFrame translates OpenGL ES calls into host OpenGL calls. This is why the likes of gDEBugger will capture the OpenGL API calls made by the emulator rather than the calls you actually submitted.
The PowerVR SDK includes an OpenGL ES/EGL API recording tool called PVRTrace that has all of the functionality you're looking for.
The PVRTrace recording libraries can be used to record applications using PVRVFrame on Windows and Linux. The SDK also includes recording libraries for Android and Linux devices.
PVRTraceGUI (analysis tool for Windows, OSX & Linux) can be used to review and inspect the data you've recorded. It also has an Image Analysis widget that allows you to step through the draw calls in your recording & some other handy features, such as a Pixel Analysis pie chart that highlights the most costly fragment shaders in your render so you know where to focus shader optimisation.
There's also a PVRTrace standalone playback tool that allows you to replay your recordings on any of the supported OS's (inc. Windows & Android).
You can find an overview of the tool on the Imagination website here & can download PVRTrace through the PowerVR SDK installer, available here
I routinely debug OpenGL ES on Windows using the PowerVR VFrame translator, which converts OpenGL ES calls to OpenGL, as you said. I think it's the best solution. VFrame has some step and tracing features, but mostly I am using the debugging features of MSVC++.
If you are using GLSurfaceView on android, it has an OpenGL ES tracing feature too. I also recommend using an X86 AVD rather than ARM or trusting the drivers on any one device. This article explains in detail:
http://software.intel.com/en-us/articles/porting-opengl-games-to-android-on-intel-atom-processors-part-1

Does Android X86 in virtual machine represent a real alternative to Android Emulator?

I am developing an Android application with jQuery Mobile, Phonegap and the jQuery plugin for Google maps. The emulator takes too long to load a web page, making the test of my code a painful operation. I have installed Android x86 on a virtual machine and linked it to Eclipse to debug my application.
This solution is faster than the emulator but the problem is that my application always crashes, which is not the case in the emulator. This leads me to question: is Android x86 on a virtual machine a stable alternative to the emulator?
In my experience, the answer is definitely Yes.
Unlike the situation you are describing, my application never crashes on the Android-x86 VM and since the SDK's emulator doesn't support microphone input, it is actually the only way to test my app without having to purchase a real device for each variant of Android.
Also, as you noted, it runs much faster. Contrary to Google's claim for "near native speed", Android's SDK runs extremely more slowly than Android-x86 and it is certainly slower than a real phone or tablet.
The fact that your application crashes when run on an Android-x86 VM may actually be a good thing: An opportunity to check for ways to make your application more robust in unforeseeable circumstances (you know, there are many types of devices out there).
The only downside to Android-x86 is that it is only available up to ICS (Android 4.0.4) which means that you cannot test your application in Jelly Bean (Android 4.1.x). That may be solvable by building your own VirtualBox-AOSP.
A lot of virtualization software and systems depend on hardware virtualization capability of the CPU (VT and such), but VirtualBox runs Android x86 (eeepc iso) great (fast) even without it. There are obvious limitations, but bear in mind that any emulator can only go so far.
If your CPU has no support for hardware virtualization, it is a very good alternative.
Google's Android SDK Emulator went native since version 17.
Google said in their ADT version-17 changelog
One of the new features is a big update
to the Android emulator – contributions to AOSP from Intel mean that
the emulator now runs at near native speed on Windows and Mac OS X.
So you shouldn't be seeing huge differences In speed of the application running if you are using the latest version of sdktools and emulator.

Will Android 2.2 apps work on Tablets running on 3.0 and higher version

My basic question is : Will developing android apps with android 2.2 SDK work for android tablets running on Honeycomb (android 3.0) and higher versions ?
Also, will apps developed for phones work on tablets ?
Adithya.
Yes, you can have the same apk work with 2.x and 3.x. Just use something like this in your manifest xml:
<uses-sdk android:minSdkVersion="4"
android:targetSdkVersion="11" />
If you have created a virtual android tablet you can test it on a tablet emulator, just right click your eclipse project, Run as -> Run Configurations, then check android 3.0+ in target tab.
For more info see:
http://developer.android.com/guide/practices/optimizing-for-3.0.html#Optimizing
As to the first they should, it's supposed to be forward compatible.
Having said that depending on how you developed you app it's possible that you are making use of features not present on the tablet. I have had apps that work on phones tank when I tried them on the tablet, mostly because I was not checking feature sets properly (mostly in the camera) so you do have to take some care.
Really this is not a tablet issue, more of a supported hardware issue but it becomes pretty apparent on those, many don't have cameras for instance, some don't have GPS etc.
As to the second, yes, but they won't be optimized for the tablet so your users might not like tiny images if you have not provided for higher resolution screens
I think no. Devices with Android 3.0 ang higher have xLargeScreen resolutions. And Android 2.2 doesn't have support for this. Only Android 2.3+

Resources