Today Google just released the GDK Sneak Peak for Google Glass. I have tried to run the samples they have hosted in GitHub with no success:
gdk-stopwatch-sample
gdk-compass-sample
gdk-timer-sample
I am targetting against Android 4.0.3 Glass Development Kit Sneaky Preview and trying to run it in an AVD that also targets it with the following other specs:
640x360 hdpi
For the CPU I tried both ARM & Intel Atom
When I run the app and the dialog to choose the device is shown I do see the virtual device as non compatible.
If I skip it and try to run it I see the following error output:
Installing com.google.android.glass.sample.compass
DEVICE SHELL COMMAND: pm install -r "/data/local/tmp/com.google.android.glass.sample.compass"
pkg: /data/local/tmp/com.google.android.glass.sample.compass
Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]
I have tried to force not to require the glass library (setting the requirement to false) in the AndroidManifest.xml:
<uses-library
android:name="com.google.android.glass"
android:required="false" />
... but obviously doesn't run properly, it's being shown in kind of an overlay:
I have also tried using Genymotion, but it doesn't run either.
Is there any way to run successfully glassware in an emulator?
EDIT:
Adding the gdk.jar as a library doesn't work.
Only a small percentage of the sample code seems to be using the GDK libraries. For example, the Compass example has a CompassService that is in charge of attaching the CompassRenderer into the Glass Live Card. It also has a CompassMenuActivity, that basically has calls to standard Android menu rendering. Those could be called a "glue" that wrap the compass-functionality into the Glass experience. Major parts of the compass code are just standard Android libraries.
Assuming that the emulator currently does not have a way to run glass libraries (and no-one has hacked them into it yet), and if you want to run the Compass example without actual Glass hardware, you need to implement the Service & MenuActivity in your own "standard Android" way. Basically, create an activity that implements the CompassRenderer in a surfaceview.
Have a look at these commits for an example (tested on Galaxy S4, views are being rendered and menu items are functional):
https://github.com/blaind/gdk-stopwatch-sample/commit/26e9801af983b9fc931d6dfe5ce1fcb80766fd10
https://github.com/blaind/gdk-compass-sample/commit/0d89e922a167c0fac6890684c514b9028e7bfea8
Related
I am aware of Genymotion openGL error stack overflow question.
I am attempting to run Genymotion on a Windows 10 system, but the graphics adapter is Intel G45/G43 Express Chipset WDDM1.1 and the driver supplied does not support OpenGL and Intel appear to have no interest in delivering a driver that does for Windows 10. I understand that officially this combination is not supported.
But here's the thing: I can start a Genymotion VM fine from Virtual Box, and it appears to work (almost) perfectly, as far as I can tell.
Certainly I don't see any problem with the graphics.
This must be using some (probably Virtual Box provided) software implementation of OpenGL.
However, when I try to start the same phone VM from the Genymotion console, or from the Genymotion button inside Android Studio, I get the error dialog-box in the linked question above.
My question is: Why is Genymotion insisting that there is OpenGL support from the real physical display driver? And of course, if its for a quality reason only (ie: sub-optimal user experience otherwise) is there any way to disable this check?
The reason this matters is that Android Studio does not list the Virtual Box started phone VM as somewhere an application can be run upon. I suspect that when Genymotion runs a phone VM, they set up something that the Android Studio integration needs, that simply running from Virtual Box doesn't provide.
In addition, I can't circumvent the Android Studio integration by deploying to a phone VM using the gmtool device install file.apk command bundled with Genymotion because this is a paid license feature. As you can imagine I am somewhat reluctant to purchase such a license when I know I am running in an unsupported configuration.
Purchasing new hardware also isn't an option for me in the short term.
EDIT: The justification for this question has since evaporated. Although I can't deploy using Android Studio or gmtool.exe, I have managed to deploy by using the phone web browser to fetch the .apk file. The gotcha here is that the web server must supply a Content-Length header or the download will fail. So I now have a workable solution.
{{{ Andy
I'm part of the Genymotion team. That's an interesting question. The answer is: yes, we ask for OpenGL drivers for performance reasons. Without this, the whole Android rendering would be handle by the CPU (as soft rendering) which is not fast enough to allow a real usage of the devices, with a seamless user experience, particularly since 4.3. If you run a 4.2.2 image from VirtualBox, you'll see the UI inside the window but the rendering will be very laggy.
As you maybe already noticed, running the Genymotion devices from VirtualBox works only for images up to 4.2.2 (released 3 years ago). The other image will show only a console window. And to be honest, you should more consider it as a side effect than a real feature. This behaviour could disappear on a future release for any reason. And there is no way to disable this check.
As you mentioned, this configuration is really weird and exceptional. As far as I know, we don't plan to support these kind of configuration and I don't see any real viable solution to make it work properly.
Also, to explain the problem you encountered with Android Studio. When a Genymotion device start, it gets a local IP. This IP can be used to connect it to adb. Then it is possible to interact with the device like with any other Android device. This is the tools used by your IDE (and (m)any other tools communicating with Android devices.
Usually, the Genymotion app does this for you, by connecting the newly started device to adb. But you can do it yourself by running adb connect <DEVICE_IP>:5555. Just be careful because this connection could not be permanent and you should have to run this command regularly in some situations.
I hope this answer will help.
Cheers.
I don't have a google glass device. But I am very interested to do apps for Google Glass. I want to run a Hello World in Google Glass without the use of device.
I followed the tutorials for Google Glass. Then I found some sample projects of Google glass. Can Anyone tell me how to run a simple Google Glass Project on an emulator or without a device.
And can you tell, Is there any alternative way to test the Glass APK developed by us without device.
First you need to set up Glass On mobile or an Emulator in Web. Gooogle Glass is orignally a launcher over android you need to install the apks of that launcher.
Here you will find the APK's (however Camera for Glass never worked for me.)
Here is an Album showing you the process (on Nexus 7)
And This is the set of Demo's
After all set up you have to connect the android phone and then install the apk's using adb.
e.g.
adb install -r com.sample.packagee
after that you can launch the app through voice command or if it doesnot support voice trigger then launch it like
adb shell am start -n com.mikedg.android.glass.launchy/.MainActivity
I am writing down a wiki for the issues and the to do's Please check it here..
There are no simulators right now available to do perform testing without the device.
First :
You can try this https://github.com/zhuowei/Xenologer and install the apk on mobile device which is more or less similar to what you are looking for.
Second :
You can try thus but u have to build your application based on Mirror API http ://glasssim.com/ or
https ://developers.google.com/glass/tools-downloads/playground
Third to have your custom apk install :
https ://developers.google.com/glass/develop/gdk/quick-start#installing_the_samples
To display your hello world Try second option it should work. It will add your card in Glass Timeline.
Hope this answers your question.
Thanks
There is not an emulator for Glass at this time. Testing on Glass is an important part of a Glassware development life cycle as the user experience is completely different from what you can experience on a phone or an emulator.
Feel free to follow issue 253 on our issue tracker for updates as the GDK evolves.
When integrating a Google Plus login button in an Android app, I'm observing some differences in how the button appears on an actual device and in the emulator. I am aware of the fact that the Google Plus services APKs are not installed in the emulator, but this can be worked around by pulling the APKs from a device and installing them into the emulator using APK.
My current "implementation" simply includes the login button in a layout, by referring to the button with the following XML code:
<com.google.android.gms.common.SignInButton
android:id="#+id/sign_in_button"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
When I test my app on the device, the button appears all red and shiny, according to the guidelines mentioned here https://developers.google.com/+/mobile/android/sign-in . But when running on the emulator, it's just a normal button (grey background with black text) saying "Sign in with Google".
Any idea why the results are different? I've made sure I'm running the same API level, and the resource does seem to get pulled in correctly also on the emulator since it shows the actual login button (but with a different look).
Update: Found a clue in logcat; the message "Sign in button not found, using placeholder instead." pretty much explains why I'm seeing the grey dull button on the emulator. Still need to figure out why; could be the "copy google plus apk's from device" hack isn't working properly.
Google Play services works on the 4.2.2 versions of the Android Emulator and is officially supported as described in the Android documentation: Setup Google Play Services.
Update
You now can use the Intel/x86 images (HAXM-compatible) for API 19 and newer and for ARM, Google Play Services is available on most images.
Setting up the image
To get the right image for your virtual device manager:
Open the Android SDK Manager
Open the group Android 4.2.2 (API 17)
Check Google APIs
Check ARM EABI v7a System Image
To create the Virtual Device:
Open the Android Virtual Device Manager
Create a New device
Enter an AVD name
Set the target to Google APIs (Google Inc.) - API Level 17
Save your Virtual device and start it...
Note CPU/ABI will be fixed as ARM
Now you should be able to use the Google Play Services in the emulator. Of note, you need to set your target appropriately in your Android project to the Google APIs in order for Google Play Services to work.
I tried most combinations of running the emulator, but with and without the Google APIs, which means I tested with both x86 and arm modes. I found no way of making the apk's pulled from my Galaxy Nexus phone to run correctly on the emulator.
Guessing this is somewhat related to getting the Play Store up and running, I decided to try that as well to see if I had more luck. I did not; could not get that working either. The Play Store icons appear and can be launched, but it immediately closes itself.
What did work however was to download and install the apks at the bottom of the page here:
http://umut.tekguc.info/en/content/google-android-map-v2-step-step
After installing the vending and gms packages, the login button appeared in it's full beauty under the emulator. Since I haven't actually implemented the actual login functionality yet, I can not be sure that it will actually work, but at least the button now looks identical in my app on my device and in the emulator.
You also need to download the Google Play Services software (look under "Extras" in the Android SDK manager), and install the library google-play-services_lib in your project (File-Import-Android-Existing Android Code Into Workspace, and then browse to for instance /opt/adt-bundle-linux/sdk/extras/google/google_play_services/libproject and select google-play-services_lib).
Another interesting tidbit is that this will only work on the "pure" Android emulator setups, not with the "Google API" setups. It seems the latter have some parts of those apps installed in the emulator already (not visibly and not working), and I haven't managed to remove the existing versions to install the custom apk files that worked as described above. I tested adb remove, adb install, adb install -r, and even removing the directories from /data which also failed. It's looking very much like Google is trying to make this difficult.
I'm disappointed Google is making this so hard; Google may have some weird licensing reasons for keeping this stuff out of the emulator, but if they really want people to use their services in their Android apps they need to make these services available in the emulator. Forcing people to always develop on a device (with otherwise excellent emulators available) or making people jump through hoops (lots of googling, installing unofficial/hacked versions of the apks etc) is just evil.
Final update before accepting my answer; although the correct button with the correct styling is now showing in the emulator, I am still not able to get the "pick account" dialog to appear in the emulator. When/if I do I will share the proper solution here.
Check the ldpi, mdpi, hdpi, etc... folders for a different button graphic. Your emulator is almost certainly a different DPI than your device.
i have noticed that from API 21 there are ARM and x86 images with Google APIs implemented
perhaps if you have no problem emulating using android 5 it will works without extracting the APKs
I'm trying to use the OpenGL ES Tracer, but it just doesn't collect any data. I get to the following screen, but the trace file stays emtpy:
I've tried it also with the OpenGLES20Complete example app from Google, to exclude that anything specific to my app is causing this problem, but it just doesn't work.
I'm following the documentation for the OpenGL ES Tracer, except that I'm using IntelliJ IDEA and start the Monitor tool from there. I'm using a Nexus 10 with Android 4.2, so it fulfills the minimum version requirements.
I now also managed to try it on a different device (a Samsung Galaxy i9000 on Cyanogenmod 10), and there the OpenGL tracing works. So there seems to be something specific to the hardware or the OS running on the Android device that disables or enables the tracing.
Are there any further steps or settings I have to take to make this work? What could be the reason why I can't collect any OpenGL traces?
I'd check the output in logcat to see if there is anything suspicious going on. Otherwise, you can try the following from the shell:
$ adb shell
$ am start --opengl-trace com.app.package/com.app.package.Activity
At this point you should see your app launched, but waiting for a connection from the host. You can then use the monitor tool, and in the trace connection dialog, just use the keyword system in lieu of the package name to connect to whatever is running.
Note that your app has to be debuggable.
I believe that it may be a regression with Jelly Bean 4.2.2. I had the same problem on my Galaxy Nexus and Nexus 7, and then I downgraded my Galaxy Nexus to Android 4.1.2 using fastboot and the stock Google ROM and the tracer was working again. I've opened a bug report here: https://code.google.com/p/android/issues/detail?id=53426
Go to the Developer Settings on the device and on the Enable OpenGL traces option select Logcat or Systrace.
I'm new to Android, but have published iphone and bberry apps. I see that I have to create an emulator using the SDK, before I can write and test an app. Why are there no default emulators? Why not at least a Nexus one, or HTC hero emulator shipped with the product?
Sure its supposed to be flexible, but why not make it easy to create hello world and play around with a virtual Android phone? Both blackberry and iphone come with default simulators when you download the sdk.
Thanks,
Gerry
Since you can create an emulator configuration - or Android Virtual Device (AVD) - with three mouse clicks and typing a name I don't see too much wrong with the Android Emulator that ships with the SDK.
The reason that there's no Nexus One or HTC Hero emulator is that these ship with proprietary code which can't be given away free with the emulator.
The Sense UI that comes with the Hero is written by HTC only for their handsets and some of the Google Apps, such as Google Maps, GMail and YouTube are owned by Google and are not part of the Android Open Source Project. I believe Google charge handset makers for these apps and if they included them in the SDK then anyone could have them for free.
The SDK includes emulators for all currently released devices, you just have to create and name them.
To create a "Nexus One" emulator, you would create an AVD that is using the 2.1 SDK, and has a screen size of WVGA800. It's as simple as that.
It used to be this way, but was changed to make developers think about what platform version / configuration they are developing against (and to allow multiple platform AVDs to be created).
Here is a quick way to launch an emulator running cupcake:
$ android create avd -n android1.5 -t
$ emulator -avd android1.5
What about other features.... i would love to make my app work on all android devices but, i dont own all of them, just 1. So i have to create an avd for each possible hardware configuration(phone). meaning i have to track down the exact specs for say 5-10 phones? resultion, density, aspect ratio, input types, multi touch? proccessor FPU? some do some dont. etc etc. something needs done.
I'm confused by your question. The SDK ships with an emulator. You just have to create and configure an instance of it first through the SDK and AVD manager.
You can create appropriate avd using android (android.bat) in folder /tools of sdk. Also you can choose resolution, sd card, API level. It's really easy:)
If you want to write for Nexus - why not? Choose appropriate sdk level and enjoy.