November 19, 2013 By: Will Verduzco
Capping off a busy day chock-full of KitKat news, Google has just released a new build of Android 4.4 to the AOSP servers and various recent Nexus devices. The new build comes in at version KRT16S, and it replaces the older KRT16O build.
The KRT16S update is currently available for the Nexus 4, Nexus 7 (2012 – all variants), Nexus 7 (2013 – all variants), and Nexus 10. Curiously left out, however, is the Google Nexus 5, which features a different build altogether (KRT16M). Also of note, this new KRT16O build is unrelated to the mystery KOT31B build seen a week and a half ago on the Chromium Issue Tracker.
According to AOSP Moderator Conley Owens, the new build is largely a bug fix build. As such, you shouldn’t expect too many user-facing features. That said, users looking to get in on the action can easily do so by going to the Nexus Factory Images page and downloading the latest firmware images. If building from source is more up your alley, head over to the Android Git and Nexus Driver Binaries page.
[Source: Android Building Google Group]
November 14, 2013 By: Will Verduzco
Ever since Android 4.4 KitKat was released, the question quickly turned to when devices other than the Google Nexus 5 would get to see the goods. We’ve seen various unofficial builds pop up for unsupported devices. In fact, we’ve highlighted quite a few highly functioning releases for a few of the more popular devices currently available. But up until yesterday, if you wanted to enjoy Android 4.4 KitKat in official capacity, you needed to own a Nexus 5.
Then, Google pushed out the official KitKat OTA updates for the Nexus 7 (WiFi only), Nexus 7 (2013, WiFi only) and Nexus 10, and the OTA links were soon captured. However, the timeframe for the Nexus 4 (as well as the Nexus 7 variants with mobile data) was still up in the air, with the only official statement being that it would come soon. Apparently, “soon” actually meant the following day. To that end, the official Android 4.4 KitKat restore images are now available for the Nexus 4, Nexus 7 (all variants and both years), and Nexus 10. Along for the ride are the proprietary driver binaries, which enable ROM developers to make fully functioning builds for these devices. Curiously, the OTA update for the Nexus 4 has not started making its way out to handsets. That said, we can’t imagine it’d be too long now that the KitKat images for the device have been released.
If you’re an end user, installation is as simple as downloading the images and executing the flash-all.bat file. Alternatively, you can extract the available archive and flash them piecemeal through fastboot by executing the command fastboot <partition name> <image name and path>. This will enable you to flash without losing data.
Update: It looks like some of the update links on Google’s site are currently down. We assume this is because they are likely being uploaded to the website. Keep trying every now and then, as we’re confident that they will be live soon.
[Many thanks to reader Sampo S. for sending in the tip!]
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 »
August 22, 2013 By: Will Verduzco
Not too long ago, we brought you news of the Nexus 7 (2013) Factory Image situation and the drama that ensued. Luckily, it wasn’t too long before the world was made right once again, and the factory images and driver binaries for the device were released. For those keeping track, this was build JSS15J for the 2013 Nexus 7 and JWR66V for the rest of the current Nexus stable. Now, a new build has emerged, and it is build JSS15Q for the 2013 Nexus 7 and JWR66Y for the others.
So what does this update bring? This is essentially a minor revision for the Nexus 4, 2012 Nexus 7, Nexus 10, and the GSM Galaxy Nexus. Aside from a security fix and some camera, NFC, and auto-brightness tweaks, not much has been changed. However, if you’re currently using the 2013 Nexus 7, you’re in for a treat. In addition to the above changes, the latest update supposedly fixes the GPS and multi-touch issues experienced by certain users. Also of note is that driver binaries are now available for the Verizon Galaxy Nexus running 4.3 JWR66Y, which bodes well for a firmware update in the near future.
To learn more about the changes made on the 2013 Nexus 7 build, head over to XDA Recognized Contributor sfhub‘s original thread. To get the goods on your own Nexus device without the wait, head over to the Nexus Factory Images page. Finally, if you wish to build your own ROMs from source for your Nexus device(s) and want the latest driver binaries, head over to the Nexus Driver Binaries page.
Did this update fix your 2013 Nexus 7′s GPS woes and erratic multi-touch? Let us know what you think of the updates in the comment box below!
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!
July 24, 2013 By: Will Verduzco
We were all expecting it. In fact, we’ve all been waiting for it ever since this year’s Google I/O. However, that conference came and went, without a trace of Android 4.3. But after last week’s Android 4.3 leak, we knew it was finally coming soon. And in today’s Google event, which also marked the release of the Nexus 7 refresh, it has finally been made official.
So what’s new in this latest flavor of Jelly Bean? Here are some of the key changes, courtesy of the Android Developers blog post:
- OpenGL ES 3.0 — Game developers can now take advantage of OpenGL ES 3.0 and EGL extensions as standard features of Android, with access from either framework or native APIs.
- Bluetooth Smart — Now your apps can communicate with the many types of low-power Bluetooth Smart devices and sensors available today, to provide new features for fitness, medical, location, proximity, and more.
- Restricted profiles — Tablet owners can create restricted profiles to limit access to apps, for family, friends, kiosks, and more. Your app can offer various types of restrictions to let tablet owners control its capabilities in each profile.
- New media capabilities — A modular DRM framework enables media application developers to more easily integrate DRM into their own streaming protocols such as MPEG DASH. Apps can also access a built-in VP8 encoder from framework or native APIs for high-quality video capture.
- Notification access — Your apps can now access and interact with the stream of status bar notifications as they are posted. You can display them in any way you want, including routing them to nearby Bluetooth devices, and you can update and dismiss notifications as needed.
- Improved profiling tools — New tags in the Systrace tool and on-screen GPU profiling give you new ways to build great performance into your app.
Much has also been done to improve UI performance. Most notably, the Android 4.3 Platform Highlights page mentions a change to the hardware-accelerated 2D subsystem that modifies the stream of drawing commands to send the commands to the GPU in an optimized manner. And in instances when the CPU is required, these operations are now multi-threaded, allowing the use of multiple CPU cores. Improved window buffer allocation also speeds up buffer allocation, resulting in speedier rendering starts. And to best harness the GPU’s power in 2D hardware-accelerated tasks, the system now uses OpenGL ES 3.0 for optimized texture management and to maintain higher gradient rendering fidelity. Of course, however, the main use of OpenGL ES 3.0 will be to provide game developers with the framework and native API access they need to produce high quality and efficient games.
Another major highlight in this Jelly Bean refresh is a substantial refresh to the notification system, whereby third-party apps can observe the stream of notifications and display them or transfer them to nearby connected Bluetooth devices. And just as before, notifications can be enabled or disabled per app. Building upon this, however, now users are allowed to see and toggle which apps have access to the notification stream.
The tablet multi-user feature has also been revamped. Now in 4.3, users are given the option to set up restricted profiles. This allows owners to easily create separate environments for each user, with the ability to manage restrictions in apps available in those environments. This feature is aimed to sharing your device with friends and use at kiosks.
Other notable changes include Bluetooth Smart Ready to aid in discovery and communication with nearby devices, Bluetooth AVRCP 1.3 support for richer interactions with media streaming devices, an improved DRM framework, and a VP8 video encoder.
You can learn more by heading over to the Android Developers blog post and Android 4.3 Platform Highlights page. If you’re lucky enough to own a Google Nexus 4, Nexus 7, Nexus 10, or Galaxy Nexus, you can expect this update to come over-the-air shortly. And if you find yourself impatiently waiting, you can get a head start and download the images by visiting the Nexus device factory images.
February 13, 2013 By: Conan Troutman
Those of you with Nexus devices will most likely have received an update to Android version 4.2.2 by now. The news of the OTA was broken on the forums yesterday by XDA Senior Member kataria.vikesh. Those of you who have not are no doubt on the verge of applying the update manually after a lengthy session of gawping at your status bar awaiting that notification. Nexus 4 owners may find themselves waiting a little longer than the rest, as there doesn’t seem to be any sign of an update for the device yet. However, the changes have already been merged into some custom ROMs. This latest version, build number JDQ39, was also pushed to AOSP yesterday meaning that we should soon see this latest update becoming unofficially available on a whole host of devices.
So what exactly are the changes in 4.2.2? Well, we already know from the version number that this isn’t a huge update, there are however some notable additions to functionality and tweaks to the UI. Most of these are directed more towards the end user, but one of which will no doubt be a welcome addition for some developers out there so let’s start with that one.
ADB Whitelist: Connecting your device to a PC with USB debugging enabled will now bring up a prompt which displays your PC’s RSA key and offers the option to add this information to a whitelist. Unless a specific computer is allowed access via this prompt, the device will be inaccessible via ADB. This of course adds an extra level of security to the device. Providing you use a secure lock screen any potential thief with a little ADB knowledge will be unable to access the prompt and add themselves to the whitelist. Unfortunately, it seems that this feature may not provide much more security for users with an unlocked bootloader, according to the guys at Android Police.
Other changes include:
There’s speculation as to whether the issue of streaming music over A2DP has been addressed. Some users are reporting an improvement, whereas others are not. If anyone is able to spot this in the commits then please let us know in the comments.
February 9, 2013 By: Will Verduzco
By now, you’ve no doubt heard of Paranoid Android. In fact, there’s a good chance that if you own the Galaxy Nexus, Nexus 4, Nexus 7, or Nexus 10; you’re either running the ROM yourself or you’ve given it a try in the past.
For the few unfamiliar, Paranoid Android’s defining characteristic is what they call Hybrid Engine. Contrary to what many believe, this is not “tablet mode,” though that is one of many things that can be accomplished using Hybrid Engine. Rather, Hybrid Engine allows you to select both dpi and layout on a per-app basis. Rather than being forced to modify the look of your entire device, you can optimize your applications to what works best for each and every one.
A new and important feature that has come to light in the recent beta builds, and now sees light in the official release of PA3 is the PIE control system. What this allows one to do is to disable onscreen buttons and use a swipe gesture to access various common functions, thereby freeing up valuable screen real estate. The menu can be seen in the header image above, as well as the video below.
Per-app color, another significant feature in PA3 and recent pre-release builds, allows you set system UI colors on a per-app basis. Want a black system bar for your launcher, but a blue one for Facebook? No problem. Have more eccentric choices in mind? That’s fine too.
The most recent (and most specific) addition is screen calibration for the Google Nexus 4. While the vast majority of third-party reviews have praised the device for its screen, build quality, responsiveness, and overall value; some have been quick to point out that the screen seems under-saturated, especially to those coming from overly saturated S-AMOLED devices. Rather than trying to offer a simple band-aid solution with RGB calibration, PA3 also corrects for the device’s gamma issues to give it the punch the IPS panel deserves. While you’ll be hard-pressed to find anyone who says that the Nexus 4 screen looks “bad,” the calibration has been met with much praise thus far, and the team only hopes that these changes are incorporated upstream.
Are you salivating yet? Those eager to get started should visit the threads below. Naturally, there will also be a plethora of unofficial ports for various unsupported devices. So if you’re looking for a build for your device, be sure to check in your device forum to see if someone’s already attempted porting the ROM. Even better, you could always try porting and building the ROM from source yourself.
January 14, 2013 By: Haroon Q. Raja
Whenever there is mention of custom ROMs for Android, AOKP is one of the first to come to mind. Over the past year, the popularity of this source-built ROM has skyrocketed to make it one of the most recognizable third party development projects. Though over the past few months, several AOKP users (including myself) decided to jump ship to other ROMs because of the delay in a release based on Android 4.2. There is good news: The wait is over, as Team Kang has officially released Android 4.2.1-based AOKP JB-MR1 Build 1, starting with the Nexus line of devices.
As with the changes in Android 4.2 from 4.1, the changes in this AOKP release from the previous one aren’t as many as we’ve seen in previous major releases. However, they are still substantial enough to improve the overall user experience. Apart from all the AOKP features of the previous Jelly Bean builds, you’ll get:
The Nexus line of devices was the primary focus of AOKP since its very inception, and they are the first ones to get this release as well. However, that doesn’t mean other devices will be left out. The team is working on Galaxy S II, S III, Note, and Note II support for the next build, with builds for many other devices to follow. Until then, you can grab the ROM for Nexus devices from the following links:
The team is also planning a return to its (bi)weekly release schedule once builds for more of the officially supported devices are ready. More information can be found at the AOKP website.
January 8, 2013 By: jerdog
Bootloaders are like locks on a cookie jar: They’re just begging to be unlocked. When users on XDA see a locked bootloader, they immediately start looking for the accomplished developer who is working on hacking the device. It is for this reason that we like to hold Google Nexus devices as the gold standard for how manufacturers (and carriers) should approach their bootloaders, as well as firmware openness.
Nexus devices are easy to unlock: You go into fastboot mode, type ‘fastboot oem unlock’, and you’re done. Easy peasy. Of course, Google’s method involves an automatic wipe of your data, which functions as a pseudo-security measure. There of course is a way to get that data back after the wipe on the Galaxy Nexus, but what most users fail to think about is locking their bootloader again once they’ve gotten their ROM to where they want it to be. This opens up their device to all sorts of potential problems, especially those of the malicious kind.
Recently there has been talk about the Samsung Exynos 4 memory exploit, which leaves Exynos 4-based devices open to malicious attackers. With the fact that Samsung has never fixed the eMMC Brick Bug issue, which affects stock and non-stock Exynos 4 devices, you have the perfect storm of malicious attacker meets manufacturer negligence. Users can have their devices bricked and/or wiped in a matter of moments, and they would be none the wiser.
XDA Senior Member segv11 came across something in the Nexus bootloader, which is cause for concern for the Galaxy Nexus, Google Nexus 4 and Google Nexus 10. segv11 created a bootloader unlock, which does not follow the normal convention. Instead, it falls back on a process where you can keep your bootloader locked, and still keep a sense of security. He does this by simply changing a couple of bits in the /param partition, while keeping the bootloader locked for security reasons. XDA Elite Recognized Developer AdamOutler also released a similar process for the Galaxy Nexus back in April of 2012 which utilizes a brute-force method to unlock the bootloader by replacing the entire /param partition instead of just adjusting the bits.
This app highlights an issue with the way Google has chosen to lock the bootloader, especially when it’s easy to just change the aforementioned bit. What else is contained in there that can be hacked? What else is there that a malicious app, with root privileges, could potentially render your device a pricey brick? It’s for this very reason that we encourage users to be very careful before they mess around with their devices, and to make sure they read all of the instructions the developers put together beforehand.
December 5, 2012 By: Former Writer
Over the last couple of weeks, we’ve been bringing you news of mskip’s toolkits making it to the Nexus 4 and the Nexus 10. It’s a popular and well known toolkit with extensive features. There is a second toolkit making its way around to Nexus devices, known as Wug’s Nexus Root Toolkit. We brought you news that it was released for the Nexus 7. Now, it’s available for the Samsung Nexus S and Nexus S 4G, the Nexus 4, and the Nexus 10.
XDA Recognized Developer WugFresh has been busy this month. The toolkit has made to five different Nexus devices in just a few weeks. The core features of the toolkit are the same for all releases, and include:
This program will automatically bring together all the files you need to unlock and root your device in a few clicks, or flash it back to stock and re-lock it. You can also use this program to backup/restore all your important data, flash zips, set file permissions, push and pull files, install apps, and much more! With the included file association options, you can perform tasks like flashing zips, installing apps, restoring android backup files, and flashing/booting img files with just a double click! The program includes a full featured interface for automating tasks in TWRP, enhanced restore features, an in-built auto-updater/notification system, ‘any build’ mode, and quick tools utilities. All the latest Android builds and Nexus devices are now officially supported, including the new Nexus 10, Nexus 4, and 3G Nexus 7 (with full 4.2.0 support).
The premise of this toolkit is to make rooting easy and provide a few extra features like installing applications and pushing files. For those looking for a root-bringing toolkit, you should give them a shot.
Unless you’ve been hiding under a rock somewhere, you know that Google has released a few new devices (Nexus 4 and Nexus 10), as well as a refresh to the Nexus 7. What makes this different from previous Nexus releases is that there are two new manufacturers added to the mix with Asus (Nexus 7) and LG (Nexus 4) joining Samsung (Nexus 10 as well as Nexus S and Galaxy Nexus) and HTC (Nexus One).
We recently told you about XDA Elite Recognized Developer Chainfire’s new project to automatically root devices and keep them as stock as possible, and we now have an important update to share with you, as Chainfire has added CF-Auto-Root support for the new Nexus devices. What makes this update different from previous versions is that fastboot support has been enabled, as well as an updated version of SuperSU (v0.99).
Follow the links below to learn more and to obtain the downloads.
December 3, 2012 By: Haroon Q. Raja
With the release of Android 4.2, Google added several new features to the the OS. While the CyanogenMod team has officially started the transition to 4.2 based CM 10.1, it may take a while for them to start rolling out the latest 10.1 nightlies for all devices. That’s where XDA Recognized Developer and Team Euroskank member makelegs has stepped in, providing us with a working self-compiled kang built from the latest CM 10.1 sources for the Google Nexus 10.
Announced through Google+ by makelegs, this build joins the CM 10.1 builds for Nexus 7 already bring provided by Team Euroskank. As with all nightlies, some glitches here and there would be expected. However, based on the response in the forum thread, the build seems solid enough to be usable, and it lets the early adopters among us give CM 10.1 a shot before it’s officially released.
You can find more information and download links in the forum thread.