Bootloader cracked and next steps

Search This thread

nemith

Senior Member
Jun 20, 2010
218
456
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

Here is how i see the next steps:

  1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

    For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

    This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

  2. Finish CWM. 100% done.
    Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645

  3. Work on CM9 for both SDcard and internal booting

    See Below



So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

So PM me or come to #nook-tablet @ freenode
 
Last edited:

nemith

Senior Member
Jun 20, 2010
218
456
Reserved

Bootstrap-loader (Goal #1)
Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.

Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc

So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.

fclxG.png


This would also allow us to completely replace recovery with CWM.

Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority


CM9 (Goal #2) Inprogress
There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.

There is a number of kernel changes that need to be done:
  • Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.

    This will allow us to a) have revision history b) allow merging up to 3.0 easier

    This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
  • Backport key changes (fattire probably has this already done)
  • Backport usb gadget
  • Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
  • Backport

Current Status:

oimg




Teasers:

L9lxM.png
 
Last edited:

Loglud

Senior Member
Jul 29, 2011
235
449
Wow. Thanks nemith for all the info. I will work with you and 100% will give the donation to them (verbal and writen agreement). From when I was building CWM on the GNex I remeber having to change one of the values in the .mk file to allow for adb.
 

bauwks

Member
Jan 8, 2012
16
151
Hi nemith,

That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions :).

I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git

So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:

(cd to u-boot directory and switch to second-uboot branch first, then)
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_irecovery
make
./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size


Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.

There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.

I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens ;)

Update:

I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N

So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

Here is how i see the next steps:

  1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

    For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

    This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

  2. Finish CWM. 100% done.
    Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645

  3. Work on CM9 for both SDcard and internal booting

    Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)



So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

So PM me or come to #nook-tablet @ freenode
 
Last edited:

fattire

Inactive Recognized Developer
Oct 11, 2010
2,280
6,473
www.eff.org
A bit on UI, cleanup, and various boot scenarios

Bauwks.. cool, glad emmc is is a go.

Current Status: Fattire working on a menu for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into

UB2 update from me: A fruitful night with lots of fun enhancements, some modest UI feedback, and a sprinkling of safety/sanity fixes and other tweaks. SD and emmc options should be more convenient/consistent now, with recovery selection effectively handled by UB2 not UB1 (though power+n will remain an option obviously). I'll let nemith elucidate.

Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?

Considering I don't have an NT and I'm working blind here with nemith testing... I think this could wind up pretty nifty.
 

dhkr234

Senior Member
Jan 27, 2011
575
157
Update:

I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N

Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
 
  • Like
Reactions: bauwks

fattire

Inactive Recognized Developer
Oct 11, 2010
2,280
6,473
www.eff.org
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?

Yeah. Or more specifically, everything in those partitions will need to be shoved over by a set amount to make room for UB2.
 
  • Like
Reactions: bauwks

bauwks

Member
Jan 8, 2012
16
151
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?

Hi fattire,

I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".

But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.

By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
 

CelticWebSolutions

Senior Member
May 25, 2011
855
2,012
I can't really offer much as I am no android developer. I can modify basics and work thinsg out through educated trial and error but most of what you guys have been on about has been way out of my league. If it makes any difference I have 2 NTs one of which is brand new in a sealed box just sat waiting for the correct time to bother getting it out to play.

I'm quite happy to do testing, tweak things and do what I can where required.

Not sure what happened about the reward thing but as has been said before I think giving it to a good cause is a very decent and honest thing to do.

Doing it and donating the 'winnings' to a good cause is a far better idea and I commend you for following that route. Those that do it solely for the money aren't doing it for the reasons that I think XDA exists and from what I've seen before often get their money out of blatantly using other members hard work to make themselves look good, there always seems to be a lot of sitting on the fence then diving in at the last second and releasing something as their own when most of it isn't.

Anyway, enough babbling from me! Keep up the good work and when you think I can be of any help I will be more than happy to chip in where required.
 

dhkr234

Senior Member
Jan 27, 2011
575
157
Hi fattire,

I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".

But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.

By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).

Presumably, the partition table is write protected along with the xloader and bootloader partitions, right? Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...). Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
 
