I'm working in my thesis, and I need to explore the google Android API to find a way to get every possible information about the CPU and Battery (like CPU temperature, % of usage, battery level, energy consumption, ...).
The idea is measuring, in 2 or more different execution times, the energy consumed by an Android APP, and get details on what was used by the APP to spend that energy.
Does anyone know any API from Android to measure this kind of things?
For getting battery level, you can register an Intent for ACTION_BATTERY_CHANGED. For more information refer to the Android Battery API. If you just want to get the battery temperature, you can get it using the API itself. I think Android does not have an API for CPU temperature.
However, you can read the temperature from /sys/class/thermal/thermal_zone0/temp
This is the way to get temperature on linux based systems and since Android is Unix based, I think you should be able to do it. I haven't tried it myself though
Take a look at Monitoring the Battery Level and Charging State guide. Concerning CPU, you should be able to collect some data from Systrace.
Related
I need to write a few cpu-intensive Android applications. One I have already coded is a BigInteger factorial but it consumes totally around 30-40% of my cellphone cpu. My phone is hexa-core and the cpu-usage is about 5% kernel and 30% user. Is this enough for a cpu intensive application or should the percentage be very high like 80-90%? It also consumes about 120MB memory out of the available 260MB. Is that fine or it must be very low?
Hmmm. This is both a straightforward question and a tricky question. First off, 30%-40% is not that CPU intensive; actually, it's pretty wimpy. I'm guessing that one of two things is happening: (1) your application isn't running enough threads to keep all the cores fat and happy, or (2) the OS has some built in governors to keep any given app from dragging down the phone, making it pretty much useless and giving the manufacturer a very bad name. (By the way, I don't know if the developers implement (2) or not. If I was the designer, I would.)
Is your app an android compliant Java application? Or are you running closer to the metal?
I have been trying to figure this out since couple months ago because I'm working on my thesis, but unfortunately I have not been able to make it. What I'm doing is a performance analysis regarding energy consumed by an application running an algorithm locally on the phone and the same app but running the algorithm on the cloud and getting the response back to the phone. What I want to do is to try to find an accurate way to obtain the energy consumed by this algorithm since it's executed until it gets the solution (locally and remotely).
Is there any way that I can use in java to do it by using the Android API? I would like to write my own code to get the measures. Please anything you guys think it is helpful PLEASE, let me know... I appreciate your time and patience,
Alberto.
I am not sure if there is such an API available. Here is a link with similar discussion. If you want because energy/battery consumption depends on may other factors including the efficiency of the compiler.
First of all, I am not asking "is it OK if I totally forget about efficiency when writing an application for a Google TV". I would never do that! :)
But I'm still curious: what are the differences between developing something for a Google TV and a mobile device such as a tablet/handset? I have found a lot of information online about the differences in user interface design (i.e. TV is meant to be more social, no screen orientations, no touchscreen, etc.) but none of the documentation describes the hardware-specific differences between the two devices. To be more specific,
Considering that Android was originally designed for mobile devices with limited memory, is designing an application for a Google TV any different?
Phones and tablets don't have the luxury of swap space and therefore there are hard limits on memory... is this also the case with a Google TV?
The Dalvik VM is optimized for minimal memory footprint on handsets/tablets... is Google TV powered by the exact same VM, a slightly different version designed specifically for the Google TV (but with the same design goals in mind), or a completely different VM (with different design goals in mind)?
What are the actual differences in hardware when comparing a handset/tablet and a Google TV? Are these differences significant?
Does Ice Cream Sandwich and Jelly Bean improve performance in any way (i.e. does it make use of these new hardware capabilities?)
I have a Logitech Revue and it is certainly not a speedy device; I would hope that developers pay attention to performance when targeting it.
According to this forum link, these are the specs for the Revue:
Intel Atom CE4150 1.2 GHz processor, with a 400 MHz GPU
Gigabyte GA-SBKAN2 motherboard
Samsung K9F8G08U0M 1 GB NAND Flash (Single Level Cell) Datasheet Mirror
Hynix H27UBG8T2ATR 4 GB NAND Flash (Multiple Level Cell) Datasheet
Silicon Image Sil9135 HDMI 1.3 Receiver Chip Information Datasheet from TI
Nanya NT5CB128M8CN-CG 1 GB DDR3 SDRAM (1 Gb X 8) Datasheet
Realtek Semiconductor RTL8201N 10/100M PHYceiver Datasheet
Microchip PIC24FJ64GA004-I/PT 16-bit microcontroller Datasheet
Phison S2251-50 USB to Flash Controller (Datasheet not available to end users according to manufacture)
IDT ICS9LPRS525AGLF Clock for CPU Datasheet
Samsung K9F8G08U0M 1 GB NAND Flash
Used for storage of bootloader, kernel, boot flash graphics, Linux OS etc..
Hynix H27UBG8T2ATR
4 GB NAND Flash (Long Term Storage)
Used for persistent storage, device is /dev/sda - possible to override with an external USB drive
Microchip PIC24FJ64GA004-I/PT 16-bit microcontroller
Used to handle IR input/output for remotes/IR blasters and possible interface with wireless keyboard
System reboot/powerdown
Possibly HDMI CEC
Silicon Image Sil9135 HDMI 1.3 Receiver
Used to process video to and from HDMI ports as well as audio over HDMI and SPDIF
Supports DTS even though the Revue does not (An update can probably enable this feature)
IDT ICS9LPRS525AGLF Clock for CPU
Provides a clock for the Intel Atom CPU
Considering that Android was originally designed for mobile devices
with limited memory, is designing an application for a Google TV any
different?
Fundamentally, no. These devices can exist in their form because they are using a mobile OS and so can run on less expensive hardware. The CPU may be around the performance of current mid-level phones; as far as I can tell the GPU is much lower performance (especially given the screen resolution it is driving) then currently typical on phones.
Also, the next generation Google TV devices that have been announced are ARM-based, so expect them to be much more similar in performance.
Phones and tablets don't have the luxury of swap space and therefore
there are hard limits on memory... is this also the case with a Google
TV?
Yes, this is how Android is designed to operate. I don't know off-hand how much RAM is in the current GoogleTV devices, but I doubt it is more than what you are seeing on current Android tablets (1 GB). As always you can use ActivityManager.getMemoryClass() and ActivityManager.getLargeMemoryClass() to find out the memory situation of the device you are running on.
The Dalvik VM is optimized for minimal memory footprint on
handsets/tablets... is Google TV powered by the exact same VM, a
slightly different version designed specifically for the Google TV
(but with the same design goals in mind), or a completely different VM
(with different design goals in mind)?
It's the exact same VM, just running on x86.
What are the actual differences in hardware when comparing a
handset/tablet and a Google TV? Are these differences significant?
There are a number of obvious things:
Input is primarily through DPAD interaction, so you want to implement your app so that interaction with the DPAD works well. Android has always supported fairly complete interaction with the DPAD, so this is not really anything new, just a part of application design that current mobile-oriented developers often let slide. (However it is good to support the DPAD correctly for more than just GTV, it is also important for things like the Asus Transformer when the user is interacting with a keyboard.)
There are no sensors like an accelerometer, etc. You can use the platform APIs like PackageManager.hasSystemFeature() to find out whether a hardware feature exists, or declare the requirement for the feature in your manifest so the app is not available on such devices.
These devices can't rotate, so you will need to work in a landscape screen.
Of course the screen you will be running on is larger than a typical phone screen, but with Android's support for tablets you have a lot of tools (such as fragments) available to adjust to take advantage of the screen. Especially now that you can assume that these devices are running 3.x or later, all of the infrastructure introduced in the platform for tablets is available.
There is also a lengthy document on UI design for GoogleTV at https://developers.google.com/tv/android/docs/gtv_android_patterns that has a lot of good material on how to think about your UI on a TV. There are many specifics on the UI design of GoogleTV; I would suggest you pay a lot of attention to the overall points (the space available for UI is not that much more than a phone, don't design your UI around mouse-like interaction, etc) and then decide what makes sense for you how much you are just going to present your phone/tablet UI on the TV vs. doing something more customized to follow the GoogleTV guidelines. As long as you follow the basics with a UI that works well with DPAD navigation and such, I think you will be good.
What you are noticing is something that has been around for a while. Somebody somewhere decided to call it the "10 Foot UI" when XBMC was the way to do all this. Generally speaking, yes, the user experience is much different on a shared device that you cannot or would not be touching, versus a personal device you would be touching quite a bit. On a handheld device, user interefaces tend to be "through the looking glass" types of things. Things that you can interact with and manipulate directly. On a 10-foot ui, things tend to be bigger, simpler, and friendlier to indirectly manipulate with something as wonky as a classic 0-9 remote.
I am working on an app and it is almost finished except only one thing: I don't know how to get link speed and place it in the status bar.I am new to Java so if somebody could help me I would be very grateful.
P.S. Sorry for bad English.
As the repliers suggest, your question is not very clear. You could be referring to the link connection speed (i.e up to 54 Mbps with good signal reception Wifi or up to 7.2 Mbps with full speed HSDPA) which depends on:
The network interface you are using at a time. Some phones allow tethering which means you can have both Wifi and Mobile Data Link (GPRS/3G/HSDPA) active at the same time, or on automatic switch (if your Wifi connection drops your phone will switch to Mobile network automatically if activated).
The connection speed negotiated at a time. Depending on signal quality/carrier network configuration (some have max. speed limited)/mobile data contract (monthly bandwith quota exceeded normally means defaulting to GPRS speed).
In this case I am afraid there is no standard Java API methods to know it, but the Android API the needed functionality:
For WiFi link speed check WifiInfo.getLinkSpeed()
For Mobile Data Link I am afraid that you can only check TelefonyManager.getNetworkType() to determine the current Mobile Data Link type. You should then aproximate to actual speed by link type (i.e. for GPRS up to 128 kbps, for EDGE up to 236.8 kpbs, for 3G up to 2 Mbps, for HSDPA up to 7.2 Mbps). Take into consideration that this is only an aproximation. Your could be conneting using HSDPA but your carrier limiting the top speed to 2 Mbps.
In the other case that you refer the current (Download/Upload) data link speed this is only available at a high level, actually measuring not the link speed but the speed between your phone and a server, which can be determinted not only by your link speed but also by many other factors (all the links between your phone an server, the server itself, etc.). You could just measure "HTTP level speed" which means HTTP data speed (leaving out overhead traffic for data packets), since normally only HTTP connections are supported in every scenario (your carrier could be hiding you behind a proxy that filters everything out but HTTP traffic).
If you are using 8 level API an interesting feature called TrafficStats is also available. This lets you know the sent/received packets at a low level exchanged by your phone over the Mobile Data Link, which may offer just the information you where looking for (use these measurements with elapsed times and you can easily measure current/average used data link speed).
You cannot tell directly. You must ask the underlying operating system. For OS X you can parse the output from "/sbin/ifconfig" on the appropriate network port.
You can also write extension using JNI, and ask connection speed using C. It's just in case if you don't want to parse output from other application, but please keep in mind that this solution isn't portable.
I am having trouble finding a class or API in Android documentation that would help me get battery usage statistics per application.
I have read PowerManager and BatteryManager classes but they are of no use.
However, I can find applications like PowerTutor that do provide battery usage statistics per application, so I think it's technically possible.
Can any one point me in right direction?
I'd be surprised if such an API exists. Rather, I expect that PowerTutor is using some sampling heuristics to estimate how much of the current battery usage to blame on each application.