February 8, 2012 By: Joseph Hindy
It is a rare feat when someone goes out of their way to truly study their device. It is rarer still when that study warrants relevant information that’s beneficial to other users.
XDA Senior Member bedalus has performed what amounts to a case study to test battery usage with a variety of kernels and battery features such as under-volting and various levels of idling for the Samsung Nexus S. The study is rather extensive and tests the phone under a variety of conditions such as screen on/off, while music is playing, with different governors and even CPU Clock frequency. Of course, bedalus wanted to make a special note. Do NOT try this at home, it could be very damaging to your Nexus S.
The results were rather startling. As it turns out, many of those techniques and features that many people use don’t actually work. Says bedalus:
The main shock was that Deep Idle did not work as intended. There are three forms of Deep Idle: the CPU Idle backport from kernel 3.2, Eugene’s Deep Idle, and Ezekeel’s. All three were tested, and no battery saving was measured. I also tested Deep Idle in Carbon (Jonathon Grigg’s ICS themed Oxygen 2.3.1, android version 2.3.7, gingerbread) using Ezekeel’s last kernel for gingerbread, and that showed no battery saving either. With the option for ‘Screen Off Maximum Frequency’ set to ON, the battery drain was higher (both in ICS and GB).
What that basically says is, with all respect to the developers who worked hard on these features, that none of these features actually help the battery. For all intents and purposes, a user might as well not have them. This has a number implications, but none more important than giving said developers statistics with which to base their next release. Why continue working on something that has been proven not work? Or, perhaps the better question, is that is there a way to make these features work better against the stock settings?
Please note that just because one feature on a kernel/ROM/mod doesn’t work doesn’t make that piece of work bad, it just means there’s a feature that doesn’t work. At least they don’t cause higher battery drain. In the poll posted in the thread, voters have shown that they do save power with the Deep Idle. However, there are variables that cannot be measured, such as what each user has otherwise installed and how they use their phone, so it’s worth taking note but does not disprove the research.
Continuing on his observations, bedalus also noted:
If you use NStools to undervolt, don’t bother. No gain to be had from undervolting either ARM or INT voltages. I tested this to the extreme. Check the spreadsheet, near the bottom. (Tested in both ICS and GB).
So that puts that to rest. Much like Deep Idle, there are users who claim undervolting saves them battery. However, the numbers are pretty clear that it doesn’t, so it can be assumed that, once again, there are other variables at work such as apps running and how the user actually uses their device.
This leads us to observation number three, as bedalus says:
The other main result was that mathkid95′s matr1x kernel offered the greatest battery saving. However, it should be noted that I have suffered reboots while performing other benchmarks on this kernel, and the solution was to raise voltages. (It’s not as if doing that is going to drain your battery faster.)
If you were looking for a kernel that saves battery, then this one is it. XDA Recognized Developer mathkid95‘s kernel has shown, by way of statistics, that is does, in fact, have the highest battery saving. Of course, battery saving isn’t the only reason users choose a kernel. Some may want performance, others stability, but for those who need that extra battery capacity then mathkid95′s is the one that survived all the testing.
And the final observation made by bedalus:
If you have an AMOLED display, black saves the most power, then red.
This is something that many users could have already guessed, as black has been the go to color for battery saving for a long time. However, it’s nice to finally have some numbers to put to the belief. And to those running black and red themes, bet you never thought that theme was saving your battery did you?
All of these observations are backed up with a very impressive and easy to read spreadsheet. It’s a Google Documents spreadsheet, so be sure you’re logged in to Google before attempting to view it, as it will probably alleviate any problems, but if you have five minutes then it’s highly recommended you check out the original spreadsheet. There is a boat load of useful information in there and shows all the results that bedalus has come up with and all the mentioned, and unmentioned, parameters he tested. This also includes Quadrant Standard and AnTuTu benchmark tests.
Along with the spreadsheet and detailed explanation, bedalus was also kind enough to post two videos showing users exactly how he tested these processes and how he read the results. This not only proves he actually did the research, as opposed to blowing smoke, but also gives the experts and average users alike a chance to see how it was done. In an internet community, if you don’t post a screen shot, it didn’t happen. For bedalus, he posted videos, that’s a step up.
For anyone who wants to read the full coverage of the Nexus S battery consumption research, they can do so in the original thread. The first couple of posts explain the parameters of the testing and the conclusions. Post three covers how he tested the battery, including hardware specifications and how/why he did what he did. Post four includes further explanation for test methods and plans for future testing.
The best part about bedalus’ work is that there is a plan to continue testing using better equipment and more parameters. So it is definitely worth it to keep tabs on the thread as there will eventually be more, not to mention more accurate, information to be had.
And, as bedalus will have you note:
REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.
February 3, 2012 By: Ian Stacy
If you have a phone with an NFC chip and aren’t using Google Wallet, now’s your chance. Check out this thread for reports of working NFC payment locations.
January 31, 2012 By: orb3000
Koush, a well-known developer, just released the beta of his new Touch Recovery. Finally no more volume up, volume down, power button to control what you want in the dark screens of recovery world. Just boot, tap and flash it!. For now the recovery works only on CDMA and GSM for the Galaxy Nexus, and GSM for the Nexus S. Also some members confirmed it works on the Nexus S 4G as well.
The recovery has to be flashed from fast boot, so be sure you’ve got your ADB drivers all lined up and your device installed correctly before proceeding. Here you can see a video of how it works.
Despite the beta is only available for a select few devices, we expect to see it soon for more devices. Until then, we still have to use the “old” one.
Download links on the source
January 25, 2012 By: Joseph Hindy
Modifications and tweaks are the spine on the book of the underground Android development community. Without them, a ROM is just a ROM and a kernel is just a kernel. With them, they become unique pieces of one of a kind work that people can truly enjoy.
It is in the spirit of sharing that XDA Recognized Developer brainmaster has released his collection of ClockworkMod flashable tweaks for the Samsung Nexus S and they are compatible with all Android Ice Cream Sandwich ROMs.
The tweaks cover a range of things, from RAM optimization to build.prop modifications and there’s well over half a dozen easily flashable tweaks in all.
Of course, as with flashing any tweaks, there is the disclaimer. As brainmaster writers:
ALWAYS make a NANDroid Backup of your current ROM so that you can go back if you don’t like the tweaks.
I will NOT reply any users PM’s regarding this thread or my ROMs, only the DEVs should contact me over PM.
If you are user and have questions, write HERE in the thread.
BEFORE asking any questions, make sure that you read this post.
So if you have a Nexus S and want to give it a little extra bump in its step, then you can check out the whole collection of tweaks with details on what they do along with download links in the original thread.
There is a new ROM that’s looking to make that very exclusive “all phones must have it” list. Say hello to DianXin OS, or DX OS as it’s being referred to. As XDA Senior Member qtwrk will tell you:
i know you guys may think it looks like MIUI , but i asure you it’s totally different ROM nor MIUI-based modification.
As with MIUI, it’s based in Asia, so the ROMs available to try currently still have some translation to go through and are only available on a couple of devices. Namely, the GSM and CDMA versions of the Samsung Galaxy S.
The people who are working on it currently are the aforementioned qtwrk on the GSM model and XDA Senior Member swamp goblin, who ported it to the CDMA version from qtwrk.
So far, these are the only two phones that we could find running the OS, which is reportedly only 3 weeks old. It can be expected to start making its way around the forums as people start warming up to the idea. In 6 months we could all be saying that development is not truly active until there’s CM, MIUI and DXOS are present.
If you have a Samsung Nexus S and want to check it out, or if you just wanna see what all the fuss is about, then you can head on over to the GSM Samsung Nexus S thread found here and the CDMA Samsung Nexus S thread found here. Inside these threads you’ll find download links, discussions, installation instructions, the all-important screen shots and additional information about this potentially awesome new Android-based OS. As per the norm, these ROMs are still in beta so exercise the usual caution when flashing (making a nandroid backup, etc).
December 23, 2011 By: Joseph Hindy
XDA Recognized Developer AdamOutler has updated the popular Linux Tool, Unbreakable Resurrector. This will take the newest brick woes of Nexus S users and make them a thing of the past. The only catch? You gotta have Linux, and preferably Ubuntu. Thankfully, the ever helpful AdamOutler has provided links to everything you need in the original thread .
The process seems simple enough, so there isn’t a learning curve or a worry about it being noob friendly. That should be a sigh of relief for those who aren’t ROM flashing aficionados or, like myself, are among those who spend way too much time on XDA.
For more info, check out that link to the original thread. If you’ve been a victim of the rare, but dreaded, bricked Nexus S and have used this tool, feel free to chime in and let us know how it worked for you!
Many Nexus S owners have already loaded an unofficial AOSP Android 4.0 port onto their device. But starting now, you can get the official Android 4.0.3 Ice Cream Sandwich upgrade for the Nexus S. All you have to do is grab the files from the discussion thread, follow a few steps, and you’ll be ready to go. If you’re not brave enough to do it yourself, an OTA update will eventually be pushed to your device, although you might be waiting a bit for that.
If you thought that simply because you weren’t buying a Verizon-bloated Galaxy Nexus that you would be privy to a true Google Experience, guess again! As first noted by XDA forum member Luxferro, who discovered that his GSM Samsung Galaxy Nexus‘s build.prop fingerprint didn’t quite match up to the expected, not every Galaxy Nexus is a Galaxy Nexus.
What is “Nexus?”
Let’s take a few steps back and figure out what’s going on. To do so, we must take a look at what a Nexus device is, and what the term has come to mean. According to Andy Rubin himself, a Nexus device is, “the pinnacle of what we can achieve when integrating Android onto a piece of hardware.” In other words, a Nexus device should represent Android done right, i.e. the absolute zenith of technology—in both software and hardware.
The mere existence of the Nexus program is a tacit admission by Google that although Android’s fundamental distribution model has lead to industry-leading platform adoption, carrier and OEM control is hardly ideal. Instead, Nexus gives Google a chance to “take back” their OS and show the world Android in its full glory.
Previous Nexus Devices
The Nexus line began with the HTC-built Nexus One, the phone which ushered in Android 2.1 Éclair. Barring a select few carrier-controlled versions, this device featured pure Google software in the majority of its configurations. The hardware was great, too—a Samsung-sourced AMOLED panel here, 512 MB of RAM and a 1 GHz Snapdragon SoC there. Just a few months later, Froyo came; and naturally, the Nexus One was the first phone to receive the JIT- and Flash-enabling goods.
Next up was the Samsung-built Nexus S, which brought the first taste of Android 2.3 Gingerbread to the masses 11 months and change after the arrival of the Nexus One. While not quite the latest in hardware—as the Samsung Hummingbird and Super-AMOLED panel had been seen in the Galaxy S roughly six months earlier—the software in the most markets was still controlled directly by Google. While not bearing the moniker “Nexus,” the Motorola XOOM, which delivered Android 3.0 Honeycomb for us on a Aluminum-backed platter, was also a Google-controlled device in its home turf.
When the Galaxy Nexus was officially unveiled on October 19th in Hong Kong, the hardware and software evoked a visceral lust many had not experienced before towards a phone. Packing a 720p Super-AMOLED HD display, a powerful dual-core OMAP4 SoC, a full GB of RAM, and—most importantly—Android 4.0 Ice Cream Sandwich; the Galaxy Nexus was a show-stopper.
A Fly in the Ice Cream-Flavored Ointment
Unfortunately, not all is perfect in Android’s latest tasty treat. Reports quickly surfaced about how Verizon’s 4G LTE variant would feature both VZW branding and a short order of mild bloatware. Bloatware on a Nexus device? BLASPHEMY!
At least unlocked GSM owners were safe… Right? Wrong.
As quickly discovered by community members who failed to receive the 4.0.1 update, and subsequently weren’t able to perform a manually install, there are several software configurations of the GSM Galaxy Nexus. The true, Google-controlled version is yakju—the rest being Samsung-controlled variants, thereof. All carry the hardware code name maguro, so it is plausible that they can be flashed to yakju. However, according to Android software engineer Jean-Baptise Queru, it is unclear at this time whether this is actually possible.
yakjusc and yakjuxw are indeed the two Samsung-prepared builds I’m aware of at the moment, but I’m discovering them as they get released. I only have some visibility over the builds that are prepared by Google, i.e. yakju. Everything else comes from Samsung and I don’t know what their schedules and release plans are. I can’t guarantee that flashing the yakju files that I posted would work on a device that originally shipped with yakjuxw, as I don’t have access to such devices. The hardware is supposed to be close, but I don’t know for sure that it’s close enough. JBQ
Where Does This Leave Us?
All builds other than yakju are not controlled by Google themselves, leading to the very real possibilities of update delays and carrier- and/or OEM-installed bloatware. This doesn’t taste like “Nexus” anymore, does it? Since Nexus represents Google’s regain of platform control, anything other than unfettered Google is no longer Nexus.
To answer the question in the title, those lucky enough to own yakju devices can breathe a sigh of relief because they are able to enjoy a true, Google-controlled Galaxy Nexus. However, all other Galaxy Nexus owners better start getting familiar with fastboot and adb in order to get the unadulterated Android experience.
Leave your thoughts in the comments section below, or drop in to the discussion in the original thread.
Oh, and… SamSONg, I AM DISAPPOINT.
[Thanks to my fellow XDA Moderators xHausx and M_T_M for the tip!]
December 4, 2011 By: Will Verduzco
There’s been much fervor regarding Google’s inclusion of “full” hardware acceleration into Android 4.0 Ice Cream Sandwich. And this is with good reason—the 2D software rendering in Android 2.x made for a noticeably less smooth experience than competing OSes.
While the inclusion of a greater extent of hardware acceleration into the OS is a wonderful thing, there are many misconceptions surrounding what it brings to the table. First off, Android has had elements of hardware acceleration for tasks such as window compositing for years. This means that all window animations were also always hardware accelerated.
Unlike window compositing, drawing inside of a window has traditionally been accomplished by the CPU in Android 2.x and below. In Android 3.0 Honeycomb, however, these functions could be offloaded to the device’s GPU as long as android:hardwareAccelerated=”true” was placed in the application’s manifest. The only difference with Android 4.0 is that ICS turns on hardware acceleration by default as long as API level 14 or higher is targeted. Thus, hardware acceleration in ICS is no more “full” than in Honeycomb. (Note: You can force all applications in ICS to utilize hardware acceleration in 4.0 through the developer options settings pane—something I have wanted in Honeycomb for eight months.)
OK. Now, hardware acceleration is on by default in API 14+ apps, and we have a way to force hardware acceleration in all apps regardless of the contents of the manifest. All is gravy, right? That’s unfortunately not the case. In the case of the PowerVR drivers used in the Nexus S and even Google’s new flagship, simply enabling hardware acceleration in any process eats up 8 MB of memory—per process! While not much on its own, 8 MB here and 8 MB there will lead to much higher memory consumption that could also lead to much slower multitasking. As a result, the Android team is putting considerable effort into fine tuning exactly what parts of the Android UI will use GPU rendering on the Nexus S.
Long story short? When compared to Android 2.x, ICS brings great features to the table thanks to its increased reliance on hardware acceleration. However, other than being turned on by default, ICS’s hardware acceleration cannot be considered any more “full” than what we already had in Honeycomb. Furthermore, hardware acceleration isn’t the magic bullet that many consider it to be—but it will certainly help!
December 2, 2011 By: orb3000
We´ve found that you can download for your Galaxy Nexus 4G (GSM/HSPA+) binary image files that are provided for use in restoring your Nexus device’s original factory firmware. This file, once unarchived, contains the bootloader, baseband, and the rest of the system. Be aware that you’ll need to have fastboot in your path, and to have the device in fastboot mode before you can use it (either “adb reboot bootloader”, or press-and-hold both volume-up and volume-down then press-and-hold power).
Be careful with this download as it can harm your device if not sure what are you doing, be sure to read all instructions before proceed.
Extracted from the original source in Google Code
For convenience, a flash-all.sh script is provided as well, which
restores the entire phone to its factory state.
If you’re only flashing some of the images, I strongly recommend
flashing things in the same order as flash-all.sh. Specifically, flash
the bootloader before the radio, and reboot after flashing the
bootloader or the radio.
Don’t forget that after flashing back to a factory state, your
bootloader is still unlocked. Don’t forget to lock it back in order to
secure your device (“fastboot oem lock”).
Hopefully this’ll be useful to people flashing custom AOSP builds, as
it provides a clean supported way to return to factory state.
Continue to the download link
The Cyanogen team need no introduction when it comes to Android ports that work. Ice Cream Sandwich has been designed to run on phones and tablets natively, so its potential to be more successful than CM7 is a given. With this idea in mind, two weeks ago the Cyanogen team pulled a rock across the entrance of their cave and began work on CM9, stating they would be “back in 2 months”. Despite the Honeycomb project (CM8) being discontinued, the team are seemingly set on making CM9 a success.
CM9 has made an appearance on the Galaxy S i9000 and Nexus S. I’ve been using it on the Nexus S, and for a port that’s only in Alpha 11, I’ve experienced no obvious faults. I am very excited to see how Cyanogen apply ICS to tablets and phones alike.
Samsung Galaxy S i9000:
Google Nexus S:
Ice Cream Sandwich ports are highly sought after, given the hype and price of the phone that runs it. However, providing there is support behind development, there is every chance you can run it on your device. This article is here to list the current ICS ports on our most popular forums and their individual stages in progress. Should your device not be listed below, you can always visit your device’s development forum on XDA and search for any ROMs listed with “Ice Cream Sandwich”. Check out our list! READ ON »
November 18, 2011 By: Will Verduzco
Google’s Mobile Product Manager Hugo Barra recently stated that the company had no plans to update the Nexus One to Ice Cream Sandwich, citing that the handset was simply too old to run the newer operating system. Many users felt unnecessarily abandoned, believing that a former flagship device under 2 years old could hardly be considered “too old” for updates. Having used a Nexus One as my primary device for eight months, the news made my heart sink ever so slightly.
Ironically enough, the first ICS SDK-port for the Nexus One actually had already appeared four days earlier. However, as is the case with the majority of SDK-ports, the lack of hardware acceleration made things dreadfully sluggish. Instead, AOSP builds are indeed the Droids you’re looking for.
Four days ago, we broke news of the ICS Source Code release and predicted an imminent rush of AOSP builds. We are happy to announce that not only has XDA forum member dr1337 begun the Nexus One AOSP porting effort, but several other devices have joined the tide. Thanks to the hard work by XDA forum members dizgustipated, MongooseHelix, stritfajt, jaybob413, onecosmic, Chaosz-X, and zFr3eak; the Nexus S, Droid Eris, Hero, Hero CDMA, Galaxy S I9000, Desire, and Desire HD now have their first tastes of Google’s latest treat.
Without further ado, here are the links to get started on your own device:
While none of the releases have quite the level of polish required to be made daily drivers, their mere presence just days after the source code release speaks wonders of the amazing talent housed within our development community.
If there are any other AOSP builds that I have left out, please send me a PM through the forums, and I will promptly add them to the list!