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 19, 2013 By: Jimmy McGee
At the beginning of this year, Canonical announced that it was making an alternative mobile device operating system, called Ubuntu for Phones. With its lack of need for hardware buttons and use of screen sides as hot zones to initiate gesture commands, the underlying UI concept was vastly different from Android.
On the 15th of February, Canonical announced that the Touch Developer Preview of Ubuntu for the Galaxy Nexus and the Nexus 4 will become available on the 21st. This is intended for developers and enthusiasts to get used to Ubuntu’s smartphone version. This same day tools and instructions for flashing this to devices will be released on the Ubuntu Wiki.
It is interesting that Canonical chose to release Ubuntu Touch on two Nexus devices. The Nexus line is known to be “Google’s flagship” device group. Perhaps the developer openness of the Nexus line is what allows Ubuntu to be flashed to the device. Additionally, Canonical has announced that attendees at this year’s Mobile World Congress will be able to stop by their booth and have the release installed onto their smartphones.
Also, Canonical has announced that smartphones aren’t the only devices that Ubuntu’s touch-based smartphone operating system will appear on. Ubuntu announced today, “Ubuntu for Tablets.” This adds another layer to the unified ecosystem that Canonical is trying to create: one interface for all your connected devices. However, some people, like KDE’s Plasma Active team leader Aaron Seigo, claim that while the graphics may look the same, the code, is in fact completely different, which could prevent seamless application integration between devices. Only time will tell if this issue actually crops up.
While at CES this year XDA Developer TV Producer Jordan and I got to see an Ubuntu for Phones demonstration. It is very likely that with the unification effort in the Ubuntu ecosystem, that Ubuntu for tablets will be very much similar, if not the same.
Additionally, Jordan asked Ubuntu Community Manager Jono Bacon some questions about Ubuntu for Phones. Some of the answers did not have a clear answer, let’s hope they have come up with clever solutions to some of these concerns.
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 19, 2013 By: jerdog
At the end of last year, we started selling XDA cases with our friends at CruzerLite, and we’ve seen some phenomenal interest. Our current lineup is the Samsung Galaxy Note 2, Samsung Galaxy S III, Samsung Galaxy Nexus, and the Google Nexus 4—but we want to add more. So we have decided to hold a poll and let the users choose which device(s) to add to our current lineup.
Below you will find some of the top devices at XDA. Please choose one from the list that you would like to see offered, and we will pick from the top 3 devices. The voting ends on February 15, so make sure you place your vote for the devices you love!
EDIT: The results are in, and displayed below. We’ll keep you updated as to the final options when they become available.
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.
January 2, 2013 By: Haroon Q. Raja
If you visited the Ubuntu home page early this morning, you couldn’t have missed the countdown timer that promised something, “So close, you can almost touch it.” Most assumed it to be about a fully touch-optimized UI for the next version of the popular Linux distribution, but it turned out to be something even more significant. In an announcement earlier today, Canonical unveiled Ubuntu for phones, a fully working Ubuntu distribution meant for existing and future mobile handsets.
If you are thinking “Wait, wasn’t Ubuntu for Android already announced last year,” you aren’t alone. Upon first hearing the news, that was the first thing that came to my mind as well. However, this is a whole different project with a much more ambitious aim and broader scope. While Ubuntu for Android was built to run in tandem with Google’s mobile OS to offer a full Ubuntu desktop experience only when docked, Ubuntu for phones is a complete OS in and of itself, entirely independent of Android. Before we get into the details, check out a hands-on video courtesy of The Verge. You will notice significant amounts of lag, but don’t be alarmed because this could be due to this being a development build that is not yet ready for release.
Here’s another, much more detailed 22 minute video featuring the founder of Canonical, Mark Shuttleworth himself, presenting Ubuntu for phones:
An announcement like this one is bound to receive mixed reactions. The Linux and Ubuntu enthusiasts among you must be rejoicing at the idea of getting an official and fully native Ubuntu experience that’s tailored for the small screen, rather than being a mere port of the desktop OS. At the same time, the skeptics must be wondering why on earth Canonical decided to release yet another mobile OS. With Android and iOS dominating the mobile ecosystem, the chances of a new smartphone platform thriving don’t seem too bright. After all, we’ve seen the lack of commercial success in Windows Phone, which despite Microsoft’s efforts over the past couple of years, has yet to grab significant smartphone market share. Though before we jump to conclusions, let’s give Ubuntu for phone a fair chance to at least present itself. So enough talk, let’s take a look at what Canonical has to offer the smartphone world.
From the details provided by Canonical and what can be seen in The Verge’s hands-on video, the OS clearly derives significant inspiration from the excellent but ill-fated Nokia N9. There are no on-screen or on-device buttons (it is running on a Galaxy Nexus, after all); and the OS is entirely gesture-driven. Edge-initiated swipes can be a great way to launch and navigate between apps, as we have already seen in case of the N9, and Ubuntu for phone makes full use of these gestures. Here’s how the UI works:
Based on the above, the user experience offered by the UI itself seems outstandingly intuitive. It was a pity to see this excellent gesture-driven interface not make it to the masses in form of the N9 due to Nokia’s decision to ditch the platform, and we hope things fare better for Ubuntu.
Smartphones of today have become powerful enough to be useful as our daily use PCs, but their size and form factor makes them unsuitable for getting serious work done. We have previously seen several attempts to do this by the likes of ASUS and Motorola, some of which have been successful in their niche, while others have faded into obscurity. One issue that keeps manufacturers from converging several devices into one is obviously commercial interest. It doesn’t seem to be a smart business choice to sell a phone that does it all for most users, when you can sell the same user a phone, a tablet, and a laptop or desktop PC. Nevertheless, with ~2 GHz quad-core processors, multi-core GPUs, 720p & 1080p HD displays, 32/64GB internal storage, and 2 GB RAM becoming the norm, this convergence is bound to happen sooner or later. While the likes of hardcore gamers, graphic designers and video editors will still buy PCs, these powerful phones have already adequate power for the average user who primarily only needs to play casual games, edit some documents, watch videos, listen to music, and browse the Internet.
With Ubuntu for Android, Canonical had aimed to converge our devices into one, offering a full desktop computer experience right from our phones when docked with a display, keyboard, and mouse. The same docking support is also there in Ubuntu for phones. Canonical aims to offer the OS on both mid-range and high-end devices, and the latter will be able to offer a full PC experience, allowing you to use your phone as your primary computer that you can carry around wherever you go. Being optimistic, we can even start expecting laptop and tablet terminals that only offer the screen, I/O devices, a few extra ports, and high-capacity batteries. These will then use our phones for the computation work itself, just like the ASUS Padfone.
From what we have seen above, things definitely look great for Ubuntu. Though the UI or docking support alone can’t offer a great experience, which brings us to the ecosystem.
Ubuntu for phones will ship with all the core apps you would expect from any mobile OS such as phone dialler, SMS & MMS, web browser, email client, camera, photo gallery, music & video player, calculator, alarm clock, and so on. Furthermore, all popular HTML5-based web apps will be readily available for the platform, and will work side-by-side with native apps, complete with their own icons and access to the notification system.
Apart from the web apps, the platform will also enjoy fully native third-party apps. And unlike Android, there will be no Dalvik virtual machine, which will force these apps to be written in native code. If you are a developer, this will be your primary interest, so let’s take a look at what the platform has to offer the developer community.
We have seen on multiple occasions (webOS and BlackBerry) how developer interest can truly make or break a platform. With almost every modern smartphone out there offering the hardware specs and every smartphone OS offering all the core features required from such devices, the number and quality of apps available for the platform is truly the deciding factor for many users when purchasing their next phone or tablet. This may be a little too early to say right nowm but in case of Ubuntu for phone, the future doesn’t look dark in this regard—even if not too bright just yet.
Canonical made the excellent choice to make Ubuntu for phones not a separate OS from its desktop variant, but rather the very same OS, merely with a different UI. This means apps written for Ubuntu PCs will run on Ubuntu phones and vice versa, with only minimal changes required in the code to support the different form factor and instruction set. The already established Ubuntu Software Center will also cater to phones as the application discovery, distribution, and installation platform. Ubuntu One is also integrated into the OS as the cloud storage medium offering plenty of free space, with optional paid upgrades for those who need them.
While only time will tell whether Ubuntu for phones stands against its major competitors in an already saturated market, or ends up suffering the same fate as webOS or Meego, the concept as well as the product itself are both promising. What we do see right now is a well-built OS, a promising app ecosystem, and the much-needed convergence between platforms. Combined together, these are all ingredients for success in this industry. That said, how things actually turn out will also heavily depend upon manufacturer support, as well as the marketing strategy adopted by both Canonical and device manufacturers.
While you can’t try out the OS at the moment, Canonical has promised to make Ubuntu for phone available for several existing devices within this year, starting with the Galaxy Nexus. CES 2013 is just under a week away, and more details will be revealed at that time. Furthermore, you’ll be able to grab the binaries of the OS for your Galaxy Nexus within the next couple of weeks. However, devices with Ubuntu pre-installed aren’t expected to start shipping before 2014.
So what do you think of this newest combatant in the smartphone arena? Join the discussion and let us know in the comments below.
When a community becomes as large as XDA, it’s hard to find things that everyone agrees one. One of those rare things is that Google Apps would be so much better without silly carrier and country restrictions. Google Wallet should work on every Android device with NFC, and Google Music should work everywhere. There is one less app with country restrictions now and it’s GoogleEars.
For the unfamiliar, GoogleEars is a sound search widget that helps identify various sounds or music. This functionality has even been added to the latest build of Google Search. XDA Senior Member manumanfred has modified the GoogleEars APK so that it’s usable in every country. As manumanfred explains:
I moved my modified GoogleEars.apk to /system/app/ and I changed permissions and then I rebooted my nexus and went to system/app/ and I installed GoogleEars.apk and then I rebooted my nexus again and widget is still here and it’s not frozen anymore..
So this works well, You can use it without need to defrost it every time when you have booted your phone again… This is just modified to work on the blocked countries..
This is really cool if you’re in one of the many countries that can’t access every Google service. So far, users have reported it working in Germany, India, and Canada. It was released for the Samsung Galaxy Nexus, but it should work with any Android 4.2 AOSP ROM at least, and possibly more.
For more info, check out the original thread.
December 2, 2012 By: Former Writer
Most are aware that unlocking the bootloader on Nexus devices typically wipes the /data partition. You can sometimes root without unlocking the bootloader, backup data through a root-enabled app, unlock your bootloader, and then restore your data. However, most would prefer not to go through that hassle. Now, you can unlock as normal, and get that wiped data back.
Usually the operating system will just delete the reference pointer in the index that says that a file exists with such-and-such name and it’s located at this position on the hard disk / memory location…The issue is that data recovery tools need an actual mounted drive in order to dig deep and unearth those funny pictures of cats you so tragically deleted by accident. These newest batches of phones don’t have external SDcards which are super easy to mount as drives. Internal memory mounts as MTP/PTP which is not treated as a mounted drive and cannot be scanned by these data recovery tools.
Thus, a method was created to scan those drives and recovered the data. The method is for the Galaxy Nexus, but should actually be compatible with any device with an internal SD card. While it is for use on Windows 7, it should be easily translated over to Linux. It’s a pretty long process, but after following it, users will be able to use their favorite data recovery tool on their devices to recover the lost data.
For the full instructions and more info, check the original thread.
November 27, 2012 By: Former Writer
Every new version of Android brings changes. Not only visible changes, but also under the hood changes. Sometimes they can be pretty big too. Just ask the folks in the Samsung Epic 4G forums, who had to switch to the MTD Partition Map. Android 4.2 saw the addition of multi-user support (on tablets), and some people, specifically those with a Samsung Galaxy Nexus, have faced SD Card formatting issues as a result.
XDA Senior Member k786 explains the problem more in depth:
After upgrading to 4.2 the sdcard format changed due to the addition of the multi-user feature, and because of this users were having issues with many “0” folders being created in their sdcard when they flashed new roms in recovery, the recoveries were updated but the problem existed for many users. so this guide is a way to keep the internal storage as data/media instead of the new format data/media/0
As mentioned, k786 wrote a guide that helps get you to Android 4.2 without changing the SD card formatting. The method isn’t difficult, but it does take a while. Users have to backup, and subsequently restore, their entire /data/media. That could be several gigs, depending on what is on your Nexus. From there, users install a 4.2 Google image, restore the backup made earlier, check to see if there are any discrepancies, and then finally flash TWRP. After that, users should be able to flash any 4.2 ROM without their virtual SD card data moving from /data/media.
To learn more, check out the original thread.
As PACMan continues to spread like wildfire, users are starting to embrace the ROM’s unofficial motto: “Why choose when you can have it all?” For those who are still unfamiliar, PACMan ROM is a kang ROM that combines the best features of CM10, AOKP, and ParanoidAndroid. Since it was first released, it’s been gaining momentum. Now, Samsung Galaxy Nexus owners can get in on the fun.
XDA Senior Member [vertigo] has released the AOSP kang for the Galaxy Nexus. As one would expect, it has features from the three biggest AOSP-based ROMs. This includes CM10 settings, AOKP Settings, and ParanoidAndroid settings—plus all the interconnected cherry picks you could ever wants.
For most devices, there are usually some bugs due to the lack of proprietary binaries that are compatible with AOSP. The Galaxy Nexus obviously doesn’t suffer from these issues, so there are virtually no bugs to speak of. However, the ParanoidAndroid crew have asked that the ParanoidPreferences.apk be taken out of the ROM. It can be grabbed from any ParanoidAndroid ROM, though, so it isn’t that big of a deal. Also, this is only for the GSM version of the Galaxy Nexus. The Verizon and Sprint versions have to wait just a little longer.
For more details, check out the original thread.