February 19, 2014 By: Will Verduzco
Hot off the heels of selling money pit Motorola to Lenovo, could Google be eyeing the new Moto-novo as the next Nexus phone manufacturer? According to sources over at IB Times Australia, this is highly likely. Ignoring the obvious irony in selecting the now third party Motorola as a Nexus device manufacturer, this alleged partnership could make quite a bit of business sense.
For starters, let’s consider a potential timetable. Since Nexus phones are typically released in the Fall, that would mean that R&D for such a device would have to begin a significant amount of time prior. Assuming a one year turnaround from initial design to device ship date, that would mean that the Motonovo Nexus 6 would have been under active development when the OEM was still Googorola. Furthermore, having the now Lenovo-owned Motorola produce the next Nexus device would avoid that nasty conflict-of-interest in selecting a first-party OEM as a Nexus device manufacturer. And finally, since Google now owns a small chunk of Lenovo, this gives Google a vested interest in the future of Lenovorola.
Now let’s consider the other Nexus device successors. Both the first and second generation Nexus 7 tablets have seen great commercial success. Loved by consumers and the media, these wallet-friendly tablets prove that you don’t have to sacrifice build quality in order to get a top notch device experience. And due to their success, they essentially defined what has become the archetypal Android tablet. Because of the nearly unanimous praise seen by the devices, it’s safe to assume that Asus will produce the next mid-sized Nexus tablet. And what about that shift from 7″ to 8″? (that’s what she said) Well, given the popularity of that debunked rumor of an 8″ Nexus device that ended up being a bad device mock-up, it stands to reason that Google saw consumer demand for a slightly larger midsize tablet and changed plans accordingly.
So, what about HTC? It’s no secret that the Samsung-built Nexus 10 has not seen much commercial success. Despite offering a fantastic display and relatively decent internals, many feel that the app ecosystem is simply not there for the 10″ tablet space. And beyond the lack of 10″ tablet-friendly apps, the device still is relatively sluggish, largely due to that massive WUXGA resolution screen. Where does HTC fit into all of this? Well if you recall, HTC recently held a Reddit AMA. And in this Q&A session, the Taiwanese company was asked if it had any Nexus plans. Rather than simply stating that nothing was in the works, they replied no comment.
So what do you make of all of this? What would be your ideal Nexus phone, mid-size tablet, and full-size tablet? Personally, I’d love to see a Motorola Nexus phone, but 5″ is already pushing it for me when it comes to device size. I’d also like to have a slightly bigger mid-size Nexus tablet, as my Nexus 7 v1 and v2 always felt a bit small. And about that HTC Nexus 10? That’d be the One for me! Let us know your thoughts and what you would like to see in the comments below.
[Source: IB Times Australia | Thanks to my fellow writer Tom for the heads up!]
January 14, 2014 By: Will Verduzco
Update: It appears as if this was a hoax. See below for more details.
Although the Samsung-manufactured Google Nexus 10 still offers a great value with its class-leading display and relatively speedy processor, it’s hard to argue with the fact that the device is starting to get a little long in the tooth. The device, which was released in the middle of November 2012, is now well over a year old. This is essentially an eternity in the mobile device world, where generational gaps are shrinking faster than we can even keep track (e.g. Samsung’s plethora of marginally different device variants).
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 15, 2013 By: eagleeyetom
As you all know, AOSP is the purest form of Android. All Nexus devices are shipped with relatively clean Android, baked by Google engineers. Constant and frequent updates make it a quite interesting position for all Android enthusiasts. But AOSP is pretty barebone, as it lacks many of the key features of skinned ROMs that many of us have come to enjoy. This is when the brilliant Xposed Framework enters the picture.
A few months ago, we talked about an Xposed Module aimed at bringing some goodies to Samsung stock ROMs made by XDA Recognized Developer wanam. This time, wanam created a module dedicated to Nexus devices owners running KitKat. This module allows you to customize many little things to make your stock ROM more suitable for your needs. With this kit, it’s possible to change the clock position, the type and color of your battery text, and so much more. Everything can be found in the original posts, where a video demonstrating the module is also available.
Nexus devices should not be limited to AOSP features only, and Wanam Kit gives you a great chance to enhance the user experience. More information and the module itself can be found in the development thread. Keep in mind that your device must be rooted and running the latest version of Xposed Framework.
December 11, 2013 By: Will Verduzco
Just two days ago, we wrote about how Android 4.4.2 was rolling out to the most recent Nexus devices. This was only four days after the Android 4.4.1 roll out. And earlier today, we took a quick look at what changed from 4.4 to 4.4.2. Now, we’re glad to report that the Android 4.4.2 source code has made its way over to the AOSP, and factory restore images are now available for the Google Nexus 4, Nexus 5, Nexus 7, Nexus 7 (2013), and Nexus 10.
Ever since Android 4.4.1 was released, we were wondering when the factory images would see the light of day. Thankfully, that day is today. And while users have been able sideload the incremental OTAs manually using adb sideload, it’s great to also have the freedom to perform a clean install, directly to the most recent version—either through flash-all.bat or by manually flashing the images directly through fastboot.
Google didn’t only provide us with new factory images for all the currently supported Nexus devices. They also released the full source code to Android 4.4.2. With this, your favorite aftermarket developers can start merging the new commits over from Google’s repos into their own builds.
End users looking to download the factory restore images can do so by heading over to the Nexus Device Factory Images page. Developers looking to start building with the new Adnroid 4.4.2 code can do so by browsing the 4.4.2_r1 source code directly on Google’s Git.
NEXUS 5 hammerhead:
NEXUS 7 2013 razor:
NEXUS 7 2013 razorg
NEXUS 4 occam:
NEXUS 10 mantaray:
NEXUS 7 2012 nakasi:
NEXUS 7 2012 nakasig:
December 9, 2013 By: eagleeyetom
Google likes surprises—we all know that. Four days after releasing the Android 4.4.1, they decided to push out Android 4.4.2, which is a bugfix release of a bugfix release. It’s probably one of the fastest releases in the history of the company.
A full list of improvements is still unknown, and hopefully we will notice what has been changed when the source comes out. Thanks to Sprint’s community moderator 4Social, we know that build KOT49H brings the following improvements:
- Fix for clearing the VM Indicator
- Fix for delivery of the VM Indicator
- Various additional software fixes
- Security enhancements
The OTA should be rolled out within next few days to all supported Nexus devices. Some of the packages are already available to download from Google servers. All you need to do is to execute the command adb sideload [file name] to flash it to your device.
The links for other devices should pop out soon, as well as factory images and proprietary blobs to download.
If you get the update, let us know in the comments below what you think about this release and if the changes mentioned above live up your expectations.
December 9, 2013 By: Jimmy McGee
Android 4.4.1 KitKat is now available for the Nexus 7 (2013) WiFi-only version. Official KitKat is also available for the Nexus 10! That and much more KitKat news is covered by Jordan, as he reviews all the important stories from this weekend. Included in this week’s news is the announcement that 2011 Sony Ericsson Xperia Devices get unofficial Android 4.4 KitKat and the article talking about browsing every AOSP code commit in Android 4.4.1 KitKat!
In other important news, Jordan talks about the announcement that CyanogenMod 11.0 M1 is available for current Nexus devices. Also, there are official OmniROM nightlies for the Samsung Galaxy S 4 LTE. Finally, Motorola open sources the Moto G! Be sure to check out other videos on on XDA Developer TV. Pull up a chair and check out this video.
December 7, 2013 By: Will Verduzco
The Google Nexus 10 is a tablet of many “firsts.” It was the first tablet to feature the supremely high resolution of 2560 x 1600 pixels. It was the first tablet to reach 300 ppi. It was also Google’s first (and only) Nexus-branded entrance into the 10″ tablet market. Despite the high end specs and affordable price, however, consumer adoption has been nothing groundbreaking. And with certain interface design choices introduced by Google in Android 4.4 KitKat, it would seem as if even they have forgotten about the device somewhat.
Luckily, however, the company still managed to provide Nexus 10 owners with a timely update to Android 4.4.1. The update is now rolling out to users in the form of an incremental update from Android 4.4 KRT16S to Android 4.4.1 KOT49E.
Since this is a staged rollout, not every device will receive the update immediately. Thankfully, however, you can download the update directly from Google’s Update Server. Once downloaded, you can easily sideload the update by executing the adb sideload <filename> command when your device is in recovery.
You can learn more over in the Nexus 10 Android 4.4.1 Update discussion thread. Have you updated your device? If so, let us know your thoughts on the update in the comments below!
For reference, all known OTA links for the current Nexus lineup can be found below:
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!