What do you need help with?

Optimizing Applications on ODG Glasses


It is commonly reported that processor CPU, GPU and resource intensive Apps tend to heat up the glasses, especially when the glasses are charging from a Power Hub battery. If all compute elements are pegged, it is possible to raise the surface temperature of the glasses ~ 30 C over the ambient temperature.

We know that if the glasses are charging and running a lot of processing, they will heat up. It is unfortunately a matter of thermodynamics; the glasses have only a small surface area to diffuse ~ 5-6 Watts of power when they are running flat out. We have the ability to throttle down the CPUs clock rate based on temperature, and we do that now, but only to protect the hardware, and to maintain a max 35 C temp differential touch temperature from ambient. We have considered changing levels to begin throttling back sooner, but then all Apps would not get the cycles they need during peak periods, and would be less performant, so it is a trade off. Better for Applications to tune themselves and throttle as necessary. it's always important for the App developer to do the best they can in profiling and optimizing their App, and then also consider throttling at the App level to achieve certain runtime or heat level objectives they might have; they should consider adjusting frame rate, or eliminate certain algorithms or features under certain circumstances. 

Usually the best approach is to try and optimize the application. Many times, Apps are built using engines like Unity that are running a virtual machine (Unity runs a derivative of Mono) which are flexible, but inherently inefficient. Codecs and image processing are the other usual areas which do heavy processing.

For this reason, it is good to know which audio & video codec(s) your App is using. Depending on if there's an alternative to pick one that is hardware based, that can reduce the heat.  This reference lists all the codecs available in Android, by version: 


But you can't tell which are H/W based; It is up to each ODM to map the features of their CPU codecs.
This tool will allow you to check which codecs are H/W based, and which are S/W based:
There are more H/W based decoders, but for video encoding, there are only 3. Changing your Application to use one of these to stream your video should make it more efficient. Changing to H.264 would help.
Running the Media Codec Info App on R-7 MM OS, you will see the follow video encoders:
  • MPEG-4 AVC (H.264)
  • MPEG-4 Visual
  • 3GP
The codecs listed as qcom are the hardware codecs; these are the 3 video encoders it finds:
  • OMX.qcom.video.encoder.avc (type video/avc)
  • OMX.qcom.video.encoder.mpeg4 (type video/mp4v-es)
  • OMX.qcom.video.encoder.h263 (type video/3gpp)
I've attached the App mentioned above so you can see the other google (SW) encoders listed, and all the decoders, both Qualcomm and Google.

WebRTC is a component that can be configurable, and is most likely using a software based codec (VP8 perhaps?), which are using cycles which may not show up when you look at the CPU load. One thing to investigate is the codecs in use and if you can switch to one that is implemented in hardware on the Snapdragon version in your glasses. HW encoding for VP8 is not available on the 805 (R-7). Attached another different App that can be run on the R-7 and it will give you a list of all supported encoders and decoders.

We also know there are areas in the system that are known to be not currently (KitKat) optimized well, particularly around the use of the camera. The CPU utilization you are seeing is what we typically see. One offender, mm-qcamera-daemon is qualcomm proprietary process that includes the camera server, media control, sensor drivers etc. All qualcomm proprietary solutions run as linux daemons. We do have the sources for the mm-camera, but we've made no changes to it. Only drivers have been adapted for our platform. Changes made post KitKat are including in the current update the R-7 - Android 6 / Marshmallow; the current plan has us releasing at least one more MM release with some bug fixes and enhancements. Note that we are pretty unlikely to do any optimization of the KitKat implementation.

We certainly will continue to look at performance. But, know that we are also updating our line of glasses to the best CPUs available from Qualcomm, and so we will have the best performance possible in a mobile device, and transitioning to Android N & O, which will have many improvements. Our devices where the first to have the 835. We hope to have early access to the next version as well.


Optimization Checklist:

Most developers probably already know and have looked at these, but some of the things to check:

  1. Can you turn down your camera frame rate without effecting performance below a satisfactory level?
  2. Is your image processing per frame open ended? Can it be optimized, or throttled at least, again without effecting performance below a satisfactory level?
  3. Is your GPU rendering as optimized as possible?
  4. Can you reduce the display brightness within your use case (not advised unless your use case has very static lighting conditions).
  5. As the device heats up and crosses a temp threshold, it will clock down; does this make your App thrash and be even less efficient?

Profiling tools vary, providing a view at the Linux process or application thread level.  We did see this one recently advertised:



To view Linux level process utilization, adb shell into the glasses, and you should be able to use top to get a Linux level process activity snapshot.


130|shell@apq8084:/ $ top -?

Usage: top [ -m max_procs ] [ -n iterations ] [ -d delay ] [ -s sort_column ] [ -t ] [ -h ]

   -m num  Maximum number of processes to display.

   -n num  Updates to show before exiting.

   -d num  Seconds to wait between updates.

   -s col  Column to sort by (cpu,vss,rss,thr).

   -t      Show threads instead of processes.

   -h      Display this help screen.

Have more questions? Submit a request


Powered by Zendesk