Database Info

/ as rw all the time, is this a big deal?

I'm a big linux enthusiast and have done a lot of neato stuff with my phone, including installing JF 1.31! This forum is great! I have a question though ... in /init.rc, would it be a bad idea to comment out "mount rootfs rootfs / ro remount" to make / writable on boot? I don't see a reason why not besides the obvious you'll-fark-something-up deal, but I would presume that as long as you're not piddying in root all the time, no problem (just like on a "desktop" linux system). Or ... is Android really not designed at all to have / rw, so there's exterior security vulnerabilities, chances the native UI could render data loss, etc.?

synthead said:
I'm a big linux enthusiast and have done a lot of neato stuff with my phone, including installing JF 1.31! This forum is great! I have a question though ... in /init.rc, would it be a bad idea to comment out "mount rootfs rootfs / ro remount" to make / writable on boot? I don't see a reason why not besides the obvious you'll-fark-something-up deal, but I would presume that as long as you're not piddying in root all the time, no problem (just like on a "desktop" linux system). Or ... is Android really not designed at all to have / rw, so there's exterior security vulnerabilities, chances the native UI could render data loss, etc.?
Click to expand...
Click to collapse
You can make / all you like. You can even change all the files in / all you like. But once you reboot, all changes will be lost.
The / filesystem is stored as a .cpio.gz file in boot.img. When android boots, it loads this root filesystem into memory. Any changes afterwards are in memory only.
If you want to change any of the files in /, you have to extract the boot partition, extract the .cpio.gz image, unpack, modify, re .cpio.gz, repackage into a boot.img, then flash it to your phone.
See this thread for details.

edit: something like what he said

beartard said:
I wouldn't do it for the simple reason that you don't know what 3rd party apps are programmed to do if they find a writeable root. Yes, there is a whitelist, but you can't be too careful. It's not too much trouble to remount it when you want to mess around.
Click to expand...
Click to collapse
Heck, let applications change / all they won't. Someone should write a file system monitor that tracks any changes in /, just to be able to laugh at the applications that are trying to change it.

JesusFreke said:
You can make / all you like. You can even change all the files in / all you like. But once you reboot, all changes will be lost.
The / filesystem is stored as a .cpio.gz file in boot.img. When android boots, it loads this root filesystem into memory. Any changes afterwards are in memory only.
If you want to change any of the files in /, you have to extract the boot partition, extract the .cpio.gz image, unpack, modify, re .cpio.gz, repackage into a boot.img, then flash it to your phone.
See this thread for details.
Click to expand...
Click to collapse
Really! Bizarre! Wow ... I would have never guessed that. That really saves ass on data loss/corruption for dumb things I suppose, but ... WEIRD! It doesn't sound all that hard to modify things even still, but damn. Well, you answered my question. Thanks!

