When it comes to Android kernels, the number one topic of discussion these days is battery life. But there are many myths about the relationship between kernel and battery life. At one extreme, there are those who make outrageous claims about radical changes to battery life minutes or hours after installing a kernel. At the other extreme are those who think the kernel makes absolutely no difference at all to battery life. The truth lies somewhere in the middle.

Before we get to the “truth” of the matter, I want to clarify a few things.

First, the kernel does not “drain” battery. Many times, a user installs a kernel and then reports back soon after that the kernel has caused massive battery drain (and probably also something to the effect that the kernel is crap and the dev should burn in hell for his efforts). To prove it, they post screenshots from battery monitoring apps showing “kernel” as the major source of drain. This is very misleading. On Android devices, the kernel provides a mechanism for keeping the phone awake, called a wakelock. Processes running on the device (e.g. apps and services) can ask the kernel for a wakelock, and the kernel will oblige. So yes, the kernel is technically keeping the phone awake, but only because an app or service has asked it to. It is these apps and services that are misbehaving and causing drain, not the kernel.

But that is not to say the kernel does not cause any battery drain. It still uses memory and does work, but the amount it uses is exceedingly small compared to the Android system, apps and services. There are also special hardware cases, such as the sweep2wake feature on the Nexus 5, which requires that the LCD panel remain powered on in order to work. This drains more battery than if the device were suspended normally, but still does not cause “massive” drain. On the Nexus 5, sweep2wake adds roughly 2% per hour drain while the screen is off. Not insignificant, but far less than the phone normally uses while the screen is on. Because of this, a strong myth has developed, claiming that sweep2wake and doubletap2wake cause battery drain. Except for the Nexus 5, it is just that, a myth. On the vast majority of devices, the battery drain from sweep2wake is negligible, usually something zero and 0.5% per hour, which would “cost” no more than 5% battery usage over the course of a workday. A perfectly acceptable trade-off for the convenience.

The second thing I want to clarify pertains to measurement. How do we measure battery life? I like to look at percent usage per hour. Many battery monitoring apps can give you this statistic, but you have to pay attention and set custom time points if you want to distinguish the stats further and really understand battery usage. If you do want to measure and compare, make sure you do so under similar conditions. And you must do so over a reasonable time period, which means days rather than hours. If you have some routines where you use the same apps every day, this would be a good way to test and compare. The battery monitor in EX Kernel Manager automatically provides the two statistics I will now talk about: idle drain and active drain.

Idle drain is battery drain while the screen is off. During screen off, the phone spends most of its time in “deep sleep”. Sometimes, it wakes up to do some background work, like syncing email or checking for updates. These would be examples of the system, apps or services “asking” the kernel to stay awake while they perform their tasks. If all is working correctly, when they finish, the device goes back to sleep. Idle drain should be measured over several hours to get an accurate picture. A good time to measure it is overnight while you aren’t using your device (if you are not a dev and actually get to sleep). On most devices, idle drain ranges from about 0.2% per hour to 0.8% per hour on a stock setup with default options (i.e., with no battery saving measures in place) on a normal WiFi connection. On some devices, kernel optimizations can shave a bit off this number. But only a tiny bit, generally in the range of 0.1% to 0.3% improvement over stock. This is not going to make a huge difference to battery life. As already mentioned, sometimes hardware features like sweep2wake can eat up about the same amount. So as we can see, a kernel offers relatively little improvement here, but then again, every bit counts. Another factor that influences idle drain is your network connection, particularly cellular connection. A poor signal will often result in a bit of extra drain. But this should not cause excessive drain during idle, and will mostly make a difference while you are using the data connection. I should add that many of the battery saving measures people take also make little difference here. As long as your idle drain is below 1% per hour, don’t even worry about it. If it’s more than 1% per hour, look at your apps and services. Occasionally, there will be a big batch of updates that cause a bit of extra drain. It happens.

