[SCRIPT/FIX] Internal sdcard permissions (/data/media/) - Android Q&A, Help & Troubleshooting

This should be applicable to any ROM on devices which share internal storage for applications and the internal "sdcard" (Note II, SGS3, probably others). Symptoms may include inability to take screenshots and other failures, and will usually show a "Permission denied" in logcat for files under /data/media/. The underlying problem is that permission is denied to the filesystem, even by the root user when the ROM is booted (this is strange and I still don't understand why). Running "Fix permissions" did not fix this issue for me (that script doesn't change any permissions on the sdcard).
When booted into recovery (ClockworkMod was tested in my case), root has the ability to reset the permissions properly. To fix the problem, connect with adb while booted in recovery and run the following commands to correct the permissions:
Code:
chown -R media_rw:media_rw /data/media/
find /data/media/ -type d -exec chmod 775 {} ';'
find /data/media/ -type f -exec chmod 664 {} ';'
UPDATE (Credit to @Quinny899) If that does not work, you may also want to reset the SELinux contexts for the media partition with this command:
Code:
restorecon -FR /data/media/
Hope this helps! :victory:

I recently restored a Nandroid backup of my old Nexus 7 on a replacement Nexus 7. Most everything worked okay, but screenshots, deleting certain files and directories, and other basic operations weren't really working, and "Fix permissions" didn't help.
Running the commands here worked like a charm! I used TWRP and I have JellyBeer 4 on my Nexus 7. Thanks!

skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!

xak944 said:
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
Click to expand...
Click to collapse
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!

Yeah it's kinda funny. I had that script posted up in the ADBsync thread back in February because I noticed things could start acting funny when I restored an entire sdcard backup to one of my devices. But hey, great minds think alike! Good work all around!
Thanks @TheByteSmasher for bringing another use for the zip to my attention! I didn't know those things had a tendency to go awry on their own as well!
Edit:
Here's the edify script equivalent of the above, plus the proper original perms for /data/media itself, and the special perms that CWM likes its subfolder to have (root + all). TWRP keeps its backups under the primary user subfolder (/data/media/0) and doesn't seem to care as much.
cwm-sdcard.Fix.Permissions.zip/META-INF/com/google/android/updater-script:
Code:
ui_print("");
ui_print("sdcard Fix Permissions Script");
ui_print("by osm0sis @ xda-developers");
show_progress(1.34, 0);
ui_print("");
ui_print("Mounting...");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.2);
ui_print("");
ui_print("Setting /data/media to media_rw and fixing...");
set_perm_recursive(1023, 1023, 0775, 0664, "/data/media");
set_perm(1023, 1023, 0770, "/data/media");
set_progress(0.8);
ui_print("");
ui_print("Setting /data/media/clockworkmod perms...");
set_perm_recursive(0, 0, 0775, 0777, "/data/media/clockworkmod");
set_progress(1.0);
ui_print("");
ui_print("Unmounting...");
unmount("/data");
set_progress(1.2);
ui_print("");
ui_print("Done!");
set_progress(1.34);
Available over in my Odds and Ends thread as TheByteSmasher mentioned before.

Nice. Good to know this is a well known issue, I thought I was nearly alone (and it drove me up the wall for a while until I figured it out).
Does anyone know what is technically causing even the root user not to be able to write? I'm curious.

Probably because even root apps only run root commands when they need to, so for simple stuff could run into the same issue. Just a guess, but makes sense.

I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').

xak944 said:
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
Click to expand...
Click to collapse
Osm0sis actually states in the description of his zip, that when you use ADB push to put some stuff on the SD it can mess with the permissions... that's what did it for me.. but I guess a nandroid restore can cause it too depending on how it performs the action.
Sent from my Nexus 4 using Tapatalk 4 Beta

I'm ditching the idea of editing fix_permissions. The way they do all the system files is extremely intelligent and done on-the-fly based on the contents of certain system files to trace through. Adding something specifically for internal sdcards, even with the appropriate checks, would be a hack compared to all the really great work they've done to make the script device-nonspecific.

Deleted

