Related
I'm no longer keeping up with NAND on the vogue. So if anyone would like to keep me informed and email me or post me on any changes with NAND, ill be happy to add the news on the first post. The lock up issue with NAND has been fixed!
This is simply for any noobs or others who are having issues with Android and NAND.
IMPORTANT!!!
FOR VOGUE USERS ONLY
I am not responsible for any bricked or messed up devices. By continuing you are agreeing to my simple rule.
MY SIMPLE RULE: I owe you nothing.
I will help you through the way though if you bricked or need any sort of help.
How-to Video up NOW!!!
http://www.youtube.com/watch?v=3gTkJkOc7m4
First off, What is NAND?
To keep it simple...its your phones internal memory. Up untill recently we (Vogue Users) had to run Android off our SD cards using HARET. But thats another story.
What are the benefits of running from NAND? (based on what I have seen)
-Runs faster
-Longer Battery life
-faster boot up
-can be faster to put together.
-Easier to connect your vogue with android to your pc and sync
-Much more convenient.
So how do I start?
STEP1:
The Build
First you need to find a Build that is usable with NAND. Most Hero builds at this moment are not. Here are some links:
Donut 1.6
http://forum.xda-developers.com/showthread.php?t=591104
Hero
http://forum.xda-developers.com/showthread.php?t=603028
Cupcake 1.5
Method 1 from http://forum.xda-developers.com/showthread.php?t=593786
DO NOT DOWNLOAD ANYTHING JUST YET! I WILL TELL YOU WHEN A GOOD TIME WOULD BE
You may want to consider reading the rest...
STEP2:
Base Files (Most builds will supply these)
For all builds (Except the Link in Cupcake "instructions are givin in the download.) you will need a basic set of base files. The link below contains the 3 basic empty files for all builds and Systems.
http://cid-e5302e6abd554cb9.skydrive.live.com/self.aspx/XDA/Androidstuff.rar
IF
You are using Hero make sure you download hero.user.conf too:
http://cid-e5302e6abd554cb9.skydrive.live.com/self.aspx/XDA/hero.user.conf
-create a new folder called conf
-and place hero.user.conf in your new folder.
STEP3:
Rootfs
After you have the Base files you will need a rootfs. Depending on your Build, you may need a different type then the one I am going to supply you. Most builds will supply you with one. This one is DZO's rootfs.
http://cid-e5302e6abd554cb9.skydrive.live.com/self.aspx/XDA/rootfs.img
STEP4:
Prepare
-You need to clean out your storage on your SD. Make sure you delete everything.
-Create a file called android on your desktop.
-Download the base files, unzip, open folder, and place all 3 in your android folder
-Download the rootfs and place them in your android folder. Make sure you either download DZO's or the one your Build provides.
-Download a System.img. When you download a System most likely it will have a different name such as system-hero-123.img. You need to rename it system. So it should look like system.img . Then place it in your android folder.
-If you are using Hero place your conf folder in your android folder.
-Depending on your Build (mostly Hero) you may also need a Data file. The build you select should supply one. Download it and place it in your Android Folder
STEP5
Placing
Open up your android folder of all your collected files and select all, copy, and paste into your empty SD card.
STEP6
Unlocking
If you have never flashed a ROM before than you don't have HardSPL installed. So unlock your phone with...
http://forum.ppcgeeks.com/showthread.php?t=20370
Make sure you follow the forums directions.
STEP7
Method
Method1: The way I do it.
Download ROMUpdateUtility.rar
http://cid-e5302e6abd554cb9.skydrive.live.com/self.aspx/XDA/ROMUpdateUtility.rar
Extract to a newfolder
Download a kernel with your screen size
http://it029000.massey.ac.nz/vogue/files/?C=M;O=D
Don't know your screen size...check this out
http://forum.xda-developers.com/showthread.php?t=544906
After you have have gotten the kernel:
rename it to RUU_signed and place it in the ROMUpdateUtility folder you created.
NOW you need to plug your phone into your computer. Establish active sync. And run ROMUpdateUtility.
-Follow the Instructions on the screen.
Method 2 and 3 can be found here:
http://forum.xda-developers.com/showthread.php?t=593786
This also shows my method...but a little less detail. You can also find many other helpful things there.
If you fail OR think your bricked your phone.
You will need to download one of these depending on your carrier...Make sure you download the shipped gps rom. (If you are Verizon skip down)
http://forum.ppcgeeks.com/showthread.php?p=191607
Than you will put your phone in boot mode. Hold the Camera and Power button. While holding both of them...get a pen or something small and hit the little restart button on the bottom of your phone. You may have to hold it for like a second.
-you will see three color bars on your phone
-plug your phone into your computer
-run the backup
After your phone is all back to normal. Make sure you run internet explore on your phone. It will enable you to get data.
For Verizon follow the instructions here.
http://wiki.ppchaven.com/index.php?title=Pocket_PC_WIki:FIX_VERIZON_GPS
That is about it. I'm sure I forgot some stuff and will add on to this. Make sure you donate to the Devs for all their hard work.
DZO
http://forum.xda-developers.com/showthread.php?t=593786
jamezelle
http://forum.xda-developers.com/showthread.php?t=603028
plemen
http://forum.xda-developers.com/showthread.php?t=591104
vilord
http://forum.xda-developers.com/showthread.php?t=523692
They deserve it.
thank you this was very helpful
inphin1ty said:
thank you this was very helpful
Click to expand...
Click to collapse
No problem...
yea here is the md5sum: 9b08971e7f23619b6a9a4db9d52d857a
jamezelle said:
yea here is the md5sum: 9b08971e7f23619b6a9a4db9d52d857a
Click to expand...
Click to collapse
Whats that?
staud8469 said:
What are the benefits of running from NAND? (based on what I have seen)
1 Runs faster
2 Longer Battery life
3 faster boot up
4 can be faster to put together.
5 Easier to connect your vogue with android to your pc and sync
6 Much more convenient.
Click to expand...
Click to collapse
great thread. I've run both from nand and sdcard. i have not messed with ext2 on the sdcard.
I agree with 3 for sure. I would also add that there is a deep gratification in wiping win mo off the sdcard
6 is debatable, depends on which conveniences you want. changing lcd.density, changing resolution are all much faster running from the sdcard - no flashing or messing with build.prop, just edit default.txt and reboot (aside - if you have a non-sdhc card you can flash on the fly from the sdcard, but changing lcd.density still requires pulling and pushing files from the system, which is not as easy as changing the default.txt). also more convenient to back-up or revert to a data.img when running from sdcard. definitely booting straight into android is convenient, as is the new mass storage on boot method, as well as having a re-writable system (which you also have using ext2).
1 and 2, I honestly have not noted a significant difference in battery life. With a fast sdcard, I don't think there is a significant difference in speed either - dzo has said this in one of the non-vogue forums as well. i have not tried any sense builds from the sdcard though, and that's where you would notice the greatest difference in speed if there is any.
4 I agree with in general.
I think running from the nand is a huge advance, and great for everyone to try. but, running from the sdcard is still a decent way to use android. choosing between the two comes down to choosing which conveniences suit your usage style the most.
One last thing - please add vilord to your donate links (his google ion on vogue thread), he has been instrumental in developing the ril and advancing android on the vogue. srwalter also deserves mention for his reverse engineering of the libgps.so to bring gps first to cupcake and now to donut as well. jamezelle, plemen, mssmison, zenulator, enatefox, f00bar (no specific order) have all worked hard porting roms and working on things like compcache, swap, modem, etc, which has all been invaluable (zenulator and mssmison deserve special credit for spearheading the porting business). however the gruntwork of porting to the vogue has been done mainly by dzo who brought us the kernel and initial ril and now nand (he's just frickin amazing, he singlehandedly got the first functioning port to the vogue and others helped from there), then vilord who took the ril and really refined it. I guess suffice to say, there have been a lot of people involved along the way, thanks to all of them.
when i try to run android from both nand and haret i always get an error about not being able to mount sd card. does this mean i need to reformat the card? if so how do i do this?
Barogi44 said:
when i try to run android from both nand and haret i always get an error about not being able to mount sd card. does this mean i need to reformat the card? if so how do i do this?
Click to expand...
Click to collapse
When do you get this error? During linux kernel bootup?
Verizon users.
I just update a fix for Verizon users. Shows you how to get GPS too!
Also...there will be a video up soon. It seems that there are so many people having issues. So I will create a video from start to finish. Will be posted up late tonight/ tomorrow morning.
staud8469 said:
When do you get this error? During linux kernel bootup?
Click to expand...
Click to collapse
Yea.. i think i may need a new sd card. Can android boot from a 4gb card or is 2 the max?
Barogi44 said:
Yea.. i think i may need a new sd card. Can android boot from a 4gb card or is 2 the max?
Click to expand...
Click to collapse
i running with a 8gig PNY sdcard
it could theoretically run off of a 512, but you would be a little cramped on space
i guess android doesnt like some of them
so really it doesn't matter how big the card is? do they all have to be formatted to fat32?
Barogi44 said:
so really it doesn't matter how big the card is? do they all have to be formatted to fat32?
Click to expand...
Click to collapse
short answer, yes.
Hey guys...I will try my best to get that video up today. I am about to start recording it.
Am I correct in assuming that step 4-b is create a FOLDER name android on the desktop?
Can I delete those files from the SD when flashing is done?
THANK YOU for the N00B instruction, works great.
stopthebus said:
Am I correct in assuming that step 4-b is create a FOLDER name android on the desktop?
Can I delete those files from the SD when flashing is done?
THANK YOU for the N00B instruction, works great.
Click to expand...
Click to collapse
Yes that is correct, as for deleting the files...I would assume you could. But im not sure. Maybe they are still needed on boot. Never hurts to try though.
im not getting access to the internet after i flashed, am i suppose to edit anything?
im running the donut flash on my sprint vogue.
gigermunit said:
im not getting access to the internet after i flashed, am i suppose to edit anything?
im running the donut flash on my sprint vogue.
Click to expand...
Click to collapse
Wait...NVM you want data to work right?
If you are using donut...try to restart your phone one time. After it boots back up you should see a 3g symbol appear on the notification bar.
If that does not work...go to your apps and open modem. Click once on disconnect and then once more. Then click connect.
Tell me if that works...
So as a little side project I've tasked myself to review the security features and potential risks to data being stored within the Android OS and I've been using my Captivate as the test rat. Since pretty much everyone with an android device uses Gmail I wanted to focus first on the Gmail app. I know that information for many apps are stored under the /data/data/[app package]/databases directory structure in an SQL Lite *.db file.
That being said, I wanted to inquire with everyone here about being able to access the /data/data directory and all info there-in WITHOUT having to root the device. Im sure there might be some on that but Im just trying to be thorough in my review...any potential thief would obviously just instantly root and delve right in afterward the data but what other potential ways are there to get into that directory, if there are any?
I've been playing around with ADB and from what I can tell that is not a viable path. The only thing I could think of is somehow tricking the ADB daemon into thinking my phone is a development phone which would allow ADB to run as root but haven't found that to be possible.
So in any case, just looking for insight from the more experienced folk as to other avenues of attack against the user data beyond the obvious root method. Thanks very much for any help!
You can run adb shell as root if the phone is in clockworkmod recovery - but if someones going to the trouble of dropping a clockwork update.zip could just as well and as easy drop a root update.zip on the phone.
If someone physically gets a hold of your phone anything tied the google account/s on the phone would have to be considered compromised - as these phones are so easy to root anyway.
I just thought of another thing, if someone were to get a hold of your phone and have access to a computer with odin they could pretty quickly do a system dump (grab every file off your phone) return where you could find it without you ever knowing they got it.
dayv said:
I just thought of another thing, if someone were to get a hold of your phone and have access to a computer with odin they could pretty quickly do a system dump (grab every file off your phone) return where you could find it without you ever knowing they got it.
Click to expand...
Click to collapse
you dont need odin. adb will do it too
Pirateghost said:
you dont need odin. adb will do it too
Click to expand...
Click to collapse
Can you do a system dump in adb without root?
dayv said:
Can you do a system dump in adb without root?
Click to expand...
Click to collapse
yes
adb pull /system
Pirateghost said:
yes
adb pull /system
Click to expand...
Click to collapse
Learn new things every day.
I like this phone allot, but there just is no way to secure it against someone physically gets their hands on it.
Pirateghost said:
yes
adb pull /system
Click to expand...
Click to collapse
Yep thats actually very easy to do however it doesn't contain any critical private data really. I looked through the directories and while there is some interesting information that can be gleaned (e.g. the generic APN configs and other hardware information) there isn't any actual private stuff such as Gmail data, authentication info for apps, etc. That is all contained within the /data/data directory from what I understand.
You CAN get a list of all the packages on the device through /SYSTEM as well as all the APK's of the installed apps but otherwise not much I've found to be worrisome.
I'll have to check out Odin and see what that can offer from a non-root perspective.
Pirateghost said:
yes
adb pull /system
Click to expand...
Click to collapse
But, that is why you don't leave USB debug on all the time - and why there is a warning when you do turn it on.
PIN or pattern lock keep prying eyes out, and protect your phone from ADB, but not if you leave USB debug on. But, like other hardware, if someone has physical access and enough time, they can get to your data.
So now that Im rooted, is there an easy way to write up a script to copy all files in the /data/data and whatever other folders I decide onto my PC?
Hi guys.
I know that the z4mod can successfully patch a Tab kernel, without any problems (I did it myself, flashed it, and ran it just fine for a few days).
But when I tried to run one of the zip files to switch the file system, everything went nuts and I had to reflash my Tab from scratch.
So I did a little investigating, and as far as I can tell, all that needs to be done to make the whole thing successful is to modify the script in the zip file to correct the mount point names (as they are different from the SGS).
So if anyone around here knows anything about this sort of business, please take a look at it and let me/us all know, cuz it would be GREAT to get z4mod working on the Tab.
Here's the web site if anyone's interested;
http://www.sgscompilebox.dreamhosters.com/
Hi, did you tell ryanZA what results you got? I'm sure he'll be interested to help.
However, thank you for trying, I was about to do the same.
Noob question. What's the benefit of running ext2/3 for the internal partitions versus rfs?
knightnz said:
Noob question. What's the benefit of running ext2/3 for the internal partitions versus rfs?
Click to expand...
Click to collapse
RFS is Samsung's partition format (FAT + journal) that is supposed to be better for flash devices. Apparently it is not so good, and very laggy. Therefore people are switching partitions to ext2/3 or moving and linking stuff to SD card with ext2/3 or jffs2 partition.
jeebspawnshop said:
So I did a little investigating, and as far as I can tell, all that needs to be done to make the whole thing successful is to modify the script in the zip file to correct the mount point names (as they are different from the SGS).
Click to expand...
Click to collapse
Could you explain how you came to that conclusion ?
I was not able to locate my mount points to compare with what you did observe, but i guess we should start with that, then ask ryanZA his thought about what you've found.
Fyi: http://forum.xda-developers.com/showthread.php?p=9629477#post9629477
doloop said:
Could you explain how you came to that conclusion ?
I was not able to locate my mount points to compare with what you did observe, but i guess we should start with that, then ask ryanZA his thought about what you've found.
Click to expand...
Click to collapse
It has been tested by many Galaxy S users. Go to their forum and you will know
evermick said:
It has been tested by many Galaxy S users. Go to their forum and you will know
Click to expand...
Click to collapse
I'm really newb on linux, but i've read a little since last post.
What if we:
1 - dump mount list from a working SGT (terminal or adb shell -> mount ?)
2 - apply Z4mod then SGT won't boot (i assume it creates /etc/.fstab)
3 - edit /etc/fstab to match the dump in step 1
But, how do we read/write /etc/fstab once the sgt is locked ? using some kind of update.zip, or is there some shell service we could connect to, even if some mounts aren't in the right place ?
Unfortunately, everything I could contribute to this idea was in my first post. I know absolutely nothing about Android development, sadly...
But after reading what Deodexed said about volumes not mounting properly during recovery (he's the guy trying to get CWM to work for our Tabs) it seems that maybe that's the reason that z4mod may not work... If the volumes aren't mounted correctly, it can't convert the filesystems.
Maybe what doloop said might work? I hope so. An SGT running on ext2 would rock the socks off anything else out there. God I want it
I understand that the solution to this question may already exist in the forums, however, I did check high and low for it, and was unable to locate one.
Here goes:
I like (as I'm sure others do) to install apps2sd, something I'm able to do thanks to the actively-rooted and cyanogen-modded N1 that I use.
Unfortunately, the actual *install* files *themselves* from all Market-downloaded apps seem to remain in the phone's internal memory, clogging up preciously limited space. How do I get rid of these install files? I tried using a file manager to go into the mnt/asec directory to get rid of *.pkg's, but these seem to be uninstall-protected (I'm not even sure if I'm making a mistake from the get-go in trying to purge the *.pkg's), so I'm kind of back to the drawing board on this one.
Any help on this would be pretty invaluable folks.
Thanks,
Eli
If you've installed a lot, your dalvik cache will grow pretty big. That's found in /data/dalvik-cache.
Thanks Rusty - but my /data dir is completely empty (unless there are invisible folders; if there are, who you know how I can make them visible?).
Best,
Eli
You need SU access to view /data, make sure what you're using to browse it supports that.
Ahh, thanks Rusty - will do that
Your DATA folder is inaccessible, unless you use Root Explorer or other file explorer with root privileges (ES Explorer, for example - but it doesn't work with all ROMs).
There are no PKGs. There are APKs. And you're wrong in your assumption that they aren't used. This is no PC, this is Android, forget what you used to know, you need to learn again. APKs are the actual applications being ran, without them you can't execute anything, and using old Apps2SD, AKA Apps2EXT, you can move your /data/data to SD (EXT partition) and /data/dalvik-cache to /cache. CM doesn't support Apps2EXT, but it can be easily installed and used, following the guide in DarkTremor's thread. Read Wiki in my sig, it'll point you in the right direction. You can start by reading FAQ, question 9.
seekingandroid said:
I understand that the solution to this question may already exist in the forums, however, I did check high and low for it, and was unable to locate one.
Here goes:
I like (as I'm sure others do) to install apps2sd, something I'm able to do thanks to the actively-rooted and cyanogen-modded N1 that I use.
Unfortunately, the actual *install* files *themselves* from all Market-downloaded apps seem to remain in the phone's internal memory, clogging up preciously limited space. How do I get rid of these install files? I tried using a file manager to go into the mnt/asec directory to get rid of *.pkg's, but these seem to be uninstall-protected (I'm not even sure if I'm making a mistake from the get-go in trying to purge the *.pkg's), so I'm kind of back to the drawing board on this one.
Any help on this would be pretty invaluable folks.
Thanks,
Eli
Click to expand...
Click to collapse
1) The .apk isn't the install file it _is_ the application. The are no "install only" parts to an android app
2) Anything on /mnt/asec is already on your sdcard using froyo-style a2sd
3) .so files in /data/data/xxx/lib and /data/dalvik-cache are the primary causes of full /data partitions
I have a Nook HD+ that I want to root myself, and I'm looking for a simple CM (or whatever) bootable SD card image that does nothing to the HD+'s internal storage. I just want it to boot up so that I can connect via ADB, and do what I want on the HD+'s internal storage myself via ADB and shell commands.
Yes, I know I can use "Universal Root", but that does more than I want, and I think I want to root a different way anyway. I know what I'm doing, having published a similar rooting procedure for the Nook Tablet a year ago. I just need to boot from a SD card and have ADB/shell command-line access to the HD+'s internal storage.
I think I see a couple of bootable images, but they all seem centered around CWR. I do not want to install CWR on the HD+, and the descriptions seem vague as to exactly what the images contain.
Dean, you can go to my HD/HD+ CWM thread and make a bootable CWM card. It does nothing to internal memory until you flash something. Then you can connect to ADB and it gives you root access, again with no mods yet to internal. Then you can do what you want to the system. But remember, if you change anything on /system, it will reset on the next reboot. Look at my HD/HD+ tips thread item 15 to understand this.
Sent from my Nook HD+ running CM10.1 on emmc.
Simple (basic) root
Thanks; I wasn't sure that the CWR images included ADB enabled.
I came up with a slightly simpler solution that uses a "remount,suid" on "/data". This is no longer necessary. The prerequisites are:
The HD or HD+ is running B&N v2.1.x or v2.2.0 (other versions unknown/untested).
SuperSU is already installed (but need not be working) on the HD/HD+ via Google Play.
At http://www.mailpen.com/download/HdP_2.1.x-Root_0.05.zip
Note to lurkers: Don't quote this message with the above link intact, as it will change (and has):
Revision history:
2013-06-13 v0.01: Original release.
2013-06-14 v0.02: Avoid CWR set_perm bug?
2013-06-14 v0.03: Modify to use /system/bin/clrbootcount.sh. Include busybox and sqlite3.
2013-08-13 v0.04: Add updateSU.sh for easy update after su binary change.
2013-08-30 v0.05: Install files in /system/xbin/.bin and create links to them. Remove installation of a custom /system/bin/clrbootcount.sh. Add /system/xbin/.bin/busybox.sh (but don't execute it), which the user can use to create the required busybox links in /system/xbin (from where it should be run).
You are free to adapt this as you see fit.
You really should include an assert statement there for ovation (or ovation/hummingbird) in case it somehow gets out somewhere else. And the title says HD+, but inside the script it says HD/HD+. Also this should work on all versions of stock.
It does not install busybox or its symlinks.
Edit: Verygreen's original root did something similar where he put the su in /res, I think, set suid and symlinked it. But his root also failed to address busybox.
Edit 2: also some of my other zips will not work with your root because you removed the userinit.d implementation from install-recovery.sh. I suggest that you move your root to /system/bin/clrbootcnt.sh and symlink that. It also gets run on each boot. Then it would not interfere with my other zips that use install-recovery.sh to set up userinit.d.
Sent from my Nook HD+ running CM10.1 on emmc.
Details, details ...
leapinlar said:
...
It does not install busybox or its symlinks.
Edit #1: Verygreen's original root did something similar where he put the su in /res, I think, set suid and symlinked it. But his root also failed to address busybox.
Edit #2: also some of my other zips will not work with your root because you removed the userinit.d implementation from install-recovery.sh. I suggest that you move your root to /system/bin/clrbootcnt.sh and symlink that. It also gets run on each boot. Then it would not interfere with my other zips that use install-recovery.sh to set up userinit.d.
Click to expand...
Click to collapse
#2: OK, I don't have a problem with that. Stand by for v0.3 ...
#1: I personally install busybox (and sqlite3) in /data/local/sbin, and they work there. The reason I don't create the busybox links is due to the PATH value, which usually has the value:
Code:
/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
In most busybox installations, busybox is in /system/xbin, and so when the links are created, if there is a name conflict between a busybox link in /system/xbin and a pre-existing one in /system/bin, the one in /system/bin takes precedence in a PATH search. That means that pre-existing apps that count on a particular standard behavior, will find the one in /system/bin. I think the probability of a problem due to a pre-existing app finding different behavior is very small, but it's one less thing to think about. Note that "mount" on the Acer Iconia A500 is nonstandard ...
Also, in most installations, /system/xbin is empty, or very nearly so, so putting the busybox links there (which I certainly could do on the HD+ as well) made it "cleaner" for maintaining that directory.
However, there are good arguments for putting the busybox links in /system/sbin (now aka /data/local/sbin). In addition to the same "cleaner" argument above, the busybox links would now supercede names in /system/bin. That might be an advantage, since usually the busybox versions of common utilities are more capable (more options) than those provided by the tablet vendor (usually in a similar program named "toolbox").
The point of all this is that I didn't want to rush in making a decision. Suggestions/comments welcome!
PATH priority
DeanGibson said:
...
In most busybox installations, busybox is in /system/xbin, and so when the links are created, if there is a name conflict between a busybox link in /system/xbin and a pre-existing one in /system/bin, the one in /system/bin takes precedence in a PATH search. That means that pre-existing apps that count on a particular standard behavior, will find the one in /system/bin. I think the probability of a problem due to a pre-existing app finding different behavior is very small, but it's one less thing to think about.
...
However, there are good arguments for putting the busybox links in /system/sbin (now aka /data/local/sbin). In addition to the same "cleaner" argument above, the busybox links would now supercede names in /system/bin. That might be an advantage, since usually the busybox versions of common utilities are more capable (more options) than those provided by the tablet vendor (usually in a similar program named "toolbox").
The point of all this is that I didn't want to rush in making a decision. Suggestions/comments welcome!
Click to expand...
Click to collapse
OK, I tried creating links in /system/sbin, and that caused SuperSU (and other apps requiring root) to not work. The apps work if the links are in /system/xbin. I've added a "busybox.sh" script to the above .ZIP to allow the user to create the links wherever he/she wants.