Active drain is the amount of battery used while the screen is on. That is, while you are using your device. Active drain is obviously much greater than idle drain. The phone is on, the screen is on, and it is doing work using the CPU, GPU, memory, modem, wifi, disk, etc. Active drain varies quite a bit from device to device. A lot of times we hear about “screen-on time”. Active drain, measured in % per hour can be translated easily into screen-on time. Active drain of 12.5% per hour is extremely good and will equate to about 8 hours of screen time. Drain of 25% per hour will get you about 4 hours of screen time. See how that works?

Screen-on time (hours) = 100 / Active drain (% per hour)

This does not take into account the small amount of battery use while the screen is off. Assuming idle drain is about 0.6% per hour, you would lose about 6% in ten hours, or around 14% in a 24 hour period. You can subtract that from 100 in the equation above.

Now we’re getting into the truth of the matter. What influences active drain? Many
things. Network (especially cellular) connection makes a difference. Poor signal means it has to work harder to transmit and receive data. The type of apps you are using makes a difference. Obviously playing a graphics-intensive game will use far more battery than reading some email. Using the camera, especially flash, will cause more drain than texting. The point is, what you do with your device has, by far, the biggest influence on battery life. Something like changing your web browser could have a significant impact on battery life, perhaps a greater impact than any kernel or battery saving tweaks floating around on the Internet. Bottom line: Active drain will vary from user to user, even with the same device!

There is, however, one part of the kernel that has a significant influence on active drain, and therefore can have a big impact on screen-on time. This is the CPU governor. This is why kernel developers spend a lot of time tweaking governors. It’s about frequency usage, which you can measure with an app like CPU Times. The CPU governor controls frequency scaling according to system load. While not busy, the CPU will stay at its lowest frequency, which uses the least energy. When there is work to do, the CPU governor ramps up the frequency so the work can be completed faster and the user can enjoy a smooth experience. A good governor is responsive, quickly responding to changes in system load, to prevent lag, but also quickly returning to the lowest frequency to save energy.

There is an idea called “race to idle” which suggests the governor should immediately ramp up to the highest frequency so tasks can be completed as quickly as possible, and consequently, the CPU can more quickly return to a lower power state. This logic is generally sound, but with modern processors, there may be a negligible time difference for completing a task using the highest frequency available compared to a frequency somewhere in the middle. In other words, it may be a waste of energy to ramp up to the highest frequency when a somewhat lower frequency may complete the task in essentially the same amount of time, and return to an idle state. The highest frequency will use more energy than the moderate frequency, and there may be very real battery savings when this is repeated thousands or millions of times per day. The trick is to find frequencies that are “fast enough” to create a feeling of snappiness for the user, without constantly ramping up to the highest frequency. I could write a whole other essay on governors, so for now I will leave it at that. It will suffice to say that different governors will behave differently, and have different battery use characteristics. Therefore, the kernel really does have an impact on battery life.

There are other aspects of the kernel that impact battery life too. Chief among these is task scheduling, particularly the aspect where tasks are assigned to one CPU core or another. This means a CPU may be “woken up” to perform a task, or tasks may be packed onto the same core. Another is hotplugging. There is an energy cost to put CPU cores on or offline. On many devices, you will hear about the evils of mpdecision, a closed-source binary from Qualcomm that controls hotplugging and often includes a “touchboost” feature that overrides the CPU governor. Many custom kernels disable mpdecision and implement a custom hotplugging driver. My own testing has found that mpdecision and its excessive touchboosting generally do not have a major impact on battery life, and I have left it enabled in most of my kernels. In some recent devices, such as the Nexus 6 and the HTC One m9, there is no hotplugging during normal use. All CPU cores are online. It can’t be said that task scheduling, hotplugging and touchboost have no impact on battery life. They clearly do. It’s just not going to make a huge difference. If we think of the impact of these optimizations in terms of active drain (% per hour), the change will be relatively small, probably less than one percent per hour, which would be measured in minutes of screen-on time over the course of a day. I think the impact of these optimizations is more apparent on older devices that are less power efficient and have smaller batteries.