[GUIDE][please correct] permaroot for the android newb (using Evostance's guide as b)

PREFACE & CRY FOR HELP:
I’m pretty sure this guide works. This is how I got permaroot and write access to my DHD system files and directories. But I might have made mistakes. I hope some experienced people will read this guide and point them out. I hope newbs will wait for a few people to say if this guide is correct or not before trying this.
I mainly used Evostance's guide. Thank you Evostance (and all the others whose work I've ripped off here!) and I hope you understand me for posting this rather longer, newbified guide;
The guide:
This is a guide to rooting and gaining write permission to your Desire HD, written for the Android newb.
You ain’t dumb, you just don’t know Android. Even though I’m learning to program for this OS, I don’t know Android either. Not enough to root and gain write without the help of expert reverse engineers and other guide writers who have much more experience than I do with this OS.
However, all the knowledge is very fragmented right now, due to everyone being VERY EXCITED about root now being available on a NAND locked DHD. The info is there, but it takes some looking around, some warnings, some things I didn’t find in one place, but scattered through many posts on many threads.
That’s why I wrote this: for the Android newb who wants a rooted phone and doesn’t have the time to spend hours tracking down the information and all the caveats.
WARNING: THIS IS DANGEROUS AND CAN BRICK YOUR PHONE. IF YOU TRY THIS, IT IS YOUR OWN RESPONSIBILITY, NOT THE APP WRITTERS, NOT THE GUIDE WRITERS, JUST YOURSELF.
1.
First things first: you might have a lot of programs running which use temproot.
Remove them. ALL.
Check SuperUser which apps have been granted root, and uninstall them, removing all data. For previous (temproot only) versions of Visionary, it might be safer to stop it temprooting at startup, and restart your phone (longpress power, select restart or power off), then remove visionary, just in case.
Finally, remove SuperUser itself.
All the above might not be necessary, but there have been reports of trouble from having these programs running whilst trying to achieve permroot. So be safer rather than sorrier.
2.
Now your phone is essentially running a stock version; no programs running root are active, no surprises at startup. Titanium Backup etc etc are not going to interfere.
Get the following files and programs:
From the Marketplace:
-Gscript (Lite is fine)
-Terminal Emulator
-a root file explorer. The only program I’ve found which does what I need is Root Eplorer. It will cost you money, but Android Mate or Astro haven’t been able to do the job for me.
(DO NOT INSTALL YET -SuperUser; we’ll get this later on; if you install it now you might run into trouble whilst trying to get root, as it might interfere with certain program’s checks to see if you have root already. I mention this program here so you know you’ll need it later, so either have access to the Marketplace or have the .apk ready to install later on.)
Install these on your ‘clean’ phone.
From the internet:
-the files listed in the first post of :
http://forum.xda-developers.com/showthread.php?t=805327 (adwinp’s guide)
or
http://forum.xda-developers.com/showthread.php?t=834427 (Evostance’s guide)
I used the second link (and the guide Evostance wrote which is included). Use this time to read through what Adwinp and Evostance say. Follow the link to their threads and understand what you’re doing.
-get Visionary+ from the awesome Paul O’Brian.
DO NOT INSTALL THIS YET!
http://android.modaco.com/content/t...350/10-nov-r12-test-visionary-one-click-root/
Use a version higher than v11 (v12, v 13, v14 … I don’t know what version he’s on; you might have to look for v13 in that thread, page 6, 7 or 8, if he hasn’t released a newer version).
3.
Now, get all these files and apk’s on your phone. Sync ‘em, download them direct, use wifi, whatever. Just don’t install them (yet). You want the raw files.
Specifically:
-the visionary apk
And from any of those packages you downloaded from the guides listed above:
-the wpx.sh and hboot.sh files (found in the gscript folder of Evostance’s guide’s package): these should be put on your SDCARD, in a directory named gscript (you might be able to put them anywhere, I put them here and the process worked for me).
-the correct wpx.ko and hboot-XXXXXX.nbo files. The XXXXXX refers to a specific hboot file, corresponding to if you updated your phone over the air with the HTC fixes or not. These files are found in rar/zip packages found in the previous mentioned guides (and probably many other mirrors). Pick the files which are located in the folder whose name corresponds to your kernel version (found on your phone using menu -> settings -> About phone -> Software Information -> kernel version).
These .ko files should be put in your SDCARD’s root directory
4. RECAP:
Now you should have
-Gscript and Terminal Emulator installed
-the Visionary .apk on your sd card somewhere
-wpx.sh and hboot.sh in the SDCARD\gscript directory
-wpx.ko and hboot-XXXXXX.nbo on your SDCARD’s root.
5.
Now we’re almost at the point of no return.
Run Gscript.
Hit the menu, “add script” and hit “load from file”. Select the wxp.sh file. Have “run as superuser” selected.
Do the same for hboot.sh.
Exit gscript.
6.
Install Visionary.
Don’t do anything except get temproot. ONLY hit the temproot button; don’t change anything else.
Wait.
You should have temproot now. To be sure, go and select ‘run at boot’ (the ‘re-get temproot’ checkbox) in Visionary and reboot your phone (long powerkey press, restart or shutdown, then restart your phone).
You should have temproot again. You can check this after the next step:
7.
Install SuperUser (preffereably from the Market, so you have the latest version).
If you start the Terminal Emulator, you should now be able to type
su
and hit enter, and the prompt will change from a $ to a #. If so, you have root. You might have to allow SuperUser access to the Terminal Emulator. Do so.
7.
After you have temproot, you should now start Gscript. In the next bits, you might get “Gscript is trying to use SuperUser status” (or somesuch) popup message. Allow this.
Run the wxp script. It should report an error. This is OK.
Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked.
If you get a message saying that this operation couldn’t run, you’ve done something wrong, somewhere. I can’t help you: try from the beginning or something. Sorry I can’t be more helpful than that.
8.
Point of no-return:
You have temproot, you have installed SuperUser and you have run the two Gscript commands.
In this next bit, SuperUser might prompt that Visionary is seeking root permission. DENY THIS. It’s my belief that Visionary expects NOT to get that permission and only then runs. Giving permission leads to not much happening after you press the root button. I suspect a few problems happen due to this. Anyway:
Startup Visionary again. (maybe select ‘mount system as r/w’ … for me it didn’t, which is part of why I’m writing this guide).
Now, in Visionary, hit the ‘get permroot’ button. This process might take a while. If it’s working, the menu you pushed the button on should whisk away to the side: that way, you know Visionary is getting you permroot. Your phone should reset and you should have permroot.
8.
Making it stick.
Use Root Explorer for this next part. I tried using other programs, but they wouldn’t work. Mainly because granting write access hadn’t worked properly.
Now copy
su to /system/bin/
and
Superuser.apk to /system/app/
You can find su in system/xbin/ and SuperUser.apk in /data/app/. You might have to mount the system directories as r/w (from r/o) using Root Explorer. I had to do this, as I didn’t have write access to system files, even though I asked Visionary to do this. No biggy, but it did mean I had to buy Root Explorer. Not a bad price to pay for permroot, write access and a pretty good file explorer 
Now, finally, open Terminal Emulator and type:
su <enter>
chmod 4755 /system/bin/su <enter>
After typing ‘su’, the prompt should change. If it doesn’t, as mentioned before, you don’t have any kind of root (or Term.Emu doesn’t have it, maybe resetting SuperUser’s settings will help) and I can’t help you.
Now you should have total control over your system files. You now finally own your phone.
9.
Thanks to everyone involved, from the hackers to the helpers to the guide writers to those who just chimed in. I didn’t do anything except steal all this info from them, use their files and programs and write this down.
Thank you; we NAND locked phone users are in your debt.