1990mustafa said:
Deleted
Click to expand...
Click to collapse
Could somebody point me in the direction of how to do this for the Note 3 SM-9005 please?
I have an internal SD permissions issue and the flashable zip doesn't work, I presume because the directories are located slightly differently.
Many thanks

i m also stuck in same boat as none of scripts work for note 3... need some help / guidance here ..

You saved me, i was playing with ubuntu touch and i forgot that symbolic links and chown always modify the original directory and twrp could not fix the permissions!

Thank you! Works like a charm! :highfive:

Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
[email protected] said:
use for fixing access
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Worked a dream, might be useful for anyone else

Quinny899 said:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
Worked a dream, might be useful for anyone else
Click to expand...
Click to collapse
worked perfectly!

Hey, big THANKS to everyone who contributed to this thread. I restored by SD a different way than I used to do it and had this issue. I figured it was a permissions issue but couldn't get the 'Fix Permissions' function in TWRP or ROM Manager to fix it (now I know why). This saved me, much appreciated!

Quinny899 said:
Code:
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Oh man, so it was SELinux causing these issues all along!? I wonder why my original fix worked then since it didn't reset the SELinux context... Oh well, good to know.

Thanks @TheByteSmasher for leading me to the right solution
TheByteSmasher said:
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Click to expand...
Click to collapse
Thanks again
osm0sis said:
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc.
General Information
In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller scripts and zips I've created that I don't think merrit their own separate threads. This is partially for my own sanity and will hopefully make it easier for others to find some things as well. A lot of the stuff here was developed with the GN or N7 (my devices) and Windows in mind, but could generally be applicable to most devices either out-of-the-box or with some slight modification. If you see something that inspires you, go ahead and mod it, just let me know and give me some credit somewhere. If anyone would like to know the specifics of what's in a particular script that I haven't already linked to more information on, just let me know and I'll post that in here as well. Thanks!
Misc./Batch Tools
AnyKernel 2.0 (many devices) - link
AnyKernel was a simple template for an update.zip that could apply any kernel to any ROM, regardless of ramdisk to reduce the chance of any issues arising from the custom kernel pairing. The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. AnyKernel 2.0 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the install experience.
Android Image Kitchen (many devices) - link
A collection of Windows/Android ports of the necessary Linux utilities for Android image (kernel+recovery) mod work, and my own automation script to unpack, edit and repack the ramdisk. Other guides/scripts exist but none of them are universal for target device, compression and/or developed for Windows/Android. Now also Linux builds to bring my improved featureset back to where it came from. Has been extremely useful for me in my messing around with kernel ramdisks.
ADB Screenshot (all devices) - attached
Take screenshots while in recovery. Useful for development of recovery apps or error reporting. Original method had lots of different threads around with the general method for various devices but I figured out a couple tricks required for getting it working on the Galaxy Nexus and then automated the process. Tested and confirmed working with both pixel formats of CWM and TWRP. More information in this GN Q&A FFmpeg thread. New method uses fb2png and should work on all devices.
ADBsync sdcard Backup (many devices) - attached
Backs up the entire sdcard so that you can have a complete snapshot of your device when you make periodic backups, and be able to restore things exactly as they were. Automates the sync process of Renate NST's great ADBsync utility which makes only newer files get pulled, significantly decreasing backup time for the sdcard compared to "adb pull". Original version posted in the old ADBsync thread. Defaults for devices with /data/media/ internal sdcards (Nexus devices, etc.), but is easily customizable to backup other mountpoints.
Flashable Zips
Nexus BootUnlocker script (GN, N4, N5, N7 '13, N10) - attached
I don't know about everyone else but sometimes I find I've rebooted into the bootloader only to realize I've forgotten to unlock it in segv11's excellent BootUnlocker App beforehand. Well, I decided to make a BootUnlocker Script for my Galaxy Nexus so I could just boot to recovery quickly, unlock, then adb reboot-bootloader (or use my Reboot To Bootloader script below) to get back without having to fully boot the OS to make the change. Also extremely useful in the case you aren't able to boot. As with the app there is no data loss like there would be with fastboot, allowing you to relock for safety. Originally posted in the GN EDIFY Scripting thread. Modified for the newer Nexus devices and combined into a single Nexus BootUnlocker zip with tamperbit reset support added using information from the BootUnlocker App Dev thread.
N7 BootUnlocker script (N7 '12) [creation guide] - link
The Nexus 7 2012 is a special case. Per-device encryption of an entire partition makes it impossible to support the N7 '12 in a simple root app, or flashable zip as above, however using my guide and included script you can now create a working BootUnlocker Script Zip for your specific device. As with the above scripts there is no data loss like there would be with fastboot, allowing you to relock for safety.
Flashify script (many devices) - attached
This script zip makes flashing boot.img (kernel), recovery.img, and radio.img/modem.img (baseband) files via recovery simple. Inspired by cgollner's powerful and visually stunning Flashify App, it aims to save the average user the hassle of repacking their own image zip, or using the command-line or fastboot to flash it. Place an appropriately named file in the same directory as the zip and flash away! Should work on all emmc devices with normal partition naming ("boot", "recovery" and "radio" or "modem") which accept Android standards-compliant images. Extremely handy when used with amarullz' brilliant AROMA Filemanager, and/or my Android Image Kitchen: Mobile Edition (linked above).
Kernel Emergency Reset script (many devices) - link
Basically a go-to cure-all for custom kernel users experiencing issues after an upgrade due to old settings left over in a kernel control app (eg. franco.Kernel updater, Trickster, etc.), or problematic init.d/userinit.d scripts. It's also useful if you just want to make sure you're running clean defaults without conflicts.
Reboot To Bootloader script (all devices) - attached
Those who prefer using CWM may have noticed a couple of things missing that the other popular custom recovery, TWRP, has built-in. One of these is a file explorer/manager, which is answered by amarullz' brilliant AROMA Filemanager. Another thing I found myself wanting is a way to reboot back to the bootloader once I'm in recovery, so I created this very very simple flashable zip script. (No longer required on CWM >=6.0.3.5). Note: Once in the bootloader, "Start" will boot you back to recovery. Not sure why, but it's not a big deal, just reboot normally from recovery at that point.
sdcard Fix Permissions script (many devices) - attached
A little flashable zip script to fix ownership and permissions of files and directories on the sdcard to what they would be if Android OS had put them there itself, since some apps can't access pushed files that have root.root as owner/group. This is useful when restoring to your sdcard backup, as with my ADBsync sdcard Backup batch script above, since generally, pushed files get root.root from adb shell and higher permissions than usual. Also a solution for a bug where sdcard files get lower permissions somehow, resulting in similar access problems. Currently written for devices with /data/media/ internal sdcards (Nexus devices, etc.), but could easily be modified for other mountpoints.
nano Terminal Editor v2.2.6 Installer (all devices) - attached
A simple installer to push bgcngm's great Android port of the nano editor binary to /system/xbin/ along with the required files in /system/etc/terminfo/. It can then be used from Terminal while booted from that point on. Each time you flash it also temporarily enables use in recovery by pushing a script to /sbin/nano with the required environment variables, so you can then trigger it from recovery shell or the console in amarullz' brilliant AROMA Filemanager. Makes it extremely easy and worry-free to tweak and mod on the go, knowing you can edit the faulty build.prop or init.d script if something goes wrong. This script could also be added to recovery to make the functionality permanent.
odex Script Installer (all devices) - attached
Based on the great work and binaries from this thread, a simple installer to push my odex script along with the required dexopt-wrapper and zip binaries to /system/xbin and set the appropriate permissions. Automates the procedure to odex any apk or jar from the commandline to potentially improve performance. Dalvik runtime only. Also uses cut from busybox.
Kernel init.d Support Injector (many devices) - attached
Following from great ideas by Captain_Throwback in my AnyKernel2 thread and using script from my Flashify script above, this AK2 zip will inject basic init.d bootscript support into any kernel ramdisk on any emmc device with normal partition naming and using the Android bootable image standard, without having to bloat a ramdisk using a busybox binary. This zip is also signed, so could potentially be used with stock recovery on a locked bootloader, but that depends on the stock recovery supporting grep, etc. for the zip script to perform the required file changes.
Dev Team init.d Pack Installer (all devices) [see "950iosettings, etc." below] - link
A simple installer I wrote to create the /system/etc/init.d/ directory, extract the latest init.d scripts as published by the "Franco's Dev Team" tuning collective (of which I'm a member), then set correct owner, group and permissions to the entire init.d directory. Link points to my Dev-Host since these may still be subject to change from time to time. If you are a developer and would like to include these tunables/scripts in your kernel or ROM please provide credit. A lot of time and effort has gone into this project and that's all we ask.
Credits & Thanks: All authors of any included binaries and libraries for their amazing work. Anyone who's helped me with these projects along the way.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
XDA:DevDB Information
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc., Tool/Utility for the Android General
Contributors
osm0sis
Version Information
Status: Stable
Created 2013-11-13
Last Updated 2015-03-30
Click to expand...
Click to collapse

Related

[DEV][Q] Adding root / su permissions to AOSP

I've been building from AOSP for a few weeks now and have a decent product, but there's a couple things that I have yet to work out.
First is adding root permissions (i.e. changing the permissions to su) from source. Currently, I have pulled this[URL] code from ChainsDD's github into my tree and added the Superuser.apk via my [URL="http://github.com/rmgeren/android_vendor_rmg/blob/master/products/rmg_passion.mk"]vendor file. Some things work, others don't. Rommanager seems to be fine, but Titanium Backup isn't. I think the problem is that su is installed into /system/bin but not xbin. When I use dsixda's rom kitchen it installs to both places and sets the permissions for su in my update-script.
Second part is more of a "like to have." I make a nice ROM, install it via RomManager (like everyone should!) and, as soon as I boot, I'm back into RomManager installing the custom recovery image.
Here's the question part:
How do I get su to install to /system/bin with a symlink to /system/xbin?
Can I just pull koush's recovery image source into my build and have a nice, custom recovery?
Is it better to just somehow not build the recovery image? How would I make that happen?
RMGeren said:
I've been building from AOSP for a few weeks now and have a decent product, but there's a couple things that I have yet to work out.
First is adding root permissions (i.e. changing the permissions to su) from source. Currently, I have pulled this[URL] code from ChainsDD's github into my tree and added the Superuser.apk via my [URL="http://github.com/rmgeren/android_vendor_rmg/blob/master/products/rmg_passion.mk"]vendor file. Some things work, others don't. Rommanager seems to be fine, but Titanium Backup isn't. I think the problem is that su is installed into /system/bin but not xbin. When I use dsixda's rom kitchen it installs to both places and sets the permissions for su in my update-script.
Second part is more of a "like to have." I make a nice ROM, install it via RomManager (like everyone should!) and, as soon as I boot, I'm back into RomManager installing the custom recovery image.
Here's the question part:
How do I get su to install to /system/bin with a symlink to /system/xbin?
Can I just pull koush's recovery image source into my build and have a nice, custom recovery?
Is it better to just somehow not build the recovery image? How would I make that happen?
Click to expand...
Click to collapse
For the symlink, just add the following to your updater-script (assuming you're using a binary update) immediately after you extract the system partition.
Code:
symlink("../xbin/su", "/system/bin/su");
If you include a recovery image in your build you will overwrite the users' recovery image which isn't such a good idea for a rom... I'd leave that one alone to be honest. And problems writing the image and you could bork their phone. It's easy though, just create the .img, put it in the root of your update zip and install it using your updater-script as such:
Code:
assert(package_extract_file("recovery.img", "/tmp/recovery.img"),
write_raw_image("/tmp/recovery.img", "recovery"),
delete("/tmp/recovery.img"));
I don't understand your third question sorry...
Thanks for the response! I actually solved the problem by including busybox as a pre built package and pulling the su source from chainsdd
Before, I was including the binary su
By compiling from his source, it installs the symlink correctly.
Sent from my Nexus One using XDA App

CWM for Galaxy Player 5.0 US (YP-G70XAA)

Hello all,
I'm working on porting CWM to our beloved Galaxy Player 5.0 US edition. I'm loosely following the guide here. I cannot promise that I'll be able to port it successfully, but I can promise that I'll brick my device at least once.
tl;dr : This post says some guy is working on CWM. Woot!
-apapousek
Your sending it to the people are you? And good luck, I only wish I knew how to do this
Apapouseck-
Are you a dev? PM me and give me your email address please. I have a question.
Sent from my Galaxy Nexus using xda premium
azoller1 said:
Your sending it to the people are you? And good luck, I only wish I knew how to do this
Click to expand...
Click to collapse
Of course I'm distributing it. Once I get a working copy, it's being thrown on github, or my own server, and given freely, open source, blah blah blah. No proprietary crap, except maybe enough drivers to get it up and running. But sources for those, too.
cramjammer said:
Apapouseck-
Are you a dev? PM me and give me your email address please. I have a question.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
Well, technically not a dev. I just like taking software, messing around with it, seeing what it can do. My email address is [email protected]
Can't wait
Sent from my YP-G70 using Xparent Blue Tapatalk
That post, as it says, doesn't cover Samsung devices. It turns out that a while back, Koush made a commit to mkvendor.sh that allows it to operate without an example boot.img.
However, the problem is that there's a remaining bug in mkvendor.sh that TMPDIR is not set in the code path that is triggered when you don't specify boot.img
Right now I'm at a state where CWM starts and runs, but somehow it is treating the tilt sensor as volup/voldn input - so the thing scrolls eternally.
Entropy512 said:
That post, as it says, doesn't cover Samsung devices. It turns out that a while back, Koush made a commit to mkvendor.sh that allows it to operate without an example boot.img.
However, the problem is that there's a remaining bug in mkvendor.sh that TMPDIR is not set in the code path that is triggered when you don't specify boot.img
Right now I'm at a state where CWM starts and runs, but somehow it is treating the tilt sensor as volup/voldn input - so the thing scrolls eternally.
Click to expand...
Click to collapse
Maybe you need the s3c-keypad file to correct this or changing somewhere in the source /dev/input/eventX to another one.
Looks like I need to figure out how to filter out /dev/input/event1, and only pay attention to event4 and event5 (or just event4)
I've got something that seems to be working... Needs a lot more testing. Recovery is important, and if it's broken, can really **** up someone's device.
Also, the way I got it working seems to be a massive hackjob, I need to chat with Koush if there's a better way to do things. Either that or a LOT of CWM porters have done source code modifications without publishing them (Which, while not ideal is allowed for CWM since it is Apache-licensed not GPL.)
Entropy512 said:
I've got something that seems to be working... Needs a lot more testing. Recovery is important, and if it's broken, can really **** up someone's device.
Also, the way I got it working seems to be a massive hackjob, I need to chat with Koush if there's a better way to do things. Either that or a LOT of CWM porters have done source code modifications without publishing them (Which, while not ideal is allowed for CWM since it is Apache-licensed not GPL.)
Click to expand...
Click to collapse
I'm glad you got a clockworkmod which seems to work. Let us know what koush says and if it'll be official support to CWM on our devices.
Yup.
Main things you need to consider when building:
1) The recovery.fstab for Samsung devices isn't appropriate for CWM. One appropriate for CWM has just three entries:
mount point, filesystem, device
The filesystem format options (fourth and fifth columns) seen in stock recovery.fstab will screw up CWM
2) /dev/input/event1 MUST be filtered on SGP5 US devices (and probably international too) - the accelerometer spams keystrokes. This is in ev_init() in minui/events.c
3) Recovery.fstab can't be in /etc - but this path is hardcoded in CWM so you must change the path in roots.c - SGSII seems to use /misc instead of /etc - this is in load_volume_table() in roots.c
Entropy512 said:
Yup.
Main things you need to consider when building:
1) The recovery.fstab for Samsung devices isn't appropriate for CWM. One appropriate for CWM has just three entries:
mount point, filesystem, device
The filesystem format options (fourth and fifth columns) seen in stock recovery.fstab will screw up CWM
2) /dev/input/event1 MUST be filtered on SGP5 US devices (and probably international too) - the accelerometer spams keystrokes. This is in ev_init() in minui/events.c
3) Recovery.fstab can't be in /etc - but this path is hardcoded in CWM so you must change the path in roots.c - SGSII seems to use /misc instead of /etc - this is in load_volume_table() in roots.c
Click to expand...
Click to collapse
Koush put this up at rootzwiki.
apapousek said:
Koush put this up at rootzwiki.
Click to expand...
Click to collapse
I've seen it - if you read it, it's just some "best practices" document that says what you should do after you've managed to compile a working CWM recovery binary - however, I have not seen a single kernel that integrated CWM the way he says, even ones coming from very talented developers (like codeworkx)
Entropy512 said:
I've got something that seems to be working... Needs a lot more testing. Recovery is important, and if it's broken, can really **** up someone's device.
Also, the way I got it working seems to be a massive hackjob, I need to chat with Koush if there's a better way to do things. Either that or a LOT of CWM porters have done source code modifications without publishing them (Which, while not ideal is allowed for CWM since it is Apache-licensed not GPL.)
Click to expand...
Click to collapse
Could you post how you achieved this partial state? I'm busy downloading cm, which is just fun
I'll try to when I have some time... next few days are going to be busy.
Very quick summary:
Need to fix mkvendor.sh so TMPDIR is set when you don't provide a bootimage argument, otherwise the device tree doesn't get created properly
Need to pull recovery.fstab from the device and make it CWM-compatible (Only three columns: mount point, fstype, mount device) by removing all the Samsung-specific cruft - look at the SGSII recovery.fstab for an example of what it should look like
Put in the partition sizes and such in BoardConfig.mk
Need to do the source edits to CWM I mention a few posts above - both are oneliners. I'll try to post a patch when I have the time
Once you build by "make recoveryzip" you need to manually go and copy the recovery binary and all its symlinks into the initramfs - it's in out/target/product/samsung/yourdevicenamehere/ somewhere
dammit...
Something is not working right. Nandroid restores aren't restoring properly... The restores always seem to get corrupted.
****ing RFS... I hate it.
Somehow restored directories are FUBAR:
Code:
ls: ./tts: No such file or directory
ls: ./bin: No such file or directory
ls: ./app: No such file or directory
ls: ./xbin: No such file or directory
ls: ./vendor: No such file or directory
ls: ./firmware: No such file or directory
ls: ./usr: No such file or directory
ls: ./fonts: No such file or directory
ls: ./lib: No such file or directory
ls: ./media: No such file or directory
ls: ./modules: No such file or directory
ls: ./vsc: No such file or directory
-rw-r--r-- 1 root root 2437 Sep 16 21:35 build.prop
drwxr-xr-x 1 root root 0 Jan 9 23:24 cameradata
-rw-r--r-- 1 root root 44 Sep 16 21:35 default.prop
drwxr-xr-x 1 root root 0 Jan 9 23:24 etc
drwxr-xr-x 1 root root 0 Jan 9 23:24 framework
Entropy512 said:
I'll try to when I have some time... next few days are going to be busy.
Very quick summary:
Need to fix mkvendor.sh so TMPDIR is set when you don't provide a bootimage argument, otherwise the device tree doesn't get created properly
Need to pull recovery.fstab from the device and make it CWM-compatible (Only three columns: mount point, fstype, mount device) by removing all the Samsung-specific cruft - look at the SGSII recovery.fstab for an example of what it should look like
Put in the partition sizes and such in BoardConfig.mk
Need to do the source edits to CWM I mention a few posts above - both are oneliners. I'll try to post a patch when I have the time
Once you build by "make recoveryzip" you need to manually go and copy the recovery binary and all its symlinks into the initramfs - it's in out/target/product/samsung/yourdevicenamehere/ somewhere
Click to expand...
Click to collapse
Can you post the patch with the modifications in the source? Thanks!
Attached patch and my current recovery.fstab - remove the .txt extensions
Still not exactly working... RFS formatting seems busted.
Figured out the formatting problems - a few services running from /system were preventing it from unmounting properly.
I did a successful Nandroid restore - things are close now. I may just need to tweak recovery.fstab a bit more to have RFS format/restore/backup fully working.
Voodoo Lagfix - whole other story...
Entropy512 said:
Figured out the formatting problems - a few services running from /system were preventing it from unmounting properly.
I did a successful Nandroid restore - things are close now. I may just need to tweak recovery.fstab a bit more to have RFS format/restore/backup fully working.
Voodoo Lagfix - whole other story...
Click to expand...
Click to collapse
It's a step closer and a BIG advance if we got CWM working on our devices. Really thank you.