I will mention quickly one more topic that always comes up in discussions of battery life: undervolting. Again, undervolting probably made a bigger difference on older devices. Devices released in the past year or two have become considerably more power efficient, some even have automatic fine tuning and scaling of voltages. I remember working on msm8960 devices that used the same voltage for every CPU frequency. In a case like that, undervolting could make quite a difference. Recent devices run with much lower voltages, and chips are binned with tighter tolerances, leaving less headroom for undervolting and reducing the battery impact of undervolting. On some devices I offered automatic undervolting, but only for the lowest frequency, which is the most-used frequency.

Much more could be said on this topic, but the main point I wanted to make is that the kernel does, indeed, make a difference in battery life, but the difference is often not as dramatic as some like to think. From the kernel’s perspective, the CPU governor will have the biggest impact on battery life. Many of the things that people obsess about do not make a big difference in battery life. Finally, if you want to judge battery life, take a scientific approach. Try to use the same conditions when making comparisons, measure carefully, and give it some time.

- flar2

This article was originally posted by its author on elementalx.org and Android Revolution blog has been given a permission to re-publish the article.

Do you have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

For latest news follow Android Revolution HD on popular social platforms:

Read More..

The activity is the core of an android application. Each application can have one or more activities.

In this post we are going to explore the activity’s life cycle and understand the event handler of each stage through the activity’s life cycle.

Activities in the system are managed in an activity stack (Last in Last out). When a new activity is launched it becomes on the top of the stack. Any previous activity will be below it and won’t come to the top until the new one exists.

The application on the top of the stack has the highest priority from the operating system. While the activity that is not visible has lower priority even if the a running activity requires more memory, the system can shut down that activity to free memory.

Android runs each activity in a separate process each of which hosts a separate virtual machine. Android saves metadata (state) of each activity so that when a new activity launches so that it can come back to the activity when the user backtracks.

The activity can be in one of four states:

Active: the activity started, is running and is in the foreground.

Paused: the activity is running and visible but another activity (non full sized) is running on the top or a notification is displayed. The user can see the activity but can not interact with it. A paused activity is fully alive (maintains state and member information) but can be killed by the system in low memory situations.

Stopped: the activity is running but invisible because the user has launched another activity that comes to the foreground the activity is alive (maintains state and member information) but can be killed by the system in low memory situations.

Dead: either the activity is not started or it was in pause or stop state and was terminated by the system to free some memory or by asking the user to do so.

The following figure shows the states of the activity and the methods that handle each state


The sequence is as follows:

• The activity starts, passes through onCreate(), onStart() the activity is still not visible to the user, onResume() then it comes to the foreground and becomes fully running.
• If another activity launches or a notification appears the activity passes through the onPause() method. Then there would be two scenarios:
  1.if the system decides to kill your activity due to low memory the activity starts the cycle again from onCreate() method with Bundle savedInstanceState parameter that holds data about the previous state of the activity.
  2.If the user resumes the activity by closing the new activity or the notification the activity cycle continues from the onResume() method
  
  

• When the user is about to close the activity the activity calls onStop() method then onDestroy() method when the system destroys the activity.
  But if another activity runs while the current one is was not shut, the activity calles onStop() method and if it is not killed by the system it will call onRestart() method then onStart() mehod and continues the cycle.
  
  
• onCreate(): will be invoked in three cases:
  - the activity runs for the first time and it will be invoked with null Bundle savedInstanceState parameter.
  - the activity has been running then stopped by the user or destroyed by the system then it would be invoked with Bundle savedInstanceState that holds the previous state of the activity.
  - the activity is running and you set the device to different resources like Portrait vs landscape, then the activity will be recreated.
  
  in this method you will create the user interface, bind data to controls and register the event handlers for the controls. Then it is followed by onStart() method.
  
  
• onStart(): will be invoked when the activity is first launched or brought back to the foreground
  it would be followed by onResume() if the activity continues and comes to foreground, or by onStop() if the activity is killed.
• onRestart(): is invoked in case the activity has been stopped and is about to be run again. Always followed by onStart() mehod.
• onResume(); invoked when the activity is about to come to the foreground and is on the top of the activity stack. It is the place where you can refresh the controls if the activity is using a service that displays some feeds or news. Always followed by onPause() method.
• onPause(): is invoked when another activity launches while the current activity is launched or when the system decides to kill the activity. In this method you have to cancel everything you did in onResume() method like Stopping threads, stopping animations or clearing usage of resources(eg the camera).
  
  This method is followed by onResume() if the activity returns back to front or by onStop() if the activity is to be invisible.