Hi MacDegger,
Good effort, a couple of things that when reading appear a little off, unnecessary or confusing
"You should have temproot now. To be sure, go and select ‘run at boot’ (the ‘re-get temproot’ checkbox) in Visionary and reboot your phone (long powerkey press, restart or shutdown, then restart your phone).
You should have temproot again. You can check this after the next step:
7.
Install SuperUser (preffereably from the Market, so you have the latest version).
If you start the Terminal Emulator, you should now be able to type"
- There is no need to reboot. Also, checking "run on bootup" is something I would refrain from. Simply temp-root is enough
- Why "install superuser" from market?! temprooting via visionary (r12 is what I used) already pushes Superuser.apk to /data/app, so there is no need to re-install from market
- So instead, I would simply temp root with visionary. No reboot, not market download
In this next bit, SuperUser might prompt that Visionary is seeking root permission. DENY THIS. It’s my belief that Visionary expects NOT to get that permission and only then runs. Giving permission leads to not much happening after you press the root button. I suspect a few problems happen due to this. Anyway:
Startup Visionary again. (maybe select ‘mount system as r/w’ … for me it didn’t, which is part of why I’m writing this guide).
Now, in Visionary, hit the ‘get permroot’ button. This process might take a while. If it’s working, the menu you pushed the button on should whisk away to the side: that way, you know Visionary is getting you permroot. Your phone should reset and you should have permroot.
Also not necessary. Visionary R12+ (actually use the R13 version as this one skips the "root already installed routine" some people have issues with) will permroot your device straight after temprooting it just fine. It will open the wpx.ko, will write busybox and su to system/xbin, will repush superuser.apk to /data, will then copy wpthis-lovinglymadebymodaco.ko to /data/local and then reboot.
After this reboot, you are already perm rooted. uninstall visionary, and reboot to test it.
Run the wxp script. It should report an error. This is OK.
NOTE: running visionarx to PERMROOT will copy the required wpthis.ko file (with the right kernel version to /data/local), and will call it "wpthis-lovinglymadeforyoubymodaco.ko."
So as a matter of fact you now have 2 (two) modules in /data/local, the wpx.ko and modaco (pauls) version of it. Whilst no biggy, I would simply adapt the wpx script to insmod pauls version, not wpx anymore. Just to be safe the right kernel is used when execuing and opening the exploit to remove the RW protection to /system, and I believe visionary+ actually checks the kernel and then pushed the correct wpthis*.ko to /data/local.
The next steps,
8.
Making it stick.
Use Root Explorer for this next part. I tried using other programs, but they wouldn’t work. Mainly because granting write access hadn’t worked properly.
Now copy
su to /system/bin/
and
Superuser.apk to /system/app/
You can find su in system/xbin/ and SuperUser.apk in /data/app/. You might have to mount the system directories as r/w (from r/o) using Root Explorer. I had to do this, as I didn’t have write access to system files, even though I asked Visionary to do this. No biggy, but it did mean I had to buy Root Explorer. Not a bad price to pay for permroot, write access and a pretty good file explorer 
Couple of things - visionary will only mount to /RW when flagged and executing TEMPROOT. SO by default, upon reboot the system is always in R/O mode, not R/W mode, whether you use visionary or install root manually. Thats fine and as you said, you can remout RW with RootExplore or via ADB.
Pushing SU and superuser.apk from /data/app and /system/xbin to /system/app and /system/bin is, whilst "safe" not really required. Superuser.apk is quite happy being on /data/app, and IF you must move it to /system/app, you should do a couple of things.
a) MOVE it, not copy it. This way, the user data (which permissions are allowing access to root) will not uninstall, and the permissions will also be set correctly (664 permissions for apps, or RWRWR). Copying it is not ideal, as it could simply kill/forget or cause other issues to it when you do it wrong. And if the permissions are missing as you didn't copy right, you basically blocked yourself our of your root-method permanently.
b) Copying su to system/bin is nice, but again, I would rather create a symlink to is in system/bin to execute/link to system/xbin. Again permissions are necessary and vital
They work just fine in /data/app and system/xbin. THe only reason to move su to system/bin is that some apps simply look for SU in /system/bin, and not in system/xbin. Most well programmed apps that require root will find it anyway, regardless of whether su is in /system/bin or system/xbin.
SO, I would, if I had to advice "noobs", simply leave them where they are. I would temproot, permroot and then install the s-off recovery. Nothing more after step 7.
PS the point of no return, the really dangerous bit, is actually THIS
Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked.
Thats where your system is flashing the bootloader, this is the risky part, where things can go terribly wrong. So "something worked" is maybe not very noob-friendly SO when writing for newbies, make sure they understand ONE thing.
ALL they do in your guide is reversible with flashing the RUU again if something got messed up.
But this
"Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked. "
This is where you CAN turn your device into a 600 USD paperweight!

I think this guide has too much info for the average user to understand.
It's better for the average user to just permroot only and leave hboot alone until they know what can go wrong.
My guide takes alot less steps to achieve S-OFF, because I use the kernel module Visionairy+ leaves behind after permrooting. In other words if you fail to permroot, you won't be able flash HBOOT until you read the other topics on how to modify the module. Which leaves the average Jo far away from a possible brick without some knowhow.
Just my two cents.