Flash image gui?

Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.

[Q] Recovery script for removing system apps

I've been running CM nightlies as long as they've been available for my device (Samsung Captivate). After each flash though, I have to go in through Titanium Backup and uninstall a number of system apps (mail, exchange services, music, DSP manager, news & weather, dev tools) that I do not use for various reasons. I know the ROM runs fine without these elements, as I've been removing them for years now. Manually removing them wasn't such an issue until my phone received a TWRP recovery, which effectively gets me much closer to a "one-click" nightly update making the manual cleanup more of a burden to my lazy lifestyle.
My question is, I'd like to create a CWM flashable zip that contains only an update script that removes the system apk's that I specify. Using TWRP I'd like to be able to flash the update, the kernel, and my custom "cleanup" zip in that order. I know the path to all the subject apks, but I know little about scripting or creating CWM zips. Can anyone point me in the right direction to do so? I know my way around a bash script, but I'm not even sure if that's relevant.
Why not open the zip on you pc with, for example Winrar, and remove the apk files from system\app ?
Much easier!
airtower said:
I've been running CM nightlies as long as they've been available for my device (Samsung Captivate). After each flash though, I have to go in through Titanium Backup and uninstall a number of system apps (mail, exchange services, music, DSP manager, news & weather, dev tools) that I do not use for various reasons. I know the ROM runs fine without these elements, as I've been removing them for years now. Manually removing them wasn't such an issue until my phone received a TWRP recovery, which effectively gets me much closer to a "one-click" nightly update making the manual cleanup more of a burden to my lazy lifestyle.
My question is, I'd like to create a CWM flashable zip that contains only an update script that removes the system apk's that I specify. Using TWRP I'd like to be able to flash the update, the kernel, and my custom "cleanup" zip in that order. I know the path to all the subject apks, but I know little about scripting or creating CWM zips. Can anyone point me in the right direction to do so? I know my way around a bash script, but I'm not even sure if that's relevant.
Click to expand...
Click to collapse
Good source is here: http://forum.xda-developers.com/showthread.php?p=17684719
To remove files you'll want:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p22", "/system");
delete("/system/app/blah.apk");
unmount("/system");
Your mount command will probably be different, so check the CM update-script for the equivalent one
RoadXY said:
Why not open the zip on you pc with, for example Winrar, and remove the apk files from system\app ?
Much easier!
Click to expand...
Click to collapse
I rarely use my own PC in the flashing process. Grandfathered in on an unlimited data plan, and I usually flash at work and connecting my phone to my work PC is verboten. Plus it takes about as much time to just uninstall them from TiBu.
Atarii said:
Good source is here: http://forum.xda-developers.com/showthread.php?p=17684719
To remove files you'll want:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p22", "/system");
delete("/system/app/blah.apk");
unmount("/system");
Your mount command will probably be different, so check the CM update-script for the equivalent one
Click to expand...
Click to collapse
That's exactly what I need! Thanks a ton!!
Posted in that other thread linked here but going to ask here as well:
Quick question, for a delete command can you use a wildcard?
Like this:
delete("/system/app/SamsungHub.*");
I only ask because some roms have .apk and some are .odex (for example). Looking to make one script work for any stock rom on my phone.
Also, according to my TWRP log I'm able to mount /system but /data threw an error:
mount: failed to mount /dev/block/mmcblk0p29 at /data: Device or resource busy
Looks right in the partition area:
Symlink_Path: /data/media/0
Symlink_Mount_Point: /sdcard
Primary_Block_Device: /dev/block/mmcblk0p29
Any thoughts why?
script file
airtower said:
I rarely use my own PC in the flashing process. Grandfathered in on an unlimited data plan, and I usually flash at work and connecting my phone to my work PC is verboten. Plus it takes about as much time to just uninstall them from TiBu.
That's exactly what I need! Thanks a ton!!
Click to expand...
Click to collapse
Hello, I'm also looking for same. can you share your remove/delete apk script file. I'll make the necessary changes myself.
Thankyou
jd2050 said:
Hello, I'm also looking for same. can you share your remove/delete apk script file. I'll make the necessary changes myself.
Thankyou
Click to expand...
Click to collapse
I'm not using one anymore. This thread is nearly 5 years old.