• onStop(): is invoked when a new activity is about to come over the current one or the current one is to be destroyed. Always followed by onResume() if the activity comes back or onDestroy if the activity is to be killed.
• onDestroy():is invoked when the activity is shutting down because the activity called finish() [terminated the activity] or because the system needs memory so it decided to kill the activity.

Killable methods:


There are methods that are “killable” meaning that after theses methods return, the process hosting them can kill the activity without executing any further code (due to lack of memory)


These methods are onPause(), onStop() and onDestroy()

Summary

• The entire activity life cycle is between the onCreate() where you construct the UI and aquire resources and onDestroy() method where you release all resources.
• The visible life time of the activity is between onStart() and onStop(). Between the activity is visible to the user although he may be unable to interact with it. Between the two methods you persist the state of the activity so that if another one comes to the foreground then comes back to the original activity you find the state persisted.
• The foreground lifetime is between the onResume() and on Pause(). During this time the activity is fully interactive with the user. The activity can go through the resume and pause states many times (if the device sleeps or a new activity launches) so the code should be very lightweight.

Read More..

Posted by LeVar Burton

(Cross-posted on the Google for Education Blog.)

Editors note: Through his work with Reading Rainbow, LeVar Burton continues to inspire generations of students to love reading. Getting an early start on celebrating Teacher Appreciation Week, we asked LeVar about educators that inspired him. He shares some stories from his childhood in today’s guest post, and he’ll share more during his keynote, “The power of storytelling to inspire students,” during our Education on Air conference. Register today and tune in for LeVar’s talk on May 8th at 11:15am ET.

Teachers seem to run in my family. My elder sister, my son and two nieces are all educators, and my mother, Erma Gene Christian, was a high school English teacher before becoming my first teacher. I know firsthand how hard these unsung heroes work, and especially how important a teacher can be in a child’s life.

One of the most indelible memories from my childhood happened one day when I was learning to read. My favorite aunt Hope, my mother’s youngest sister, was visiting from Kansas City. We were sitting together in a chair in the living room and I was reading aloud while my mother listened from the kitchen where she was preparing a family meal. Things were going fine until I got stuck on a word. I stopped cold in the middle of a sentence. The word was one I thought I knew, but I didn’t yet have the inner confidence to know that I could read it. I will never forget the infinite patience that Aunt Hope displayed and the gentle nudges of support she gave me. “Go on,” she’d whisper, “You know this word. I know you can sound it out.”

I still remember the word —it was “pretty” — and when my aunt finally said the word to me it was a revelation. She gave me the confidence I needed to trust myself; to trust that I did know these words. I was a reader. This is what teachers do for their students every day.

It’s from my mother, Erma Gene, that I learned the allure of storytelling. Throughout my childhood, mom always had several books going simultaneously, switching from one to the other seamlessly, deriving pleasure from each turn of the page, no matter what the genre. I learned from my mom—and eventually from my own experiences reading, and from exposing children to the joy of books through Reading Rainbow—that storytelling is an elemental part of the human experience, regardless of whether the medium is a print book or a digital book. We know that kids are reading more than 200,000 books a week on the Reading Rainbow App. They are using their devices not just for games or movies, but to read.

Heres me with the first educator who inspired me, my mother.

Children are drawn to stories, and with good storytelling we can teach kids anything. I have seen the light go on in a child’s eyes when he or she falls in love with a story. I’ve seen that light get brighter when they realize that they can read the stories for themselves. This light is the beginning of a lifelong love of reading, and from there a lifelong love of learning. For me, literacy means freedom, and literacy begins with storytelling. You get a child’s attention when you give them a good story. If we fail to take advantage of this, we are letting the opportunity of a lifetime—of our lifetime and theirs—pass us by.

Hear more about the power of storytelling from LeVar Burton during his Education on Air keynote on May 8 at 11:15am ET or check out his Reading Rainbow website.

Read More..