Last edited:

fattire

Inactive Recognized Developer
Oct 11, 2010
2,280
6,473
www.eff.org
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right?

Nope.

Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...)

Nope.

Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.

This is not the g2. It's not a write-protected emmc and a power cycle of the emmc will do nothing. I appreciate the enthusiasm, but you're coming to this very late.
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,280
6,473
www.eff.org
More rambling...

If I'm not mistaken, the way you're suggesting is UB2 would be a prepended portion of the boot and recovery images as part of a "package", and this is how we were already discussing doing it in the cm9 build system-- this also matches in effect how Nook Color CM7 distros work-- the bootloader is actually re-installed with every update.zip (to enforce compatibility as newer versions of Android require newer u-boot).

However, I was considering that some people want to swap various u-boots in and out of existing boot or recovery partitions without necessarily having to push aside the rest of the image to make room. So if they're thought of as a unit, it makes total sense to do it as you suggest- but if UB2 is something that can be replaced (or updated) independently, then maybe a standard "buffer" size would be more appropriate.

We've talked about a few ideas- if a simpler boot menu is used to replace UB2, or a redirection to "see other partition for bootloader"... then it could be 512K (or whatever) mostly wasted... which may not be a big deal either.

Anyway, just typin' out loud. Lots of options, and no "right" way to do it.

Hi fattire,

I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".

But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.

By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
 
  • Like
Reactions: Eustace2

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,809
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
aversion of single-point-of-failure

I'd like to recommend, to avert the Single Point of Failure, a manditory and automatic backup of the /ROM/ partition. Since you're developing the first custom kernel, there will be a lot of work based upon yours for this device.

This can be handled in the init scripts. after /ROM/, /system/ and /sdcard/ mount. If the /ROM/ folder is available and there is no backup, make one. This simple step can save alot of grief in the future in case of damage.

Untested code:
Code:
#! /bin/sh
ROMBACKUPDIR="/sdcard/backup/ROM/";
BACKUPFILE=$ROMBACKUPDIR"ROMPARTITION.img";
TESTFILE="/ROM/NAMEOFANYFILE";
ROMPARTITION="/dev/block/***";
busybox test ! -e $ROMBACKUPDIR && mkdir --parents $ROMBACKUPDIR;
#no backup detected, so make one.
busybox test -f /ROM/$TESTFILE && busybox test ! -f $BACKUPFILE && busybox dd if=$ROMPARTITION of=$BACKUPFILE;
where ***=the ROM partition on your kernel and NAMEOFANYFILE=the name of any file on the /ROM/ folder
 
Last edited:

Loglud

Senior Member
Jul 29, 2011
235
449
Whomever is building the AOSP!!!

Be careful with the ICS 4.0.3. There are alot of issues with the way the AOSP market place is working with it. The 4.4.3 Market has a tendancy to crash continually. Might be worth building ICS 4.0.2, and using that to elimitate all the problems whe can.
 
  • Like
Reactions: Land Master

hkvc

Senior Member
Jul 6, 2011
83
240
Congrats to everyone who cracked it finally :)

I can say with 90% surity that You can recover a junked ROM partition or for that matter a fully junked eMMC, for the simple fact that it gives other pheriperals a chance before booting into eMMC (cannt say 100 % by myself immidiately now, because have been busy with other stuff at work over the last week, so my memory FIFO wrt my experiments on NookTab is bit blurry now).
 