Thanks for your awesome comment, Thyrus! I think that an android newb (like me ) now has enough information, after reading this with your post, to do this safely.
I'm going to incorporate your comments into the post, but there's one thing I'm hazy on. Thing is, what I described above was the exact sequence I used to get root and write. You seem to suggest that the whole gscript thing is unnecessary and visionary13+ permroot does all of that anyway, except for flashing the hboot?
So basically I flashed my hboot twice, and because I ran the two gscript scripts, I basically rooted my phone twice?
Just to be sure, you suggest getting rid of the whole gscript section and replacing it with "run visionary permroot now, and if you really want to (and at your own risk) flash the hboot using the gscript hboot.sh"?
I'll wait for your response before changing, just to be sure. Anyway, thanks for your great post!

/data partition read only - My experience

I have spent a couple of days in hell and would now like to share my experience as a big thank you to the XDA community. However, I am fairly noobish when it comes to Android so if you feel that this does not help, please feel free to delete this entry.
It all began when I restarted my G Tablet and got lots of popus about various applications, including acore, failing. I thought that this was due to me screwing up the system in some way after more or less having followed r34p3rex's superb guide here: http://forum.xda-developers.com/showthread.php?t=827209.
Ignoring this for a moment I tried to install one of the NDK sample apps on the device. This failed with the message: "read only file system". Looking in logcat it was pretty apparent that this was also causing all other applications to fail, since they were logging errors with not being able to write under /data/.
Looking at dmesg output finally confirmed this, where it reported that the /data partition had journal errors and could only be mounted as read only (this was also confirmed by issuing the mount command from within an adb shell).
This led me on a journey from just trying to remount the partition as read only (which failed with no further message), through installing clockworkmod, different versions of tnt lite, formatting and repartitioning (or so I thought), to flashing the device through its APX interface (using nvflash). None of them worked.
Not until I read a post by raydog153 - in this archived thread: http://forum.xda-developers.com/archive/index.php/t-857875.html - did I succeed by re-partitioning the sdcard (under the advanced section).
You could argue that it was stupid to not realize that a re-partitioning was required in the first place - since the ext3 partition obviously had errors and Android does not provide a fsck command (or does it?) - but I guess I thought that this was what was actually being done in other clockwork commands or at least when doing the nvflash, but obviously that was not the case.
Anyway, sorry for the lengthy entry. I just wanted to give back to the community and help others who might get the same problems I had. Also, on the positive side I have learned a lot and, like someone else wrote, I have completely lost my noob fear of bricking my G Tablet.
Keep up the good work, guys! You Rock!

almost a week without problems with FCs, thanks for this usefull info.

[INFO] Edify Scripting Notes