[Titanium Backup] Failed to protect backup

Tried every method...but I'm unable you protect my backups in titanium backup
To protect*
How I solved this problem on my Moto G LTE
Shantanu Baviskar said:
Tried every method...but I'm unable you protect my backups in titanium backup
Click to expand...
Click to collapse
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
_jis_ said:
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
Click to expand...
Click to collapse
Although in the case of Note 4 it didn't work right off the bat, I made it work a little different thanks to your idea. For some weird reason the script just doesn't get executed at boot (neither the *.sh file, nor as a script, through ROM Toolbox) but I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
As a mention for those interested in replicating all these: the suggested SD card fix made by rummy applies EXACTLY the same changes as the SDFix so you can use either of them. Again, thanks for your reply and the great idea! :good:
nacos said:
I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
Click to expand...
Click to collapse
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
_jis_ said:
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
Click to expand...
Click to collapse
This update addresses the issue mentioned before about init'd scripts not executing at boot. OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr. I've tested it and it's working, however it doesn't work directly with <X.sh> text files, instead the script must be packaged in a flashable zip and flashed from recovery. Once I did that, it worked like a charm! The 98mediarw file in the screenshot uses the same script as previously mentioned; The 98 before the file name assigns a higher execution priority - I used 98 for testing purposes, it clearly doesn't need that. :good:
nacos said:
OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr.
Click to expand...
Click to collapse
Oh, at first I thought that you post something what helps me with my tablet:
_jis_ said:
I solved this problem on all my phones but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk.
Click to expand...
Click to collapse
But this is just another example how to execute script at boot
none of these methods are working. Is it because I'm using a Custom ROM?
What are you trying to achieve? What exactly is your environment?
nacos said:
What are you trying to achieve? What exactly is your environment?
Click to expand...
Click to collapse
I have Motorola Moto E (CM11 Stable build by percy_g2) and I'm trying to protect my backups in TiB but I'm getting error "Sorry, the operation failed." It used to be the same in stock ROM. And one more question, is this bug fixed in Lollipop versions of Android?
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
nacos said:
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
Click to expand...
Click to collapse
(Please ignore that screenshot. I didn't properly read your msg in blue text)
I couldn't understand post #4 so can you please describe it more deeply? :crying: btw I don't have 00test but a file named 00banner. And can you tell me how to use tasker properly?
Sorry for butting in on this thread. I found it by searching because I too can no longer protect a backup in my tibu Pro. I used to be able to but not anymore and I'm not sure why.
I'm on a rooted nexus 5 running stock 4.4.4.
Reading your instructions I went looking for platform.xml and found it. When I checked its properties I got, see screenshot. Don't know what to modify to mount it as you say. I'm in ES Explorer.
Can you help?
Thanks.
And here is a screenshot in root Explorer
Update your tb to 7.0.1 and now you can protect backups ? this thread should get closed now
Closed? Why? Just because a shortcut is available doesn't mean there is nothing to learn from wondering around, my friend!
After all, this is exactly what XDA is: a huge data base available to those who are willing to learn and dare to wonder around, wouldn't you agree?

Categories

Resources