deleting system files with Tasker.
Saad Chaaban
So here is my Task Plan:
1. Task: on System boot, show a message "removing apps"
2. Task: remove file "/system/app/calculator.apk" (use root is checked, continue on error is checked <- i use it because not every rom has every pakage i want to delete)
3. Task: show a message "you can now use your phone"
So i restarted my phone for a test.
1. Task: on System boot, show a message "removing apps"
2. Message appears that Tasker got SuperUser rights.
3. nothing happens for a second
4. Task: show a message "you can now use your phone"
After checking in the app drawer the "Calculator.apk" is still there
So what am i doing wrong?
Ivelin Ivanov
The /system folder is set to read-only by android, so you can't delete stuff from it or copy to it. You will need to set it to read-write first with a Script -> Run Shell action:
mount -o rw,remount -t yaffs2 /dev/block/mtdblock0 /system
Then delete all files you want, then set it back to read-only:
mount -o ro,remount -t yaffs2 /dev/block/mtdblock0 /systemBut since you will be running shell commands for that task anyway, I suggest you do all the deleting with shell commands as well - this way you won't have to insert an action for each file you want removed and you won't end up with 389484 Delete File actions ;). It will probably also be a bit faster than using Delete File actions, but I'm not sure about that. Anyway, if you want to do it with shell commands, you could put the following in the Run Shell action:
mount -o rw,remount -t yaffs2 /dev/block/mtdblock0 /system;busybox rm -f /system/app/{FILE_1,FILE_2,FILE_3,...,FILE_X};mount -o ro,remount -t yaffs2 /dev/block/mtdblock0 /system
A couple of notes:
1. You only need to run one shell action - all commands can be listed there and just need to be separated with semicolons (see above)
2. By typing "rm -f /system/app/{file1,file2...}" you avoid the need to write the full path everytime, instead of "rm -f /system/app/file1 /system/app/file2 ..."
3. The built-in version of the "rm" command in android appears to not support the -f option, but you need that one, otherwise it will not remove anything if there is a file listed that doesn't actually exist. Basically the -f option is the "Continue Task After Error" option of the "rm" command. But since the built-in version of rm doesn't support it, you'd need to install BusyBox, for example from here - https://play.google.com/store/apps/details?id=stericson.busybox
4. If you don't want to or can't install busybox, you can just use "mount -o...... /system;rm /system/app/{file1,file2,...}" instead, but then you'd have to make sure that all the files in that list actually exist, maybe by using a variable array and checking for nonexistant files with Tasker before running the shell script. So you'd maybe create a variable %list_of_files and do a For-loop on it to remove all missing files, then use it in the shell script - "rm /system/app/{%list_of_files}". %list_of_files would be a comma separated list of all the files you want to remove. I assume you can figure out how to do that by yourself, but it really is a lot easier to just use busybox.
regis herrmann
Yar, since you actually have to root your phone for this task to actually work, might as well install busybox while you're there.. Not doing so would roughly equate having a condom but keeping it in your pocket while having sex with a random stranger : not really useful in any practical way.. ^^
Interesting -if not to say crucial- is that the shell command to set the /system partition to R/W actually varies with the brand/model of your device and is usually specific to a brand or family of devices.. E.g., Ivelin I can tell frim your command that you most probably own an HTC device, since mtdblock0 is mostly HTC specific. On a Samsung device it is rather /dev/block/mmcblk0pX, where X designates the partition number (which also doesn't necessarily have to be the chronological order of the actual partition layout, at that, to further confuse matters).
So I suggest you actually do a bit of research on the partition layout specific to your device, -and to backup your whole phone before trying anything at all-, as root can be a very unforgiving thing that has the potential to turn your day into a (totally communicationless) nightmare. Accidentally wipe the secondary bootloader for example, and you'll wind up toting a 500$+ mp3 player -at best.. Such a mistake cannot be righted without access to pro hardware (i.e a JTAG device) and a lot of knowledge. ;)
(Sent from my supercharged, hot-rodded, nuclear-fueled Samsung Galaxy Note2...)
--
You received this message because you are subscribed to the Google Groups "Tasker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/groups/opt_out.
TomL
Personally, I would *not* use a wildcard delete in a system dir.
Lastly, if op just doesn't like seeing the calc app, most launchers let you hide an app from the drawer.
Tom
Ivelin Ivanov
Interesting -if not to say crucial- is that the shell command to set the /system partition to R/W actually varies with the brand/model of your device and is usually specific to a brand or family of devices.. E.g., Ivelin I can tell frim your command that you most probably own an HTC device, since mtdblock0 is mostly HTC specific. On a Samsung device it is rather /dev/block/mmcblk0pX, where X designates the partition number (which also doesn't necessarily have to be the chronological order of the actual partition layout, at that, to further confuse matters).
Actually I have a Huawei Ascend Y300 and when I run "mount" in the terminal emulator, it lists the /system partition as being under /dev/block/mmcblk0p17, so in that regard it's more like a Samsung. But if I use that mounting point to try to mount /system as R/W, then I inevitably get "bad option" as a result and nothing happens. So I searched around the internet a bit and tried a couple of things and the only one that worked was the /dev/block/mtdblock0 one, so I assumed that that one would work for a lot of other phones as well, regardless of their manufacturer.
BTW, can you even brick your phone from within android? I thought you can't even find the bootloaders because android doesn't have access to the partition where they are located? Or is it possible to gain write access to them? Also, even if you could and did delete the bootloader, wouldn't the recoveries (CWM/TWRP) still work? (I'm not arguing, just asking, since I myself only transitioned from a feature phone to android a bit over 2 months ago and don't really have any previous *nix experience either.)
regis herrmann
Oh, my bad... but since huawei sounds very chinese to me, I guess they must've copied an HTC reference board, or maybe they're using them under license. Whatever... ^^
regis herrmann
Short answer : yup, it is possible to brick a bóoted phone, if it's rooted.
Stock Androids don't have a root account (although the UID 0 that is reserved for the superuser exists, it's visible in the init.rc and the files listing file/directory permissions -the one the recovery uses when you're doing a 'fix permissions' after installing a paranoidandroid rom, for example), but rooting them 'activates' it back, giving the user and the whole system access to all the hidden partitions...
It depends on the target file/partition, everything that is mounted during normal use cannot be wiped while powered on, most of those have to be manipulated via adb under the recovery *before* bootup.
But since the primary and secondary bootloaders are only used when the system is starting (and actually never get mounted by it), it's very possible (on some devices it's even trivial) to wipe'em out if you have superuser privileges, putting the phone out of commission as soon as you'll try rebooting it... Your only çhance then (provided that you realize that you did fatally screw up before it's too late, I mean) would be to fix the problem by dd'ing a backup of those partitions back on -and to not reboot the phone before you've done just that. But this supposes that you took the precaution to make a dd backup of those partitions beforehand, something that most people carelessly neglect to do. ;)
regis herrmann
Ánd no, CWM couldn't help you either, because it's fired up by the bootloader also.. the bootloader is the gateway to everything, even the 'download mode' that saves you from the majority of screwups usually... ;)
Basically : no more bootloader + phone rebooted before having been fixed = very expensive paperweight + an arm and a leg to spend to get it fixed by your nearest service center (which usually won't let themselves be arsed by such things, and charge you a full motherboard replacement, just to pass you the temptation to mess with their products ever again... :s)
Ivelin Ivanov
Ánd no, CWM couldn't help you either, because it's fired up by the bootloader also.. the bootloader is the gateway to everything, even the 'download mode' that saves you from the majority of screwups usually... ;)
Basically : no more bootloader + phone rebooted before having been fixed = very expensive paperweight + an arm and a leg to spend to get it fixed by your nearest service center (which usually won't let themselves be arsed by such things, and charge you a full motherboard replacement, just to pass you the temptation to mess with their products ever again... :s)
Got it. Thanks for explaining, I've learned something new again :)
TomL
mount -o rw,remount /system
rm -f /system/app/%list_of_files
mount -o r,remount /system
Are you willing to bet that %list_of_files would never be accidently set to any of the following:
[empty string]
*
..
.
../..
Seriously? Worth the risk?
Tom
regis herrmann
Uuuuugh... Seeing a rm -f command and a /system on the same line of code gives me chills down the back of my neck... ^^
Although it's a thing I might try on one of my linux or BSD boxes (with an R added for good measure and recursivity, like 'rm -Rf'.. they're old machines and are easily reinstalled after all. I've even scripted the packages they have to install in order to make the process fully automatic without any intervention from me), just for the hell of it and to see wot happens, that's something I'd never try on my 600$+ phones... Talk about playing with matches right next to a cooking pan filled with boiling ethyl ether (why anyone would have such a thing on their stove, I'll leave to your guessing... xD), that's pretty close -although far less dangerous towards your physical integrity... :p
regis herrmann
If anyone is interested in learning more, head on over to my usual hangout : xda-developers.com, there's almost surely a forum section dedicated to your own device(s), it's a gold mine for anyone who doesn't want to brick their phones but still want to squeeze every last ounce of performance it has to offer ;)
As an example, check this out, it's from the Samsung Galaxy S2 forum (a phone I've owned for 2 years now, and which is very near indestructible -has to be in order to survive me for that long... I must have totally taken it apart and reassembled it about 20 times by now, I guess I could even do it blindfolded, much like a US marine with his trusty M-16 (or M-4). :p), and describes in detail the .pit file for it (basically it's the files that tell the flashing program how to partition the internal memory before actually flashing a custom ROM on it (every samsung device running android have one such file, but they can even differ between variants of one model) :
http://forum.xda-developers.com/showthread.php?p=40456199
It doesn't tell you the mountpoints the partitions will be mounted on though, but a bit of research and some guesswork will tell you that factoryfs = /system, datafs=/data, ums=/sdcard, cache=/cache, etc. Hidden is a 512mb partition that gets mounted to /preload but only stock roms use it, to store some stuff during their install, it's unused after tha5, and custom kernels like the siyah kernel use it as a secondary /system for dual-boot setups. (The note2 follows much the same layout, but /system and /data got fused together under factoryfs in a bigass 2gb partition..)
Interesting to notice : there're two 8mb partitions reserved for kernel and recovery, but only the recovery is user, as the kernel and recovery are compiled together into a single initramfs ramdisk, why samsung chose to lim8t the s2 like this is still unclear to most of us :s
Also, notice the quite complex boot sequence that actually involve 5 different binaries (that are each an easy target to wipe for an unsuspecting nerd messing around, or an ill-meaning malware -virus, worm, you name it- if it somehow gets root privileges... And how there are actually 2 secondary bootloaders (='SBL') in the S2, a primary and a backup in case the primary is accidentally wiped. But the catch is : the secondary SBL partition only gets populated the first time you'll flash an update package for the stock ROM (and by this I mean a full rom, flashing a stock kernel won't work), when the device comes out of the factory the backup partition is blank... Many an unsuspecting user (who didn't properly do their homework and research things *before* they start messing with their device) has been caught unawares by this small catch, and had to hand some $$ over to a samsung service center because of that apparently small detail (that isn't actually documented anywhere that I could see, it's at XDA that I learned this soon enough to be of any help to me.. ^^)...