Return to Contents Page - doubleshot Developers Reference
**For some reason the board merged all of my posts...sorry guys, just gonna have to deal I suppose.
Since sharing my notes here about what i've learned/am learning for Android development seems to be helping people beyond myself, i'd like to share my notes regarding Edify scripting so far.
WARNING: You can really screw up your phone once you start making your own flashable zips. While this guide gathers scripting information from all over XDA and distills it into MT4GS implementation, it is not a difinitive resource.
There are blatant gaps of knowledge in this thread. I am trying to include as many of the helpful resources I can that were found here at XDA. Links are at the bottom of this post - if you found a good edify-script reference here at XDA, please reply with a link to this thread for people researching this topic. Thanks!
I highly recommend you have a good understanding of what you are doing before you go ahead and do it. Follow the links, drift through the XDA knowledge base and soak it all in.
Feel Free to ask any questions or add anything related to Edify scripting to this thread.
Here's how this thread is laid out:
Post 01 - Contents
Post 02 - Edify Scripting Explanations.
Post 03 - Before we begin...
Post 04 - Mounting your way out of RAM.
Post 05 - Delete, Demolish and Destroy.
Post 06 - Break more stuff: Format <-- Flashable zip 'format' utility here.
Post 07 - Reserved. ( Installing )
Post 08 - Reserved. ( Permissions )
XDA Links:
Tools:
nubecoder's amend to edify script converter
Utility i've been signing my zips with by benjamminzIS
Posts/Threads:
Single post by nubecoder, syntax
Tutorial by coolexe on Amend/Edify script syntax
Thread by DooMLoRD, pieces of the mounting puzzle
...and more when I get time to track them down and put them in.
One thing to note about this thread is that it's not just a quick synopsis of syntax. There are plenty of threads like that around XDA, and they are all helpful. The MT4GS has some specifics to keep in mind, and there are some things to work around in CWM, but we can start to tackle some of this with this guide.
This thread is more of an explanative review of the process, an attempt to point out some common, or not so common mistakes that are easily made...and a bit more of a look at why things are happening beyond just how to do them.
More of a theory behind the application of principles and so not a quick read.
I would like to say thank you to computerkid23 for putting an end to trying out every update-binary I could find looking for the right one. By allowing me to re-use the one from the "Tasteless Venom" ROM, I stopped treading water and started making forward progres again.
This is the update-binary file used in all of my scripts, and has the proper syntax for the commands to work with the MT4GS.
---------- Post added at 04:54 PM ---------- Previous post was at 04:51 PM ----------
Edify Scripting Explanations
ClockworkMod Recovery 3.0+ and update-script
Read the post from the above link to understand that Amend scripting is the old way and Edify scripting is the new way.
While the commands are essentially the same, the syntax and expression is much different in Edify then Amend.
If you are trying to flash a zip, and want to figure out if it's an Amend or Edify:
Both Edify and Amend flashable zips have the following directory:
/META-INF/com/google/android/
In the android folder:
Amend = update-script
----------------------
Edify = update-binary
updater-script
Click to expand...
Click to collapse
This is the easiest way for you to tell what kind of script you have - in simplest form and first point of recognition:
1 File = Amend
2 Files = Could be Edify
If two files exist in this directory, check to make sure they match the quote above for Edify. Make sure it's not a mix of an Amend update-script and Edify update-binary.
If everything matches up to Edify so far, then browse through the thread and look at the command syntax laid out for Edify. If what you're looking at doesn't match, then you'll have to seriously downgrade your CWM version to run it - meaning you will have to write your own recovery from scratch.
With that understanding, for the remainder of this thread we will only be focusing on Edify scripting.
update-binary
This is a not so trivial piece of your scripting puzzle. There are an unknown number of different update-binary files out there. They support different script syntax, make sure your updater-script and update-binary match.
---------- Post added at 04:54 PM ---------- Previous post was at 04:54 PM ----------
Before we begin...
...there are just two things we have to go over:
1 - Backups.
2 - The ui_print("") command.
First, read my Thread about backups. Specifically post 2 about making a Clockworkmod backup.
You should have multiple copies of each backup you keep, on different machines or media. If your only backup is on the sdcard of your phone, and you accidentally erase it, that's it - it's gone.
Make sure your CWM backup works before relying on it. The only thing worse then losing a backup is keeping a bad one you think is good.
Your can't just pull individual images out of it and restore it through CWM, you need the whole backup file that was generated by CWM. You can restore only specific partitions from the complete backup file if you want.
Basically, your backup is your security. Once you start writing scripts you run into the problem of being able to affect changes on things you weren't intending to and you just can't fix - you need that backup.
Second, the ui_print("") command.
Code:
Syntax:
ui_print("some message goes here");
ui_print("another one here");
ui_print("the next line is a blank line");
ui_print("");
This command simply prints whatever text is in between the quotes to the screen when the line is executed.
This includes white-space, so any spaces you make in the quotes are preserved, even if it's the first thing after the quoatation mark.
Okay - so here's one of those MT4GS tips that you find through trial and error:
- The MT4GS screen in recovery, after executing a file, fills up to a certain point with printed text.
1 - Verticle:
To get your title, introduction line, whatever, as the top line erasing all code that came before it, you must print 23 lines of text to the screen. The first line must be blank.
Example:
ui_print("");
ui_print("MT4GS - Blue6IX A01 Wipe - Stock Mod");
ui_print("");
Click to expand...
Click to collapse
That's how your first 3 ui_print("") commands should be entered into your script to make your title be the top line of code on the screen when the script is finished in CWM.
2 - Horizontal:
To keep your text from being split at an awkward place, remember that you get about 40 characters on a line before it starts printing to the next line on the screen. If this happens, that second line counts as one of your 23.
I attached some screenshots of some of my scripts at the bottom of this post. They show what clockworkmod looks like as soon as the script is finished, before the user changes anything.
With the parameters of 23 lines down (first line blank) and no more then 40 characters to any individual line, you can format the final output of your script to be much more useful to the user.
If a person sees all the commands they entered leading up to executing your script, but only a few of them and some are already pushed off screen, it can be confusing.
This is a part of the development approach that is appealing to me, the end user experience and what I can do to enhance it. By making the final output of your script consist of only what you want to be shown on the screen, you have an opportunity to communicate to the user.
Make sure to check all your spelling - honestly, when I see typos in the printed output of an installation script, on any software on any platform, I start to worry about what's in the rest of the code. By presenting yourself well here, you can establish a level of trust with the end user in your product. ( Obvious slang and intentional misspellings notwithstanding )
Something else to consider is that if you don't use the progress commands to show that the script is doing something, a long operation might confuse a user into thinking their phone froze. They might then do something really bad in the worried and irrational state of mind that could put them in...
"oh...no... I think it froze somewhere between writing the radio and imaging the boot partition...
Click to expand...
Click to collapse
I put that up there as an extreme example, writing radios is not part of this thread ( initially... ) but imagine being that user who doesn't really know what's happening to their device, doesn't have the technical background to know what to do in a situation like that, and they might irrationally pull the battery while it really is writing the radio in a panic.
When contemplating the effects of what actions you do and do not take, always consider the worst possible thing you can think of happening as being the most likely to occur.
Simply using a progress bar, or as I prefer, the ui_print(""); command to keep something happening on the screen keeps the user from guessing. If enough space is left over, you can even tell them what they have to do next.
Or you could just chalk it up to me being too particular about the details...
Anyways, check out these screenshots to see how you can use the space available to you to direct the user and possibly eliminate some confusion:
---------- Post added at 04:55 PM ---------- Previous post was at 04:54 PM ----------
Mounting your way out of RAM
-Mount Points
-"mount" command
-"unmount" command
The most feature-rich script for reprogramming your Android device just the way you want loses all value if all you are doing is writing to RAM.
If you do everything else right, but don't mount your partitions correctly, then your script will either error out or just zip through the install in no time flat.
First piece of information you need to know-
doubleshot mount points:
Code:
/dev/block/mmcblk0p22 /system ext4
/dev/block/mmcblk0p23 /data ext4
/dev/block/mmcblk0p24 /cache ext4
These are the mount points for system, data, and cache.
Thanks to nubecoder for the how to on finding them out Here:
Not a direct quote.
From ABD:
adb shell "mount > /sdcard/PHONENAME_mountinfo.txt"
From Terminal:
mount > /sdcard/PHONENAME_mountinfo.txt
Click to expand...
Click to collapse
You do not need root to generate this info from Terminal Emulator.
Part 1 - Mount point usage:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p22", "/system");
** I have had mixed results using update-binary files that called for 3 parameters to mount. I may not know enough to explain why, but my theory is that:
-"EMMC" parameter allows me to force the action to take place not in RAM, can someone verify this?
Ever since using this method of mounting I haven't suffered the problem of the script running itself out in RAM and not doing anything.
By executing the above line of code, you will mount the system partition of the internal phone memory. Partitions must not be mounted if the format command is executed. For all other actions, mounting is the first step.
Part 2 - unmount when finished.
Code:
unmount("/system");
unmounts the partition and makes it safe to format.
If you are done with it for the time being in your script, you can unmount and remount it later when you need it.
All mounted partitions should be unmounted before the script is done.
Part 3 - Example
Dummy code in green, mount & unmount in bold
Code:
[COLOR="Green"]Lines(of code);
in_your(script);[/COLOR]
[B]mount("ext4", "EMMC", "/dev/block/mmcblk0p22", "/system");[/B]
[COLOR="Green"]More(code);
the(stuff you do);
to_the(system partition);[/COLOR]
[B]unmount("/system");[/B]
[COLOR="Green"]possibly_even(more code);
to(do more things);
after_you(are done with);
the(system partition);[/COLOR]
So here we learned how to mount, unmount, and some reasons why we need to do or not do this.
I am a big fan of unmounting a partition when I am done using it, and you'll see examples of this throughout my scripts as they surface here at XDA. I know some people will disagree with me about this, but here's my reasoning:
-The only way to change something on a partition is to mount it first, so if a partition is not mounted nothing is happening to it.
*Format is the exception. A partition must not be mounted if you want to format it. See the post on format below to find out more.
By not mounting a partition if I don't need to, or unmounting a partition when you aren't using it for a time, you can prevent accidents and put another layer of protection on the execution of your code.
As much as you should mold to the way the machine works, it is here to serve you and that's gotta give both ways. At some point the code has to be decipherable to a human, and there's no harm in spreading things out a little bit to also make sure everything happens in it's proper way at the right time.
---------- Post added at 04:55 PM ---------- Previous post was at 04:55 PM ----------
Delete, Demolish and Destroy
-delete
-delete_recursive
Warning: Delete means exactly that - gone. There is no un-delete, there is only a backup. If you don't have a backup, you just lost whatever you deleted.
Please read my guide on backups before playing with this.
Delete Files:
Code:
Single Item:
delete("/path/to/file.extension");
Multiple Items:
delete("/path/to/file01.extension","/path/to/file02.extension","/path/to/file03.extension");
Pretty simple with the delete commands. In the Stock App Reference i've listed the direct edify delete commands for every stock app, so I won't get back into it like that here.
We will pull an example, though, the annoyingly broken stock calculator:
Calculator
Version: 2.1.2115332058.70840
201.25KB - /system/app/Calculator.apk
116.23KB - /system/app/Calculator.odex
/data/data/com.android.calculator2
Click to expand...
Click to collapse
Okay, so what we see here is this app has an .apk file at the location /system/app/Calculator.apk
In order to delete that, we need to put this line in our script:
Code:
delete("/system/app/Calculator.apk");
But wait! There's more. HTC includes a .odex file with most of the stock software on this device. The weirdly broken, poorly coded calculator is no exception, and we can delete that one too:
Code:
delete("/system/app/Calculator.odex");
Of course, that would turn into a huge script, if you had to type in the whole command every time you wanted to delete a file. To that end, we can group multiple targets to one action like this:
Code:
delete("/system/app/Calculator.apk","/system/app/Calculator.odex");
Which matches what I quoted from the guide.
Again, be sensible about this. You could group a large amount of apps into a single delete command, but then you're going to have to browse one line of code that goes on forever when you check it or have to change/fix it.
I'd recommend grouping a handful together, then just running another delete command with another group of apps if you have to do a whole lot of them. It makes it easier for you to figure out what's going on, and troubleshoot the script if necessary.
What's the point of fitting 100+ apps on one line of code, if it takes you 10 times as long to check it? Being too efficient to be productive, break it up a little bit.
delete is one of the most powerful commands at your disposal. It takes a lot of work to make something, but one stray delete command to wreck it all. Use with caution.
Delete Directories:
Code:
Single Item:
delete_recursive("/path/to/directory");
Multiple Items:
delete_recursive("/path/to/directory01","/path/to/directory02","/path/to/directory03");
If you thought delete was a powerful command, then delete_recursive just upped the bar.
Instead of being restricted to just single files, you can now nuke a whole folder. It also deletes everything in the folder, in case that didn't click yet.
Be even more careful in using this command, because doing somethine like delete_recursive("/system/customize/resource") to get rid of all the stock wallpapers and browser bookmark pictures you don't want sounds like a great idea...until you realize that folder also has your boot animations, default ringtones, and other things that you probably want to have.
( But that's okay, you made a backup first, right? )
To continue our calculator example from above, we might want to also delete the data file from the app. If you're going to get rid of something, you should try to get rid of all of it's pieces to prevent problems on the system.
Code:
delete_recursive("/data/data/com.android.calculator2");
That line of code deletes the data directory for the stock calculator, so now we can go ahead and replace it with something working right.
If we were going to be replacing just the calculator, or only one or two things here and there, then this method is acceptable.
If you can manage resetting all the permissions correctly, you can go ahead and delete a directory you have a copy of, and then just install it back there later in the script minus the stuff you didn't want. This is a hazardous road to take, but if you're deleting 37 out of 43 files in a folder, and you have to call them all by name...
( I have had mixed results with this, nothing that makes me eager to take this road if I can avoid it )
I'd like to get more into delete_recursive, but it's actually better addressed in the next post, so skip ahead to format.
---------- Post added at 04:56 PM ---------- Previous post was at 04:55 PM ----------
Format:
Well, here we are. The big fish of the "break stuff" commands. Often times, though, it's like using an axe when you need a hobby knife.
Unfortunately, the format commands seem to be broken for us at best, not usable at worst. If someone can put more time into it then i've been able to to figure out why or if there is a way to get them to work, then please don't hesitate to post here.
Meantime, while I was browsing XDA seeking answers, I stumbled across This Post and just started laughing and walked away from the computer for a little while.
And while that wasn't the answer I was looking for, I made the decision to drop it for now and just move on with the fix.
Code:
Here's the workaround:
delete_recursive("/cache")
Simply delete the directory.
Thanks Firon!
Now, here's where we get back to the part about mounting and unmounting the same partition multiple times in a single script. Follow along with this progression:
This block of code clears the cache:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p24", "/cache");
delete_recursive("/cache");
unmount("/cache");
...and this block of code clears all user data:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p23", "/data");
delete_recursive("/data");
unmount("/data");
And they are both self-contained. As long as neither is mounted before entering these 3 lines of code each, what you get here is Mount, Wipe, Unmount - done.
The reason why I picked /cache and /data to use as an example, is because when you put them both together like this:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p24", "/cache");
delete_recursive("/cache");
unmount("/cache");
mount("ext4", "EMMC", "/dev/block/mmcblk0p23", "/data");
delete_recursive("/data");
unmount("/data");
...you've just essentially called for a factory reset in your script. The next time the operating system boots, it will rebuild the cache and data partitions from whatever is installed on the device.
Remember, though, rebuilding the data partition will make it take noticeably longer to boot, and you should let it sit for a few minutes after it finishes booting.
The reason why people get choppy installs and errors from custom ROMs sometimes, is because as soon as the screen gets past the boot screens, they just start playing with it right away. What they don't realize is that the data partition is pretty complex, and a lot of that stuff is still being created, sorted and saved behind the scenes.
When you start making the device do stuff, before it's done what it's already doing, it tries to serve you first. It will clear parts of the data partition that are still being built from memory to do what you just told it to do.
Because of that, as you use it over time you run into the missing or corrupted files/directories/permissions/etc... because what was in memory was lost before it got saved on first boot.
Letting it sit for 5 minutes after first boot from a factory reset or any simulation thereof is vital to a smooth and proper install. Developers, the average user will not know this and getting the word out with your install will save you troubleshooting phantom problems users report to you that can't be duplicated by anyone else.
Now that we've gone through all that, here are two flashable zip files already signed and ready to use:
1 - Blue6IX_A01_Wipe.zip
- This will simply delete recursively /cache /data and /system.
Users: Flash this zip before installing a custom ROM or a CWM backup to eliminate 'bleed through' from the previous ROM/Install.
WARNING: If you do not have a /system partition waiting to install after flashing this zip, you will have a phone without Android on it. Check the ROM or CWM backup BEFORE flashing this zip to make sure you will have software on your phone when you are done. If this message scares you, then use the next listed flashable zip instead.
Developers: The three blocks of code that perform the wipes of these partitions should be the beginning of your installation script, if you are providing all the resources you need for your installation INCLUDING a pre-populated /system partition.
If you are not providing the /system partition in it's entirety, then see the next script:
2 - Blue6IX_B01_Wipe.zip
- This deletes recursively only /cache and /data.
Users: Flash this zip to simulate a factory reset. Your data partition will be rebuilt on the next boot by what's installed on the device. This does not delete any system programs, but any apps installed through any market or user data of any kind ( contacts, notes and etcetera... ) will be lost.
This flashable zip is just like doing a factory reset from the settings menu, except it's from recovery.
Developers: If you are just modifying the stock /system partition, then the code in this script that isn't ui_print("") should be at the beginning of your install script.
If part of your install instructions include "do a factory reset" or "format /data and /cache" then just insert this code as the first thing your installer does and you can take that hassle out of their hands.
Since we have people of all levels of experience and ability flashing ROMs, we should try to take as many extra steps out of their hands as possible - it's just easier for everyone around.
This will ensure that no random data gets left over from the old environment before you changed it. It ensures that your information gets written correctly - as long as you play nice with the pre-existing /system partition.
So notes on these scripts:
1 - A01 CAN LEAVE YOU WITH NO ANDROID SOFTWARE ON YOUR PHONE IF YOU HAVE NO /system PARTITION TO INSTALL BEHIND IT!!
* - On the user level, I run flashable.zip before I restore a clockworkmod backup. This cleans out those 3 partitions and lets the backup write to fresh memory space.
* - On an advanced user level, I usually just install the system.img file from the CWM backup and let it build the cache and data on the next boot. Seems cleaner to me that way.
- I wrote all the text in that prints to the screen to give it a cleaner, less confusing look. When the script is done, the interface is much less busy from random notices and not as intimidating to casual users.
+ - Neither of these flashable zips has anything to do with boot or recovery images or partitions. It's all cache, data and/or system.
( I don't know what would happen if you powered off without a /system partition. I'd think that it would be able to get to the recovery utility ( Clockworkmod ) where you could flash a /system partition, CWM backup or ROM. )
(( I'm not brave enough to find out on my phone, because while i'm 90% sure it would be fine, i'm not willing to try without more research first - Don't hold me responsible if you wipe /system and then power off and something bad happens...So make sure you have a new /system partition ready to install if you use Wipe A01 ))
And, last warning. If you don't know what you're doing with these flashable zips, then don't use them. Ask a question here first, i'll be happy to answer as best as I can.

Wow this is INCREDIBLY helpful and well-done. Thank you!

Dam this woulda came in handy two weeks ago when i was a newbie at these update scripts. LOL. I researched for hours trying to get the script right and i got it. oh well better late then never.
Sent from my Supercharged MT4G Slide Running Undead's Senseless ROM using xda premium

Undeadk9 said:
Dam this woulda came in handy two weeks ago when i was a newbie at these update scripts. LOL. I researched for hours trying to get the script right and i got it. oh well better late then never.
Sent from my Supercharged MT4G Slide Running Undead's Senseless ROM using xda premium
Click to expand...
Click to collapse
lol hahaha lets hope people take the time to learn this also makes Our jobs alot easier..again Great Job blue!

Hi! Well, i have a question.
Is that possible to Freeze an app with updater-script?
How could i do that?
Thanks, awesome guide, mate!

(noob-ish) AmazonKindleFire7-2019: Where to put startup scripts eg. iptables rules.

Hi all.
I'll make my apologies if this post is in the wrong place or against any rules, if so sorry for creating more work for the mods!
I dabble in Linux, so bear with me here. I am not a complete noob, but to some of you folks here, I am certainly in the gutter of the pecking order
So I got a cheap Amazon Kindle Fire 7" 2019 model, and thanks to this forum have used diplomatic's mtk-su tool to get superuser (su/root) on adb and Termux, which has allowed me to get rid of a lot of Amazon bloat and data collection, and system apps that just aren't useful, replace the launcher and generally make this tablet useable.
I have not, as of yet, installed a modified boot loader/twrp/magisk stuff. I am trying to avoid that route, as there is quite a chance of me messing up and I am destructive when trying to take things apart (maybe unplug battery required).
On to network interface security.
I've installed NetGuard, read a lot and understand the idea behind how it works. Dump unwanted traffic to a sinkhole VPN connection.
I would like to utilise iptables. After using mtk-su in termux, I can access and create rules and these apply instantly. All seems to work as expected, however, as we all know iptables rules are not persistent and a reboot clears them all out and replaces with the stock ruleset - which is a bit too open and has strange stuff in it.
Q:
Run a my_rules script on startup.
So I can write a .sh script with the iptables rules I want applied. It won't have root permission and won't run, but if executed at boot time by another script? ( .rc ) which does have permission to do root things, the script should run, rules be applied and I can be happy.
For one thing, I am not sure quite where to add my script. I have read somewhere that the .rc files I can see are actually created from a secure/encrypted/compressed store which is uncompressed at boot time. So editing an .rc file which is freshly created is pointless.
Secondly, I guess import <name of script -no.sh extension->? won't work, and will probably need service <name of script> and oneshot or another command.
Am I going to have to go the twrp/magisk route? Do I really need to make changes to more than I can access with root and a terminal on the running device?
Thank you for your time and patience to read this post.

I am obviously not reading enough!
It seems the /system/ folder is all read-only. I can't even "cp /system/bin/install-recovery.sh /system/bin/install-recovery_bak.sh" to back up the existing.
Will try mounting /system as rw, maybe.
*edit*
OK, a major problem is that /system is not writable. mount -o remount,rw /system or /dev/block/dm-0 looks like it works but the location still cannot accept new files created or changes to existing files.
There seems to be a watchdog or something running which prevents changes to the mounting here.
So, I conclude this is what people mean by rooting - booting a modified system which allows access to these such places. Having su in a terminal /adb is all great, but still can't do everything - opens up the opportunity of going further and changing boot loader, twrp and magisk though.
Sigh, I was hoping to avoid that path.
I can, at least, launch a small shell script which would leverage mtk-su to run and write my iptables rules into the running system. But this would be a manual exercise and I am bound to forget to apply it.
If mods wish to delete this thread, I have no objection. but maybe it might help someone else in my situation to understand a little more or maybe not.
I think I am showing how much of a noob I am here. Sorry.