Top Liked Posts

  • There are no posts matching your filters.
  • 111
    So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

    This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

    Here is how i see the next steps:

    1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

      For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

      This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

    2. Finish CWM. 100% done.
      Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645

    3. Work on CM9 for both SDcard and internal booting

      See Below



    So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

    If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

    So PM me or come to #nook-tablet @ freenode
    56
    Reserved

    Bootstrap-loader (Goal #1)
    Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.

    Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc

    So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.

    fclxG.png


    This would also allow us to completely replace recovery with CWM.

    Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority


    CM9 (Goal #2) Inprogress
    There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.

    There is a number of kernel changes that need to be done:
    • Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.

      This will allow us to a) have revision history b) allow merging up to 3.0 easier

      This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
    • Backport key changes (fattire probably has this already done)
    • Backport usb gadget
    • Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
    • Backport

    Current Status:

    oimg




    Teasers:

    L9lxM.png
    39
    Holy balls!

    Just talked to chrmhoffman...

    <chrmhoffmann> [email protected]:/ # cat /proc/pvr/version
    <chrmhoffmann> Version CustomerGoogle_Android_ogles1_ogles2_GPL sgxddk 18 [email protected] (release) omap4430_android
    <chrmhoffmann> System Version String: SGX revision = 1.2.0


    Holy COW! It worked! The 1.8 pvr driver frankenstein actually worked. He had to make a change to the Makefile and another to defconfig, but he now has the 1.8 galaxy nexus/tuna binaries running on NT!

    WOW.

    TqFmPl.jpg
    ]
    It. ****ing. worked.

    Now he can do some stuff he couldn't before, like choose a wallpaper. He's also got OPENGL_RENDERER on, which is great too. I think it could make a diff for battery life.

    One thing not in yet is hwcomposer (it wasn't running before though with 1.7), because it's not supported in our kernel and needs a ton more work.. so maybe that's somethign to backport as well. Although I see a 3.0 effort has started, so maybe I should wait. This is video-related...

    (In other news, while I was waiting, I added a new altboot/emmc feature to u-boot, but it hasn't been tested yet...)

    So New ToDo List:
    ---------------------

    Update to 1.8 glx/pvr driver/get off legacy egl
    mount SD/screenshots (same thing)
    MTP/PTP USB mounting
    microphone (there is one, right?)
    stability (should never, ever crash on sleep)
    build should generate flashable update.zip
    BlueTooth (on hold until gpio is figured out)
    hwcomposer/OMX (on hold pending 3.0 kernel)


    As for hwcomposer-- here's what it is, according to TI:

    During composition, SurfaceFlinger now calls the new Android HWComposer HAL component to enable composition of graphics or video layers using the underlying OMAP system-on-chip (SoC) capabilities. The OMAP platform implementation of HWComposer works with DSSCOMP to dynamically assign layers for composition by the four DSS pipelines available in the OMAP 4 architecture and to configure the output destination for each layer This provides the flexibility to assign the DSS pipes to different content and different display destinations for every display frame.

    This distributed composition architecture ensures that SurfaceFlinger can use GPU composition of UI and video for complex UI transitions, while optimizing power during normal composition using DSS pipelines. When required SurfaceFlinger composites UI layers through the GPU to required, provide smooth video rotation, effect filters, or texture mapping to 3D text surfaces. At other times, SurfaceFlinger can conserve energy by reducing GPU computations by sending layers directly to a DSS pipeline, pipeline allowing the GPU to sleep reducing system memory bandwidth sleep, consumption, and eliminating up to 48 percent of MPU load. This load Android enhancement provides a more unified solution for GPU and DSS rendering than was possible with SurfaceFlinger and TI Overlay Object used in Android 2.

    So there you have it.
    33
    Hi nemith,

    That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions :).

    I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git

    So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:

    (cd to u-boot directory and switch to second-uboot branch first, then)
    PATH=/usr/local/arm-2010q1/bin:$PATH
    make nt2ndboot_irecovery
    make
    ./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
    dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size


    Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.

    There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.

    I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens ;)

    Update:

    I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N

    So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

    This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

    Here is how i see the next steps:

    1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

      For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

      This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

    2. Finish CWM. 100% done.
      Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645

    3. Work on CM9 for both SDcard and internal booting

      Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)



    So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

    If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

    So PM me or come to #nook-tablet @ freenode
    27
    Cm9 may be in limbo right now because the 3.x kernel is being ported over and in the long run will be more benificial than backporting all the ICS features to a 2.3 kernel. I have noticed Indirect has backed out of development and i think Neimith has been occupied wirh a new VM server. For info check out porting over 3.x. Thread in the development section.

    Actually, I decided to risk my sanity for the benefit of the community. Be grateful. :p

    Sent from my Nexus S 4G using xda premium
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone