February 3, 2014 By: Tomek Kondrat
Imagine that you’re flashing the latest nightly of your favorite ROM. If you are performing a fresh install by wiping all of your data, this also means that you have to flash all of your modified system apps, user apps, modules, and so on. And if you’re doing this on a regular basis, all the wasted time really starts to add up. So what do you do? Do you manually install these apps again, or do you add them to your favorite ROM? One of the better solutions is to use Aroma Installer by XDA Recognized Developer amarullz. However, you normally need some experience to configure it properly.
A few days ago, we talked about a Windows-only tool to create flashable ZIP files. Now, it’s time to present yet another tool that can be used on every OS with Java installed. With Android Flashable Zip by XDA Senior Members Nikhil and RajatPatel, you can easily add apps, boot animations, ringtones, and much more to a flashable ZIP. And since the tool uses Aroma installer, you can pick and choose which apps you want installed when applying the ZIP.
Aside from requiring Java to be installed on your PC, tool currently only supports a few devices—namely the Samsung Galaxy R (i9103), Samsung Galaxy Nexus (maguro), LG Optimus 4X HD (p880), and Samsung Galaxy Note II (N7100). That said, the supported device list will surely increase in time. And even if your device is unsupported, you can always give it a try and report your findings in the thread. Just be prepared in the event that something does go wrong.
If you want to easily create AROMA-based flashable ZIPs, head over to the development thread and give Android Flashable Zip Creator a shot.
December 26, 2013 By: Will Verduzco
As you’re making your way down the list of things to try with your newly acquired tech toys, one thing you’ll undoubtedly get around to is flashing a custom ROM. Those looking for aftermarket firmware now have one more Android 4.4.2-based option, as the AOKP team has just finished incorporating Google’s latest and greatest into their nightly builds.
Currently, Android 4.4.2-based nightly builds are available for the Google Nexus 5, Nexus 4, Nexus 10, Nexus 7 (2013), Galaxy Nexus, Galaxy S III, Galaxy S 4, HTC One, Xperia Z, Xperia ZL, Xperia T, and Xperia V. More devices will be added to the nightly list as soon as they’re ready. The AOKP team recommends a full wipe when installing the latest JB-MR2 nightlies, but users on unofficial builds released after December 10 may be able to get away without a full wipe.
December 5, 2013 By: Tomek Kondrat
The Samsung Galaxy Nexus was the first device to run Android 4.0 Ice Cream Sandwich. It was also the pride of Google and Samsung for a long time, and it still has quite a few stalwart fans. Good technical specification for its era combined with a then-amazing Super AMOLED HD screen equate to a device that is still more than adequate for most tasks. Unfortunately, Google chose to not bestow an official KitKat update on the device, leading many to speculate that this was due to TI’s exit from the mobile SoC industry.
A few weeks ago, we wrote about early KitKat releases by the Slim Team and XDA Senior Member Grarak, but a few things still needed to be polished and worked on. After few weeks, the GNex can join the elite team of devices with fully usable KitKat thanks to XDA Recognized Developer PlayfulGod. The build is described as beta mostly due to missing some common CM11 features. However, the only known remaining bug is glitchy screenshot functionality, but this ROM is a great achievement that once again proves that developers on XDA can do the impossible—or at least what OEMs label as such.
If you own a Galaxy Nexus and want some KitKat, head over to the ROM thread and give the newest build a try.
Android is six years old now. One week ago, we presented the first part of the Android story. Now, it’s time to continue the journey.
A long time ago in a galaxy far, far away—located in Mountain View, the first version of the operating system dedicated for tablets was born. Google called it 3. 0 Honeycomb and presented it alongside the Motorola Xoom.
November 8, 2013 By: Will Verduzco
We first heard that the Samsung Galaxy Nexus would not be receiving the Android 4.4 KitKat goods when Google announced that the device fell outside of the traditional 18-month window for firmware updates. Many figured, however, that the underlying cause of this was not Google’s choice, but rather TI’s exit from the mobile SoC market—and of course, the subsequent lack of Android 4.4-compatible driver binaries for the OMAP4460 used in the device.
Despite the driver setbacks, we’ve seen highly functional, source-built Android 4.4 ROMs pop up for the GSM Galaxy Nexus (maguro), as well as for the Verizon CDMA/LTE variant (toro). The only thing left in the way of a happy Galaxy Nexus family was a build for the Sprint CDMA/LTE variant (toroplus). Now thanks to XDA Recognized Themer kufikugel, there is such a build.
If you have been keeping up with the Galaxy Nexus KitKat situation, you may recognize the name kufikugel. That’s because he’s also responsible for one of the two releases that we covered to initially bring KitKat support to the GSM version of the device. Now, he’s brought the ROM over to the toroplus. Just like his maguro ROM, this is a part of the SlimRoms SlimKat family of cross-device ROMs.
The vast majority of device features appear to be working in SlimKat for the toroplus, and many users have reported near flawless performance. But as expected, this also contains the same types of graphical glitches as seen in other Galaxy Nexus builds—though this may be alleviated thanks to newly available drivers. Other than that, users need to take care to download the proper gapps package and be on the latest version of CWM recovery.
Head over to the ROM thread to get started.
[Many thanks to XDA Forum Member rjzmanz for the heads up and sharing his experiences with the ROM.]
November 8, 2013 By: Will Verduzco
When it was discovered that the Samsung Galaxy Nexus would not be getting an official build of Android 4.4 KitKat, many of the device’s loyal users were understandably upset. After all, the Galaxy Nexus is still a competent device today, almost two years after its November 17, 2011 release date.
Despite Google’s claims that the Galaxy Nexus fell outside of the typical 18-month support window, many were quick to attribute the missing update path to TI’s exit from the mobile SoC market, and the subsequent absence of drivers for the latest version of Android. This very issue has been the source of various graphical glitches seen with early, unofficial builds for the GSM and Verizon variants of the device. However, this may be less of an issue going forward, as XDA Recognized Developer aosp has located a new commit to the GPU drivers on OMAPZoom by TI employee Eric Luong that may be able to aid the porting process.
Not all is entirely rosy, however, as XDA Recognized Developer Hashcode later points out:
Q: THESE PVR BINARIES LOOK AMAZING! WON’T THEY HELP WITH 4.4 DEVELOPMENT?
A: Maybe.. Maybe not. In reality these binaries posted by @aosp are a bit “odd” when it comes to the build. The newest OMAP4 PVR binaries from TI are DDK 1.9 @ 2291151. They were found on the review website and never actually posted into the proprietary git. The actual “standard” JellyBean TI PVR binaries are around DDK 1.9 @ 2166536. You can see from the image that the binaries posted above are DDK 1.8(?).
In the end, the main goal is to be compatible w/ the current surfaceflinger/hwcomposer implementations so that no major hacks are needed to get the GPU functioning. EGL support for GL_OES_EGL_image was key for ICS when it first came out. In JellyBean you needed hwcomposer API 1.0 with a 3.0.31+ omap kernel. For hwcomposer 1.1 API (as implemented by TI) you would need a 3.4 kernel complete with android platform framebuffer patches / extended hwcomposer API.
GNex *could* use the newer TI PVR binaries. But might need to have it’s 3.0 kernel’s dss/dsscomp/gralloc files edited to be closer to the end of the p-android-omap-3.0-dev kernel’s sources. And of course the pvr kernel modules need to match as well.
Q: WHAT ABOUT THE GRAPHIC ISSUES?
A: There could be a variety of reasons why the graphics suffer on the latest builds for the GNex. I don’t know all of the details why as I have never dev’d on the GNex, but I’m sure more knowledgable devs have more info. New PVR bins would certainly help with compatibility, but not necessarily solve performance issues.
Ultimately, these updated binaries (that appear to be intended for Jelly Bean as stated in patches abef31d and 9ecd6e0) may be of some use. But as stated by Hashcode, they may not be the end-all-be-all for all the currently seen graphical and performance issues.
A couple of days ago, we talked about how you could get some of the KitKat goodies on your Jelly Bean device, thanks to some APKs that were extracted once the Nexus 5 factory images were released. While it is obviously preferable to have the real thing, these KitKat apps are the next best thing if you are on a device without a stable KitKat build—well, other than learning how to build from source and creating a port for your own device yourself.
The previous article focused on getting the launcher, new Hangouts app, Camera, Google Now, and Gallery working. Now, there is a fantastic guide by XDA Recognized Themer ATTACK that shows you how to get KitKat-style gradients in your Status and Navigation Bars, assuming you have an AOSP-based ROM. This involves decompiling, modifying, and recompiling your android.policy.jar and SystemUI.apk files, but there’s a guide for that.
Then to top it all off, XDA Senior Member ivn888 created a thread with all of the KitKat wallpapers, sounds, fonts, and even the boot animation. The wallpapers are available as standard images, and the sounds, boot animation, and fonts are flashable ZIPs.
To get started, head over to the gradient status and navigation bars guide and the wallpapers, boot animation, sounds, and fonts thread.
And for those who want to see the overall product of using these customizations, XDA Senior Member enricocid created a KitKat-flavored ROM for the Galaxy Nexus incorporating these goodies. While it’s not KitKat, and there are already some highly-functional builds available, the look is pretty convincing.
November 3, 2013 By: Will Verduzco
When Google stated that it would not update the Samsung Galaxy Nexus to Android 4.4 KitKat, many device owners were understandably disappointed. Many took their frustrations to the Internet, expressing distaste for the company’s decision. However, given TI’s exit from the mobile SoC market, we can’t imagine that Google had much choice in the matter.
It was only a matter of time, though, before the crafty developers here on XDA managed to get the latest version of Android onto the now unsupported device. Yesterday, we took a look at the first two source-built ROM builds for the GSM version of the Galaxy Nexus (maguro). However, this was of little comfort to owners of the Verizon variant (toro). Now, however, there are two source-built ROMs for the toro that bring the latest 4.4 goods to a device that hasn’t even seen 4.3 in official capacity.
The first comes from XDA Forum Member MWisBest, with his release entitled Fork My Life. According to the developer, the ROM is relatively functional. User response seems to corroborate this statement. Like yesterday’s builds, there are graphical glitches in certain animations, as well as when running the stock browser. Also, the camera and gallery apps don’t seem to work in this release. However, everything else seems to be running fine for most users.
The second comes from XDA Forum Member fairct. Similarly, most features work on this build, but you will experience the same graphics glitches currently affecting all KitKat ROMs for the Galaxy Nexus. And according to one user, the camera even works on this build.
As was the case on the GSM Galaxy Nexus (maguro) builds covered yesterday, the graphical glitches in these two builds are to be expected. This is most likely due to the changes to SurfaceFlinger that I detailed in my Android 4.4 feature overview. And as stated in the previous article, this is unlikely to go away entirely without updated driver binaries, which TI is unlikely to provide now that they are out of the SoC business.
In any case, if you are willing to deal with the graphical glitches, which really aren’t that bad unless you are in Chrome browser or viewing certain transition animations, head over to the builds below to get started.
While there currently are no source-built Android 4.4 builds for the Sprint Galaxy Nexus (toroplus), we can’t imagine that it’ll be long before we see them starting to pop up.
November 2, 2013 By: Will Verduzco
As soon as we broke the news that the Samsung Galaxy Nexus would not be receiving the Android 4.4 awesome-sauce, we knew it was only a matter of time before the dedicated developers here at XDA would bring us some KitKat-flavored alternatives. Now, the time is here, and there are two functional, albeit not perfect, builds available for the popular maguro.
The first alpha build that appeared came from XDA Senior Member Grarak, and is entitled A Taste of KitKat. While most device features work, and user response has been largely positive, WiFi is broken. There are also some graphical glitches when taking screenshots, accessing the recent apps menu, and during screen rotation.
The second build comes from XDA Recognized Themer kufikugel, and it is a part of the SlimRoms SlimKat family of cross-device ROMs. This build appears to be a little more functional as WiFi appears to be working. But as expected, this also contains the same types of graphical glitches as seen in the other ROM.
It is important to keep in mind that these glitches are most likely due to the changes to SurfaceFlinger that I detailed in my Android 4.4 KitKat features overview two days ago. And since TI is out of the SoC game, it is highly unlikely that any solution (read: updated driver binaries to fix these graphical glitches) will ever come in official capacity. That said, it’s great to see 4.4-based ROMs appear for the “forgotten” Nexus. And for those willing to live with a few graphical anomalies, you now can enjoy KitKat in some capacity.
[Thanks to kufikugel for the heads up!]
November 1, 2013 By: Will Verduzco
What an exciting day we had yesterday. As was widely speculated, the Google Nexus 5 was finally released, which means that you can finally put that F5 key to rest. However, the new device wasn’t the only important announcement yesterday. We were also given a nice dose of the next version of Android, version 4.4 KitKat. Now the question in everybody‘s mind undoubtedly turns to when their device will get the update. Luckily, we now know the roadmap for certain key devices. READ ON »
October 17, 2013 By: Will Verduzco
Back at XDA:DevCon 2013, Ubuntu community manager Jono Bacon gave a talk about the future of Ubuntu on mobile devices. Also at the conference, Ubuntu coder Michael Hall held a Ubuntu Touch Development Workshop aimed at spurring and fostering application development for the soon-to-be-ready platform. Both of these presentations can now be viewed online. Fast forward a few months, and Ubuntu for phones is now available for its first two devices.
Coinciding with the desktop Ubuntu 13.10 release, Ubuntu for phones is now officially available for installation on the Google Nexus 4 and Samsung Galaxy Nexus. The release bills itself as being feature complete, with quite a few bells and whistles available including gesture control for multitasking and regularly used apps, click packages, cloud photo storage, easy access to search from anywhere, extensive personalization possibilities, and a set of APIs with which to build new applications. And because all of the included core applications run natively rather than through an interpreter, Ubuntu promises high levels of performance.
While today’s release is a very big step forward, not everything is fully baked just yet. Only two devices are currently supported. And even for those devices, the experience isn’t quite perfect. For starters airplane mode and a lock screen have not yet been added. And remember the promise of convergent computing where a smartphone can function as a complete PC, as long as it meets the minimum requirements? Well, that’s not yet available. Despite the limitations, today’s release is quite exciting. It’s always nice to see other software options available for the devices that some of us already own.
Head over to the Ubuntu for Phones splash page and follow the relatively simple instructions. More information about the specific capabilities and limitations in today’s release can be found here. Finally, those looking into community-based progress on Ubuntu for Phones for other devices should head over to the Ubuntu Touch Wiki.
[Thanks to User Experience Admin svetius for the tip!]
August 7, 2013 By: Will Verduzco
The long-rumored Moto X was finally released last week to a relatively mixed reception from tech enthusiasts everywhere. While the device is far from a class-leading smartphone in terms of raw specifications, it carries with it some interesting features that set it apart from the sea of other Android device. One of these features is the new Active Display functionality, which is supposed to make special use of the device’s somewhat unique processor architecture and AMOLED display in order to periodically display critical information on the lock screen without any user input.
Due to the somewhat lackluster hardware specs, many of us will not buy the Moto X. However, that doesn’t mean that we wouldn’t want Active Display on our own devices. If you’ve found yourself longing for the feature, XDA Forum Member niko001 may have the perfect application for you with ActiveNotifications.
ActiveNotifications simulates the Moto X feature on Android 4.3 devices by using the OS build’s new Notification Listener service. Because of this, battery drain on AMOLED devices running this modification shouldn’t be terribly high, regardless of processor architecture. As stated by the developer:
It uses the new “Notification Listener” service introduced in 4.3 and therefore has minimal impact on your battery. If you own an AMOLED-phone, the “battery saving” feature should work automatically, since black pixels are simply not turned on. The app comes with similar features as the Moto X Active Display (such as not turning on when the device is inside your pocket, purse, or lying face down). Unfortunately, relying on the 4.3 Notification Listener also means that you need a device running Android 4.3 (which are pretty scarce at the moment)…I’ll think about creating a version for older versions of Android if there is enough interest.
Essentially, this is only practical on AMOLED devices running Android 4.3. Currently, this brings the list of officially supported devices down to 2: the Samsung Galaxy Nexus and the Samsung Galaxy S 4 Google Play edition. However, if you’re running a custom 4.3-based firmware and have an AMOLED panel, this may well be up your alley.
Head over to the original thread to get started.
July 31, 2013 By: Will Verduzco
Android 4.3′s launch last week has been nothing short of an almost resounding success. Why “almost?” Well, aside from a few issues with copy/paste, most users seem to be quite happy with the latest iteration of Jelly Bean. This level of user satisfaction is to be expected, as the latest flavor of Jelly Bean brings added performance, improved API support, additional functionality, and a few other features. One of these “other features,” however, is quite important for those of us who frequently transfer massive amounts of data to our devices such as media content and other large files.
Of course, as you might expect, I’m talking about how 4.3 also brings TRIM support to all Nexus devices. Anyone who has ever experienced a massive device slowdown after transferring large quantities of data to and from a NAND device knows what I’m talking about. For a very practical example, one need only look at Google’s original Nexus 7. Back when it first came out, reviews for the popular device nearly unanimously praised it for its high level of performance. However as time went on, most users seemed to notice a rather sharp I/O performance decline. This lead to an overall feeling of sluggishness when using the device, making the once fast tablet almost unusably slow for some. This issue seemed to affect those with lower capacity models more severely, or at least more quickly, than those with the 32 GB model. As you would expect, this was largely due to TRIM not being enabled in previous builds. This then prevented the scheduling of NAND blocks for garbage collection, making rewriting data to these blocks significantly slower. (Note: Traces of TRIM were added back in the Nexus 7 4.1.2 builds, but the current consensus is that it wasn’t actually enabled until 4.3.)
Looking into the Android Git, one can readily find the modifications to Android’s volume daemon (VOLD) to enable fstrim. The next step is determining when exactly fstrim runs. As exposed by some detective work by Brian Klug over at Anandtech:
I’ve learned a bit more on the conditions underlying when Android 4.3 will TRIM filesystems, as it wasn’t completely clear before. The Android framework will send out a “start idle maintenance window” event that the MountService listens for, and then invokes vold to fstrim filesystems when a few conditions have been met – the device hasn’t been touched for over an hour, no idle maintenance window event has been sent in 24 hours, and the device is either off-charger with 80% battery or on-charger with 30% battery. The goal is to have fstrim run roughly once every 24 hours if you’re in the habit of plugging the device in to charge every night.
Fstrim sends the FITRIM ioctl() command to all writable filesystems when invoked, which discards (TRIMs) blocks on the eMMC not used by the filesystem. Without TRIM the controller will track blocks that have data deleted by the filesystem, but the controller still believes has data it needs to track. TRIM is the signaling pathway through which the filesystem and OS can tell the controller that it can now consider those blocks unused and for garbage collection – different controllers will behave differently since it’s their prerogative to decide what happens next however.
In other words, if your device is idle and plugged in for over an hour, it will run the “start idle maintenance window” event. However, this will only take place if the “start idle maintenance window” event hasn’t been sent in the past 24 hours, and if your battery level is either greater than 80% or you are plugged in and have greater than 30% battery. Another way to invoke TRIM is to use a frontend for the fstrim utility and force TRIM to be executed using an app such as XDA Senior Member AuxLV‘s Lagfix application.
All of this is unimportant without tangible performance gains. So what can you expect from 4.3 in terms of I/O performance? Over the next couple of days, I set to find out on two daily use devices. I’m going to be running tests using Androbench Storage Benchmark before and after upgrading from official JDQ39 (4.2.2) to official JWR66V (4.3) on my personal Nexus 7 (8 GB) and Nexus 10 (16 GB). Both devices have received heavy usage, with much data being transferred to and from the devices, and about as many deletions. After the “after” tests are run, I will then root the devices and use the LagFix fstrim frontend to force TRIM manually and rerun the benchmarks. Stay tuned and keep checking the Portal for updates!