January 3, 2013 By: Former Writer
Update: Due to questionable gains and inherent drawbacks, we recommend that users please read this explanation before proceeding.
Despite some truly top notch hardware, some high end Android devices still seem to have trouble with some games. There are mods out there to fix these lag issues, as the underlying cause usually equates to some issue with the processor not working to its full capacity. There is now a new fix for Nexus 7 devices to help reduce game lag.
XDA Senior Member lambgx02 originally posted the Seeder Entropy Generator to stop lag on various Android devices. The running premise was that most game lag was caused by entropy. As lambgx02 explains:
So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.
After tracing and debugging for hours, I discovered the source of 90% of Android’s lag. In a word, entropy (or lack thereof).
Google’s JVM, like Sun’s, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.
Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
The result of fixing this issue is that games run much, much smoother. XDA Recognized Contributor bradman117 tested and confirmed it worked for the Nexus 7 and posted where more users can see it. So far, users have have reported excellent results. Installation is easy as well, as it’s a simple zip to flash in recovery.
However, if you do decide to give it a shot be aware of the very real caveats of decreased security due to inferior random number generation, as well as decreased battery life. As stated by lambgx02:
- There is a (theoretical) security risk, in that seeding /dev/random with /dev/urandom decreases the quality of the random data. In practice, the odds of this being cryptographically exploited are far lower than the odds of someone attacking the OS itself (a much simpler challenge).
- This may adversely affect battery life, since it wakes every second. It does not hold a wakelock, so it shouldn’t have a big impact, but let me know if you think it’s causing problems. I can add a blocking read to the code so that it only executes while the screen is on. On the other hand, many of us attribute lag to lacking CPU power. Since this hack eliminates almost all lag, there is less of a need to overclock, potentially reducing battery consumption.
While lambgx02 states that the risk of being exploited due to the urandom -> random seeding is low, any increased risk is too much for a daily driven device in our book. We advise all those who are interested to give this a second thought, though, due to the potential risks. However, we understand why some in heavily controlled environments, where cryptographic strength is not of high importance, may want to give this a shot. To see more, check out the Nexus 7 thread as well as the original thread.
The Nexus 7 is Google’s flagship 7 inch tablet. It represents both the ideals behind the Android Open Source Project and the commitment to quality hardware we have come to expect from Google’s Nexus line of devices. Being on the forefront of the open source realm, it comes as no surprise that the device has seen a tremendous amount of development and modification. The device has seen ports and ROM’s of every type, from Ubuntu to Jelly Bean. The latest groundbreaking piece of software for the Nexus 7 has arrived in the form of an untethered (meaning no PC connection is required to boot and run the firmware) port of HP’s webOS.
webOS suffered an untimely demise when HP decided to axe the TouchPad, but it still lives thanks to a dedicated and enthusiastic community of users who strongly believe in it. XDA Senior Member noahk423 brought the Nexus 7 port to our attention via this post in our forums. It would appear that @webosports and the Open webOS crew have released the build to the public. While previous work in this field ran little risk, the older builds were barely functional alphas that required a steady PC connection (also known as a ‘tethered installation’). The newest alpha build, a modification of the Galaxy Nexus build, requires a PC to boot, but runs on its own after that. Additionally, hardware acceleration has not been fully realized, meaning there is still plenty of work to be done.
The main point of attraction for webOS fanatics is the user interface. Maybe soon Nexus 7 owners will be able to use it as a daily driver. With all the advancements in porting and building new ROMs for the Nexus 7, it stands to reason that webOS would make its way to the device. Who knows? Perhaps the next release of the port will be compatible with the Nexus 7 Multi-Boot we reported on a couple weeks ago. Keep your eyes on the Portal for more information!
December 19, 2012 By: Former Writer
Most of the CM10.1 releases we talk about are unofficial. That’s to be expected, as most of these releases are alphas, pre-alphas, or preview builds that don’t really run well, but show that work is being done. When it’s official, it’s usually more stable. Now, there are official CM10.1 builds out for the Nexus 7 and the Samsung Galaxy Tab 2 7.0.
The Nexus 7 release was posted by XDA Forum Member eak1080. As is to be expected for vanilla Android devices, it’s pretty much ready to go. There are a few quirks that are easy to get around. For instance, the GooManager app doesn’t link to the proper GApps. So if you plan on flashing, use the ones linked. There are also separate zips for superuser and Picasa sync. Also, of course, there is the change in SD card path to /mnt/shell/emulated/. Otherwise, the ROM is perfectly stable and daily driver-ready. So if you’ve been waiting for official CM10.1 before flashing to Android 4.2, it’s ready to go.
The Samsung Galaxy Tab 2 7.0 official was posted by XDA Recognized Developer noobnl. While it is mostly stable, there are a few issues plaguing users. Some have reported that the camera isn’t working properly, and some are also having problems mounting the SD card. However, the ROM has come a long way since its initial release a few weeks ago.
One of the more talked about features of Jelly Bean 4.2 is the ability to switch users. It started as a hidden feature in earlier versions, and has become a full blown feature in Android 4.2. While it has caused some issues for some, the functionality itself is awesome. Now, there is a method to not only share devices with multiple accounts, but share apps across accounts on the Nexus 7.
XDA Forum Member jeepguy04 released an application that will allow users to share applications across multiple accounts on their Nexus 7. This is much like standard operating systems that lets all users access apps at the admin account’s discretion. The features, known issues, and other details about the app include:
- This is BETA
-You must have ROOT
- This changes system data on non documented files it could screw something up.
- I’m not responsible for any problems this causes or lost data or bricked or broken devices
- please use cation
- it is currently built to run on main user to enable or disable apps on secondary users (once root is fully working on secondary users I will see about making it run correctly on secondary user’s account)
- not tested thoroughly with paid apps*
- does not currently support system apps**
- due to the way I pull the app list from the package manager some installed apps may not show as available to add/remove
- apps installed first on a secondary user’s profile will probably not show in the list to add/remove
For paid applications, jeepguy04 believes that Google’s verification system will prevent multiple users with multiple Google accounts use paid apps. That said, we strongly suggest re-purchasing all apps that are to be shared across the accounts, even if the inherent verification system fails.
To learn more about the mod, go to the original thread.
December 10, 2012 By: egzthunder1
The Nexus 7 is one of the best devices for a few reasons: perfect size, loaded with power, easy to use, and most importantly best bang for your buck. Yes, it has a few quirks, which many of us are annoyed at like the lack of an SD card port (devs are working on this as we speak), but overall this is a great device for people getting started on Android, as well as for those who are more seasoned in the field of Android development. So, how could you make something this good even better? XDA Recognized Developer Tasssadar can answer this question with his latest creation: Multi-Boot for the Nexus 7.
You are likely familiar with the concept of dual booting or multiple booting different operating systems on your devices or your computer. However, more often than not, doing this comes at a price where you have to modify your bootloader, erase all your data, or a slew of other unsavory things that most people outside of our little world would rather not do. This tool saves you from all of the above, as it does not touch the /system partition on your device, nor does it wipe your data. That said, there is an inherent risk of wiping your data or even damaging your device, as it does mess with the /data partition and boot sector. However, if everything works the way it should, your system and data should be safe. So, what can you run with this? Pretty much anything that you want: other versions of Android (as long as the ROM is made for the device, of course), different versions of Linux such as Ubuntu, and more.
Currently, the only caveat is that the ROMs will need to run from the internal storage, but the dev is hard at work trying to get around that issue to enable booting the images through USB.. Oh, and for those of you with 3G versions, you are covered as well. Please take this for a spin and breath new life into this small powerhouse.
MultiROM is multi-boot solutiom for Nexus 7. It can boot android ROM while keeping the one in internal memory intact or boot Ubuntu without formating the whole device. For now, ROM can be only in internal memory of the device, but booting from USB is planned, I am trying to get support for kexec into Ubuntu, which is essential for this.
You can find more information in the original thread.
Want something published in the Portal? Contact any News Writer.
[Thanks Diamondback for the tip!]
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.
One of the more fun ways to customize an Android device is by giving it a custom boot animation. OEM and carrier boot animations are lacking most of the time, and many don’t spend a lot of time looking at the boot animation. Some, like flashaholics on the other hand, spend quite a bit of time staring at boot animations. Now there is a very in depth tutorial that helps users create their own boot animations for the Google Nexus 7.
XDA Senior Member AFAinHD has written a very in depth tutorial on creating your own boot animations. During the tutorial, AFAinHD explains various things like what file type the images in the animation have to be, proper naming conventions, proper file organization, and even installation instructions.
Perhaps the best part is a clear and easy explanation on how the desc.txt works. For those who don’t know, the desc.txt is a text file embedded in the boot animation zip file that tells the device the proper information needed for running the boot animation. So users will learn how to do things like adjust the animation frame rate, the resolution, and how many times to play the various parts of the animation. This tutorial can also easily be extrapolated to other devices as boot animations on other devices are assembled the same way.
For additional details, go to the original thread.
November 13, 2012 By: Haroon Q. Raja
Earlier today, we brought you news of the Andriod 4.2 OTA update for GSM/HSPA+ Galaxy Nexus in the US, and Android 4.2 factory images for Galaxy Nexus, Nexus 4, Nexus 7, and Nexus 10. While that’s enough to get end users excited, Google isn’t leaving ROM and app developers behind either. Android 4.2 Jelly Bean has been pushed to the Android Open Source Project, and the Android SDK has bee updated with 4.2 based API17.
News of the AOSP update was shared with us by XDA Forum Member dilwaala, and soon afterwards the SDK update followed. With the AOSP update, ROM developers can now incorporate the latest Android source code, meaning we should start seeing plenty of 4.2-based AOSP ROMs for a range of devices pretty soon. When it comes to the SDK update, it will allow app developers to utilize the latest APIs provided in Android 4.2 when developing their apps.
Last but not the least, Google has made the latest Android 4.2-based proprietary binaries available for Galaxy Nexus, Nexus 7, and Nexus 10. This means full hardware support for these devices in custom ROMs. For some reason, Nexus 4 has been entirely left out of AOSP for now, with no source or binaries published. According to AOSP Tech Lead JBQ, there’s no ETA on those yet either.
November 13, 2012 By: Haroon Q. Raja
The past few hours have been quite exciting for Nexus device owners. Earlier today, Google started rolling out the Android 4.2 Jelly Bean OTA to the Google Play variant of the GSM/HSPA+ Galaxy Nexus (takju). The OTA update file was shared with us by XDA Senior Member HAKA, along with installation instructions for all GSM/HSPA+ variants of Galaxy Nexus (yakju and yakjuxx). The method involves first installing the latest 4.1.2 takju factory image on non-takju devices, to be able to install the 4.2 update. However, there is no longer any need for that.
Hours ago, Google uploaded Android 4.2 factory images for not just the Galaxy Nexus, but also for Nexus 7 (both WiFi and GSM/HSPA+), Nexus 10, and Nexus 4. While an official yakju image for Galaxy Nexus is still not available, the takju factory images can directly be installed to any yakju or yakjuxx device.
In case the code names have your mind in a jumble, takju is the Galaxy Nexus variant sold by Google in the US Play Store, which comes with Google Wallet pre-installed. Yakju is the exact same device sold internationally by Google, but doesn’t ship with Google Wallet. Yakjuxx is the exact same device sold internationally by Samsung. Google directly updates takju and yakju, while yakjuxx devices are updated by Samsung.
You can download factory images for all these devices at the Android Developers Website.
The wonder of being part of a community like XDA is that it doesn’t take long before someone catches an inspiration and starts finding ways to put different flavors of an OS on their device—or even a different OS entirely. One need only look at the HTC HD2 to find the perfect example of that inspiration with Windows Mobile 6.5, Android, Ubuntu and Meego all making an appearance on what was arguably one of HTC’s most notable devices. Every time a new, more powerful device comes along, it isn’t long before threads talking about how to load Ubuntu on that device start popping up. Most of the time it is in the form of such methods as chroot, but occasionally you’ll find someone like XDA Recognized Developer lilstevie porting full-blown Ubuntu to devices like the ASUS Transformer TF101.
A while back, Ubuntu informed the tech world that they would be bringing the full Ubuntu experience to dual-core Android phones, but the “how” was shrouded in marketing-speak for “we’ll leave it up to the carriers to figure out how to deploy it.” With the release of the Google Nexus 7, the first Nexus tablet, came the natural interest to get Ubuntu loaded onto this device and Canonical rose to the occasion.
Last week, Ubuntu released the Ubuntu Nexus 7 Desktop Installer, a one-click process for installing Ubuntu 12.10 onto the Nexus 7. While it is only a developer preview and not a final release, it has been reported that the process works really well and is relatively stable. Mark Shuttleworth, founder of Ubuntu, was quoted on OMG! Ubuntu as saying:
“We’ve said that the driver of Unity was to build an experience that spans phones, tablets, desktops and tv. I think we can do that by 14.04.
So in 13.04 we’re focused on tuning the performance of the base system in mobile settings - memory footprint, boot performance, battery life, etc.
We’ve ported Ubuntu to the nexus 7 (it’s just the desktop) and will all be focused on that for 13.04.”
It’s always fun to see AOSP-derived, source-built ROMs released for a variety of devices at once. Whether it’s for five devices or for 14 devices, large scale releases mean that if you upgrade, you may be able to run the same ROM you’re already familiar with.
Team Liquid has recently released RC7 of their AOSP ROM to seven devices. The last time we talked about them, it was their RC3 release. The devices that got the release include both versions of the Galaxy Nexus, the Nexus 7, and all versions of the Galaxy S III except for Verizon’s.
The ROM has undergone a variety of changes. Here are a few of the highlights along with the Team Liquid members responsible for each:
◘ Added Navbar widgets/Resizable Navar Widgets – Zaphod-Beeblebrox
◘ Custom navbar targets for tablets/Tabui – Stevespear426
◘ Addded group mms threading – viekvanasani
◘ UI overhaul including Lockscreen Shortcut Bugfixed and power widget fixes – Danesh
◘ Added special Paranoid Android Sauce – Credit Paranoid Android
◘ Added USB Mass torage support for tablet mode – DAGr8
◘ SystemUI-Fix menu button in landscape – Zaphod-Beeblebrox
◘ Fix H+ and add new navbar widget icon – kwes1020
◘ “Death by subtlety” aka updated holo pngs – ToxicThunder
◘ SystemUI: Recents Ram Bar – Stevespear426
◘ Security hole fix (prevent logging of lock pattern) – CM
◘ Added home button unlock option – invisibleK
◘ Bugfix for samsung usb dock events – StevenHarperUK
◘ Make toggles hidable – Stevespear426
◘ Add setting to allow haptic feedback on toggle press -gdanko
◘ COMPLETE SETTINGS LAYOUT/ICON OVERHAUL – ToxicThunder
◘ Added support for wired headset detection – Sudhir Sharma
◘ Fix for UI LockUP with headset insert/removal – Ravi Kumar Alamanda
◘ Show more info during boot dialog (i.e. “package _ of _ is being optimized”) – JbirdVegas
◘ Fix NFC Toggle not working if it was not on @ boot – sethyx
◘ Huge Liquid Splasher overhaul including strings/summaries, layouts – Liquid0624
◘ KT747 10/28 kernel and Ktweaker for D2xxx U.S. builds – Ktoonsez
◘ Leankernel 4.5.0 for toro, maguro – Imoseyon
◘ Leankernel 0.3 for grouper – Imoseyon
Check out the release threads by XDA Recognized Developer toxicthunder below:
The Nexus 7 screen lift issue is a pretty well known issue on the XDA forums. For those who heaven’t heard, it is when the screen separates from the frame by a noticeable amount. There are many ways to fix it. Some have tried tightening the screws and removing the black foam strip. Others have tried the much more effective washer method. There is another way though—one that involves glue.
XDA Senior Member ckl_88 has posted a method that uses glue—specifically epoxy and not super glue—to fix the screen lift issue. In this method, users take the device apart, use toothpicks to prop the screen up slightly, and administer the epoxy. Once finished, they put the screws back in, and rubber band the device. After checking to be sure that the screen lift isn’t there, drop a phone book on it and find something else to do for about 12 hours.
This method has seen some success and ckl_88 has said that the Nexus 7 was put through a considerable amount of testing afterward without the screen lift coming back. While it is a little more messy than the washer method, it gives users another shot at fixing their device if the washer method doesn’t work.
XDA Forum Member shadeygeezer wrote up a similar method in ckl_88′s thread. In shadeygeezer’s method, you play the Transformers movie—or any other movie—on repeat for a little bit, then wrapped it in rubber bands and dropped a phone book on it. After leaving the movie on repeat for a few hours, leave it sit for 12 hours still with rubber bands and the phone book. Essentially, this is the same method as ckl_88′s but doesn’t involve taking the Nexus 7 apart and breaking the warranty. The logic being that you can reheat the glue already in the Nexus 7 and reset it.
While these will all likely help with the screen lift issue, none of them is really a permanent fix. To see more of the glue fix, check out the original thread. Here’s hoping Google’s next attempt at a tablet doesn’t have this problem.
October 17, 2012 By: Former Writer
Usually when we think of pairing a wireless controller to an Android device, it is a Playstation 3 or Wii controller. While there is certainly nothing wrong with this, there are those who simply prefer the Xbox 360 controller. While the wired variant has worked on Android natively for a while, there is now a way to get a Wireless Xbox 360 Controller working on a Nexus 7.
XDA Senior Member sleeplessninja has figured out how to get a wireless Xbox 360 controller working on the Nexus 7. Usually, for Xbox 360 controllers, you need a wired controller and a USB OTG cable. There is already a way to get the controller working on the Nexus 7 using a Xbox 360 Wireless Controller Dongle, but there are a lot of games that still can’t register the controller properly.
This issue has been fixed. As sleeplessninja explains:
So when i searched through the /system/usr/keylayout/ I saw there was a profile for the xbox 360 wired controller so I thought why not copy the profile and name it a wireless xbox controller. This idea worked. You name keylayouts by Vendor ID and Product ID which I also was able to get from the logcat. What is nice about this is I think we can use this to solve issues with other controllers as well, but I don’t know of any that are also having problems.
So once the simple modification has been made, you can use a wireless Xbox 360 controller to its fullest potential. And, as stated, this method could be used to fix issues with other controllers. To learn more, head to the original thread.