Database Users

Rooted Hero Fails adb remount, can't move files from SD

I rooted my hero last night and tried out a few different ROMs but eventually decided to revert to stock and make some manual changes. I used nandroid to restore to just after the root (1.56.651.2). I was able to remove some apps using adb, but the adb remount command fails (permission denied), and I'm unable to push a new bootscreen on to the phone. I also tried a Root File Manager and pre-kitchen as alternatives for the bootscreen, and neither one works. The Root Manager won't paste the files from SD into /system/media/ and pre-kitchen just reboots the phone.
Any suggestions?

Any chance this has something to do with downloading only up to SDK Platform 1.5? I'm at a total loss. I RUU'd my phone, did a clean root at startup using adb shell, and I still have the same problem. The adb remount command won't work, and I can't push anything into the system directory. For what it's worth, when I still had Root Manager installed I was able to toggle RO R/W in any directory with no problem, and I could move files around within the ROM... but I couldn't move anything into it from the SD. I'm new at this, so I have no idea what the problem might be. Anyone else had this problem or have any suggestions?

If anyone else runs into this problem, this solution worked for me:
adb shell
# su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system (Or any subdirectory you want to push to inside system)
# exit
adb push <local file> <device location>
Restore modified permissions when done.
Though I'm still not sure why this is necessary in place of adb remount.

I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

dametzg said:
I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Click to expand...
Click to collapse
Thanks... didn't realize stock wouldn't accept adb remount. If I use the above line from within shell, that doesn't help me push anything on to the phone though... so I needed to enable global permission and then do the push. Oddly enough I tried the same approach last night using Root Manager, and the transfer from SD still failed, even after I applied 777 to the dir I was trying to modify. The current solution may be kind of tedious, but at least it works.

you really shouldn't do 777 on your filesystem, ANY app can then write to your system, overwrite things, or install malicious code. Just remount manually and you should be able to push anything you want, just remember that w/ the stock rom you also don't get a full busybox either.

I'm not positive, but I would think after you remount, you should be able to "adb push" to /system. I suppose it might be specific to that shell, but I would think not.
You just may have to do it once each time you boot your phone.
Edit - err nevermind... you're having permission errors.... um... change adbd on the phone to run as root? not sure how off the top of my head...

[Solved] Is there an advantage with S-Off against mounting to rw and chmod 777?

Hi everybody!
Yesterday i came across S-OFF. From what i was able to find, S-OFF has two main advantages: 1.) Grant full NAND access, so you can write to /boot, /recovery and /system while in full booted mode. And secondly; allows unsigned fastboot flashing.
Now my question regards the first point; write access to all directories during full boot. Yesterday i was in need of write access to /system directory (actually just for creating a symlink). What i did - when got the "write-only permission" prompt at first try - i remounted system partition via terminal and then chmodded system directory:
Code:
/$ su
su
/# grep " /system " /proc/mounts | awk '{system("mount -o rw,remount -t "$3" "$1" "$2)}'
/# chmod -R 777 system
Afterwards i had write permissions to the system directory while i've been in full boot mode.
So my question is: If i'm not interested in unsigned fastboot flashing, nor in locking the bootloader etc, but only in having full access to all system directories - is my approach posted above giving me the same permissions, as S-OFF would do, or would S-OFF gimme any advantages?
My Phone:
*Nexus One on GRK39F Stock ROM,
*rooted (with "Superboot for Nexus One" by Madaco),
*su version 3 (by ChainsDD http://forum.xda-developers.com/showthread.php?t=682828)
Many thanks in advanced!
Cheers, Stephan
Update: @Mod/Admin: Sorry for posting to the wrong section. When i was looking at the section titles before posting this, i read Q&A as FAQ; donno why. I just realized the sticked thread at top of this section, thus recognized i posted to the wrong section. If you'd be so kind to move the thread to the approciated section, rather than closing it, i'd be thankful and promise to take more care about sticking to the board rules in the future. Thanks and kind regards!

I think you are mixing up a few things:
1) Nexus One's come with a partially unlockable bootloader. When you execute the "fastboot oem unlock" command, you are able to flash the /system, /boot, and /recovery partitions with unsigned images via the fastboot command. (So, essentially, you can give yourself root access once you are unlocked, and can write to the /system partition while booted normally.)
2) With S-OFF, you are able to flash ALL of the partitions of the N1 with unsigned images via fastboot, including radio, hboot, sp1custom and splash.
3) If you are rooted, you have write access to the system partition (the same as the above two).
So, to answer your question, having an unlocked bootloader, or S-OFF, or root: they all give you the same ability when it comes to the /system partition.
P.S. If you rooted with "Superboot for Nexus One" by Madaco, then you already unlocked your bootloader...

Hi Efrant!
Thanks for your answer, eventhough i'm even more confused now. ^^ You say
efrant said:
having an unlocked bootloader, or S-OFF, or root: they all give you the same ability when it comes to the /system partition.
Click to expand...
Click to collapse
But "Root" alone, on Android, does not necessarily gives you permissions to write to system directories. As long as a partition is mounted read only, you will - regardless you have userid 0 - get a "read-only file system" error prompt when trying to write to it. Or how comes
Code:
[U][B]whoami: unknown uid 10063 :[/B][/U]
issuing
[B]$ ls /data/app[/B]
returns
[B]opendir failed, Permission denied[/B]
issuing
[B]$ cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
returns
[B]cp -s -P /system/xbin/busybox /system/bin/busybox: Read-only file system[/B]
Code:
[U][B]whoami: unknown uid 0 :[/B][/U]
issuing
[B]$ su
# ls /data/app[/B]
returns directory listing
[B]namespace.apk
...[/B]
issuing
[B]$ su
# cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
returns
[B]cp -s -P /system/xbin/busybox /system/bin/busybox: Read-only file system[/B]
Code:
[U][B]whoami: unknown uid 0 :[/B][/U]
but issuing
[B]$ su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod -R 777
# cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
will finally create the symlink
For me, that doesn't look like i'm having same access to system directories whether for reading, nor for writing and that - even when logging in as userid 0 ?!
PS: And yes, you're right; i unlocked the bootloader (the very first day i bought my Nexus).

Bexton said:
Hi Efrant!
Thanks for your answer, eventhough i'm even more confused now.
But "Root" alone, on Android, does not necessarily gives you permissions to write to system directories. As long as a partition is mounted read only, you will - regardless you have userid 0 - get a "read-only file system" error prompt when trying to write to it.
Click to expand...
Click to collapse
Yes, but once you have root access, you can mount the system partition as r/w, without any other permissions/etc. All I was saying was that when you have root, you can write to the system. Of course I didn't spell it out step by step, i.e., by mounting the system as r/w, changing directory to the system, etc.
P.S. If you use a root file explorer (like Root Explorer for example, it make the process much easier).

Okay, i got it! Thanks!
So the bottom line: @secuflag has no effect on read and write permissions for the file system.
PS: Sometimes i'm using "root apps" (such as sysroot file explorer eg). But some things can not be done by apps. Plus, i think for a lot of tasks - if you're familar with linux - the command line is also much more comfortable and faster. But thanks for your tip (and help) anyway.

Bexton said:
So the bottom line: @secuflag has no effect on read and write permissions for the file system.
Click to expand...
Click to collapse
Correct (on Nexus 1s)
Sent from my Nexus One using Tapatalk

Here is a new safe way to get S_OFF for your N1. For me the only real advantage was getting rid of the ugly padlock image during boot, and customizing the initial splash image.
http://forum.xda-developers.com/showthread.php?t=1270589

garrettc67 said:
Here is a new safe way to get S_OFF for your N1. For me the only real advantage was getting rid of the ugly padlock image during boot, and customizing the initial splash image.
http://forum.xda-developers.com/showthread.php?t=1270589
Click to expand...
Click to collapse
Keep in mind that what you are linking to is not "true" S-OFF (i.e., setting secu_flag=0, like what you get when using an XTC clip or something similar). The radio is still S-ON.

efrant said:
Keep in mind that what you are linking to is not "true" S-OFF (i.e., setting secu_flag=0, like what you get when using an XTC clip or something similar). The radio is still S-ON.
Click to expand...
Click to collapse
Yes, very true. But for what I wanted it's OK. I'm very lucky that this method turned up on the same day that my new XTC Clip arrived, since it fried itself when I plugged-in the battery and I was about as depressed as a geek could be

[TIPS][SCRIPTS][ROOT]egingell's scripts. Updated 11/22/13 11:30 MST

I will be using this thread to post my scripts and link them to other threads as needed. For this thread, I am assuming you know what you're doing. You don't need mad hacking skills and you don't need to be an expert (I'm sure as hell not), but knowing your way around the file system and basic shell scripting are helpful.
Some background: I am using the stock ROM and kernel (SGS2 - GB27, SGS4 - MDC), so all of my tips revolve around using stock and all of my scripts (even the flashable ones) will work without flashing from recovery (just extract the script from the ZIP and execute it while the phone is in phone-mode - you know... powered on ).
You are welcome to use my scripts in your apps. I only ask that you give me some credit.
I am not responsible for bricking your phone. I have only tested my scripts on my personal Samsung Galaxy S2 and S4 from Sprint. You are welcome to try on your phone, but I offer no warranties or guarantees as to whether they will work or not. Back up your ****!
All of this requires root!
Below is a list of the scripts I have written for y'alls. Enjoy.
Custom df: Shows where irregular mounts ("mount -o bind") are mounted. [ Forum post | Download ]
Currently doesn't work on my SGS4.
Easily move Phonesky.apk and GoogleServicesFramework.apk to /system or /preload for Multi DPI Play Store. [ Forum post | Download ]
Untested on my SGS4, but there's no reason to think that it won't work.
Use your SGS2's internal SD card for Link2SD instead of making a second partition on your external SD card (although, depending on the setup, you may still need to make a tiny partition on your external SD card) and your external SD card as your internal SD card [ Forum post ]
Untested on my SGS4. I have no need for it.
Clean up Link2SD: Delete files associated with Link2SD when uninstalling it. It does not revert the links Link2SD makes. It only deletes the mount scripts. [ Forum post | Download ]
If you use the debuggerd script to enable init.d, running this script will cause you to lose init.d.
Untested on my SGS4, but there's no reason to think that it won't work.
Delete Samsung's bloatware from the Sprint SGS2. [ Forum post | Download ]
Untested on my SGS4, but there's no reason to think that it won't work; however, it was written specifically for the SGS2's bloatware. See thread S4 System Apps Safe To Remove for a list of SGS4 bloatware apps.
Google Home Launcher (from Kit Kat).
Works on Jelly Bean.
Below are some other tweaks.
You can use custom boot animations with the stock ROM. All you need to do is swipe a "/system/bin/bootanimation" binary file from another ROM (such as @rujelus22's Blu Kuban FL24 (ICS) or Blu Kuban GB27 (JB 4.1.2)), paste it into "/system/bin", and make it executable.
For JB 4.2.2, make sure the user and group are root and shell respectively. This doesn't seem to be a problem with JB 4.1.2 and below. It's also possible that my initial testing involved a boot animation that didn't work on my SGS4, so if it works with root as both user and group, then roll with it. :good:
Also for JB 4.2.2, use the file from a JB 4.2.2 ROM, such as The Blu Kuban S4.
You can enable init.d scripts very easily by renaming "/system/bin/debuggerd" to "/system/bin/debuggerd.bin", replace it with the following, and make both files executable. If "/system/bin/debugger.bin" already exists, then edit "/system/xbin/busybox run-parts /system/etc/init.d" into "/system/bin/debuggerd".
As with the above, make sure the user and group are root and shell.
Code:
[color=green]#!/system/bin/sh[/color]
LOG=/data/debuggerd.log
echo "$(date)" > $LOG
echo "init.d" >> $LOG
/system/xbin/busybox run-parts /system/etc/init.d 1>>$LOG 2>>$LOG
echo "$(date) finished" >> $LOG
echo debuggerd.bin launched >> $LOG
exec /system/bin/debuggerd.bin
Below are some tips.
Most of the things you can do with a custom kernel, you can do with the stock kernel, it just requires more work and more risk.
If you replace an odexed system app with a deodexed system app, make sure you delete the app's ODEX file (it's the same file name except with the extension .odex).
Conversely: if you replace a deodexed system app with an odexed system app, you better have the ODEX file to go with it.
You can clear the dalvik-cache without a custom kernel by deleting the contents of "/data/dalvik-cache". You can even delete an individual app's dalvik-cache by finding the file "/data/dalvik-cache/[email protected]@[email protected]" or "/data/dalvik-cache/[email protected]@[email protected]" and delete it.
You can manually uninstall a system app's update by finding the file "/data/app/.apk" and delete it.
You can manually delete all user data by deleting the contents of "/data/data". You can even delete an individual app's data by finding the folder "/data/data/" and delete it.
Making scripts and binaries executable:
They must be on an EXT formatted filesystem (e.g. /data, /system, /preload).
They must be at least readable and executable by the user 'shell' (755 (read/execute for all, write only for user - "u=rwx,a=rx" if your busybox supports that method) is what I usually use).
Code:
chown root:shell ""
chmod 755 ""
chmod u=rwx,a=rx "" # busybox must support symbolic modes
Changing file permissions requires read/write access to the filesystem on which the file resides:
Code:
mount -o remount,rw /system # make the /system partition read/write
mount -o remount,ro /system # make the /system partition read only
The stock kernel is considered "production" whether or not it's rooted; therefore, you cannot use ADB to push or pull files directly to or from protected partitions, nor run ADB as root, nor use ADB's remount command, so you have to use unprotected partitions as a sort of buffer. You can, however, access the ADB shell and issue the "su" command wherein you can use "cp" to copy files to or from protected partitions prior to using ADB to push or pull the desired file. However, there is an app aptly named [root] adbd Insecure by @Chainfire that patches the ADB daemon to get around this limitation.
Example:
Code:
c:/android-sdk> adb shell
[email protected]:/ $ su
[email protected]:/ # cp /system/bin/debuggerd /sdcard/debuggerd
[COLOR="green"]-- open a new command prompt window --[/COLOR]
c:\android-sdk> adb pull /sdcard/debuggerd debuggerd
c:\android-sdk> adb push debuggerd /sdcard/debuggerd
[COLOR="green"]-- switch to the first command prompt window --[/color]
[email protected]:/ # mount -o remount,rw /system
[email protected]:/ # cp /sdcard/debuggerd /system/bin/debuggerd
[email protected]:/ # chown root:shell /system/bin/debuggerd
[email protected]:/ # chmod 755 /system/bin/debuggerd
[email protected]:/ # mount -o remount,ro /system
Some noteworthy files and folders:
/proc/self/mountinfo: If you can read it, it tells you where your partitions and folder binds are mounted.
/proc/partitions: Shows all of your SD card's partitions, how many blocks each has, and their vold numbers (eg "179 1 30578964 mmcnlk0p1").
/dev/block/platform/dw_mmc/by-name: This folder contains symlinks to your internal eMMC's partitions indexed by what they are for (eg UMS for your internal SD card - "realpath /dev/block/platform/dw_mmc/by-name/UMS" will print out the device path (ie "/dev/block/mmcblk0p11")).
/dev/block/platform/dw_mmc/by-num: This folder is like the previous except that they are indexed by partition number (eg "p11").
/proc/version: Shows what version of Linux is currently being used.
/data/system/batterystats.bin: Delete this when your battery is fully charged and still plugged in to recalibrate it.
Footnotes:
For "/data/app", "/data/data", and "/data/dalvik-cache" files you need to know the package name. There are various apps that will tell you, including Link2SD (mentioned above), Titanium Backup, and the web URL of the app in the Play Store (ex: https://play.google.com/store/apps/details?id=com.devname.appname).
More:
Random boot sound using your notification sounds
Make ADB work for all users - Jelly Bean 4.2.2 (Updated 07/15/13 00:35 MST)
Stock ROM - SGS4 - init.d
No-data restore tips
SGS4 Bloatware Remover
Make apps run faster and increase battery life

Random boot sound using your notification sounds
The attached ZIP contains a script that can be run pre or post boot. It just needs to be executable.
Preboot requires init.d. See the OP for enabling it if you are on a stock rooted ROM and requires the file to be readable and executable ("chmod 755" works fine).
Postboot requires an app such as Scripter (ROM Toolbox) or Script Manager to execute the script at boot.
Requires the variable $RANDOM. You can make sure it's available from the command line ("echo $RANDOM").
Use this script at your own risk. I provide no warranties or guarantees.
What does this script do?
Check for carrier boot up sounds (sub folders in the "/system/media/audio/ui" folder) and moves them to "/system/media/audio/notifications" renaming them as needed.
Create symlinks in the above folders to "/system/media/audio/ui/PowerOn.ogg".
Check if "/system/media/audio/notifications/PowerOn.ogg" is present and copy it to "/system/media/audio/ui/PowerOn.ogg" it's not.
Count the number of files in "/system/media/audio/notifications".
Grab a random number between 1 and the number of files found inclusive (math notation: "[1, numFiles]").
Go through "/system/media/audio/notifications" and copy the file at index random to "/system/media/audio/ui/PowerOn.ogg".
Notes:
The stock file is included. If you want a different sound in its place, you can either comment out that line in the script and delete the "/system/media/audio/notifications/<subfolder>_PowerOn.ogg" files from "/system/media/audio/notifications" or just replace "/system/media/audio/notifications/PowerOn.ogg" with some other sound file and still delete the "/system/media/audio/notifications/<subfolder>_PowerOn.ogg" files from "/system/media/audio/notifications".
If you want more sounds, just copy them to "/system/media/audio/notifications" (OGG files only).
The script does not check for valid files and blindly renames the destination file to "PowerOn.ogg".
It does not look in "/sdcard/media/audio/notifications" or anywhere else for audio files.
I do not recommend using alarms or ringtones files as they are usually looped which can cause the media scanner to get stuck and overheat your phone or tablet - those files may continue to play even if you can't hear them.
If you can't hear a sound on boot, it is likely that the file is either invalid or has no audio (ex: my /system/media/audio/ui/BST/PowerOn.ogg has no audio).
It was tested and works on a Samsung Galaxy S2 (stock JB 4.1.2) and a Samsung Galaxy S4 (stock JB 4.2.2) both from Sprint and using stock kernels.
There's no obvious reason it won't work on other phones and tablets with other ROMs from other carriers.

Nice work E.

cerj said:
Nice work E.
Click to expand...
Click to collapse
:good:

Make ADB work for all users - Jelly Bean 4.2.2 (Updated 07/15/13 00:35 MST)
With Android 4.2.2, ADB now requires RSA keys. This poses a problem when attempting to connect to the device's ADB server from the device itself and the device won't ask for authorization unless it's connected via USB. Well, there's hope, yet.
For the following, I'm assuming you used my method for adding init.d support to your device.
Use these scripts at your own risk. I provide no warranties or guarantees.
Add the following script to /system/bin/debuggerd. If you use an alternate method, please note that it must be executed by the debugger daemon. You must do this first or you'll have to manually restart the debugger daemon after editing this file and executing the run-once script (next step), so edit this file first and save it.
Code:
if [ ! -e "/.android" ]; then
busybox mount -o rw,remount /
mkdir /.android
mount -o bind /data/.android /.android
busybox mount -o ro,remount /
fi
Then run this script once from the device (not over ADB on your PC).
Code:
[COLOR="Green"]#!/system/bin/sh[/COLOR]
HOME=/data
adb kill-server
adb start-server
stop adbd
cat /data/.android/adbkey.pub >> /data/misc/adb/adb_keys
echo "" >> /data/misc/adb/adb_keys # Add a blank line at the end of the file
start adbd
HOME=/
adb kill-server
stop debuggerd
start debuggerd
Notes:
You can also find the abdkey.pub file on your Windows' PC here, C:\Users\<user name>\.android\adbkey.pub. Copy it to your device by whatever means necessary, then append it to /data/misc/adb/adb_keys and you won't need to initially use the USB to allow the PC connection. Not really necessary unless your PC has no USB or you've broken your USB cable.
This may have inadvertently corrected the mounting issue introduced in Jelly Bean 4.2.2.
You can also allow other Android 4.2.2 devices, but it requires ADB version 1.0.31 and for you to manually append the contents of /data/.android/adbkey.pub from device A (the one you want to use to ADB on) to /data/misc/adb/adb_keys on device B (the target device).
Don't delete /data/.android
This won't fix apps. Just allow you to use ADB to connect to your device from itself.
Tested on my SGS4. No reason it won't work on other devices.
If you already have a /data/.android directory, you may not need to do this. On my SGS4, HOME defaults to "/" which the ADB daemon can't write to, so it can't make the RSA key.
The run-once script temporarily changes HOME to "/data", a writable directory, so the ADB daemon can write the RSA key then it append it to the allowed clients file then restarts the debugger daemon thus binding /data/.android to the /.android directory allowing all Linux users ADB access to the device.
Reassigning HOME to a new value on one user only changes its value for that user which is why I'm binding /data/.android to /.android.
Code:
# Example
[email protected]:/ $ echo $HOME
/
[email protected]:/ $ HOME=/data
[email protected]:/ $ echo $HOME
/data
[email protected]:/ $ su 1000
[email protected]:/ $ echo $HOME
/
Alternatively (much easier):
Make the .android folder in /data (mkdir /data/.android).
Add the script, the first code block in this post, to your debuggerd file or an init.d script.
Restart the debugger (stop debuggerd; start debuggerd) or reboot the phone.
Restart ADB (stop adbd; start adbd).
Copy the newly created public key to the allowed clients (cat /data/.android/adbkey.pub >> /data/misc/adb/adb_keys; echo "" >> /data/misc/adb/adb_keys).
Restart the ADB server (adb kill-server; adb start-server).

SGS4 Bloatware Remover
I have written a live-script to delete all of the SGS4 bloatware except GoogleContactsSycAdapter and SecLauncher3. If you want to delete those, remove the "#" from that line in the script. If you want to exclude an app, add a "#" to that line and put the app name in quotes (ie AppName / becomes "#AppName" / (including the forward slash) or just remove that line. If you remove the last item (YouTube in this case), remove the forward slash from the previous line.
Use this scripts at your own risk. I provide no warranties or guarantees.
What this script does:
Move the app's APK and ODEX to /sdcard/SystemAppsBackup.
Delete its dalvik-cache.
Reboot the phone. If it doesn't reboot, you'll have to do this yourself.
What this script does not do:
Delete the app's data. Because the script doesn't know the package name.
Delete its Play Store update (located in /data/app). Because the script doesn't know the package name.
Mount the SD card if it's not mounted. If you want backups, make sure the SD card is mounted.
Care if you delete a system app you wanted to keep. Most apps that you would want to keep may be available in the Play Store.
Restore apps.
Notes:
Apps will crash left and right when you execute this script in running mode. Don't fret, this is normal.
This is a live-script which means you have to manually execute the script either with a terminal emulator, a script executor like Scripter, or ADB.
This is not flashable.
If executing via ADB in Recovery mode, you may need to mount the SD card to /storage/sdcard0 manually or settle for no backups.
If you restore an app from /sdcard/SystemAppsBackup, make sure you get the ODEX file if present and set the permissions for both to 644.
This list is based off the list in the thread, S4 System Apps Safe To Remove.

Here You Go Guys, I took me about 30 mins, but I have successfully added all the app in the Op to a flashable Zip.
The Zip is base of TrulyClean v1.6 script code, I just deleted his ;delete/system/...apk and replaced it with all the ones from the OP

bigtobitobs said:
Here You Go Guys, I took me about 30 mins, but I have successfully added all the app in the Op to a flashable Zip.
The Zip is base of TrulyClean v1.6 script code, I just deleted his ;delete/system/...apk and replaced it with all the ones from the OP
Click to expand...
Click to collapse
Looks like you're deleting bloatware, perhaps you should post that in the right thread... or at least a more appropriate thread.
Sent from my SGS4.

egingell said:
Looks like you're deleting bloatware, perhaps you should post that in the right thread... or at least a more appropriate thread.
Sent from my SGS4.
Click to expand...
Click to collapse
LOL OMG I am so sorry, I had multiple tabs open and put this in the wrong forum. Please Delete

bigtobitobs said:
LOL OMG I am so sorry, I had multiple tabs open and put this in the wrong forum. Please Delete
Click to expand...
Click to collapse
Would that I could.
Sent from my SGS4.

Make apps run faster and increase battery life using Xposed App Settings.

Did you install GravityBox on your SGS4 then uninstall it and now you can't hear your games or music?
I think it has to do with GravityBox's "Volume Steps" option not undoing when GB is uninstalled. This is how I fixed it (forum post).

Stock ROM - SGS4 - init.d
I recently found out that my debuggerd hack to enable init.d support on my stock SGS4 wasn't working. So, I did this and now it works.
Make a file named "install-recovery.sh" and drop it into /system/etc. Whatever script you put in here will execute at boot up so long as the user/permissions are correct.
Code:
chown shell:shell "/system/etc/install-recovery.sh"
chmod 755 "/system/etc/install-recovery.sh"
chmod u=rwx,a=rx "/system/etc/install-recovery.sh" # busybox must support symbolic modes
Use this script at your own risk. I provide no warranties or guarantees.
My "/system/etc/install-recovery.sh" script:
Code:
[COLOR="Green"]#!/system/bin/sh[/COLOR]
LOG="/data/install-recovery.log";
echo "Executing install-recovery.sh" > $LOG;
echo "" >> $LOG;
echo "$(date) install-recovery hack..." > $LOG
echo "" >> $LOG
echo "init.d" >> $LOG
[COLOR="green"]# I can't get run-parts to work for some reason, but this will run every *.sh script in /system/etc/init.d as root.[/COLOR]
for N in /system/etc/init.d/*.sh; do
su -c "$N" 1>>$LOG 2>>$LOG
done;
Notes:
Mount binding (in JB 4.2.2+) seems to work. E.g. mount -o bind /folder1 /folder2
$(date) does not provide the correct date (mine said: "Wed Apr 15 13:24:13 MST 1970").
The Package Manager is not available. (There may be other unavailabilities, but I don't intend to test it thoroughly.)

Somethings I discovered recently while doing a no-data system restore for the second time in the same night and some tips relating to system restores:
* When doing a no-data restore, disabled/frozen system apps remain disabled.
* Apps that can't be disabled even with Titanium Backup will not remain disabled after a reboot and will sometimes crash/FC repeatedly until uninstalled.
* If an app won't open or FCs, try converting it to a system app and back to user app or vice versa.
* Don't integrate system app updates into the ROM. In the event that you have to do a no-data restore, those updates will be retained.
* Don't convert user apps to system apps for the same reason.
* Disregard the previous two tips if disk space is a problem. It's just more time consuming (redownloading updates, reintegrating, and reinstalling) after a restore.
* Save all modified system files, such as /system/bin/debuggerd, /system/build.prop, /system/etc/install-recovery.sh, and if your ROM uses /system/etc/unit.d, any modified or extra files there. If you use them, you'll need them after a restore.
* For a smoother post no-data restore, use Titanium Backup's labels so you can batch-uninstall those pesky system apps you don't want.
SGS2 - JB 4.1.2 GB27
SGS4 - JB 4.2.2 MF9

any command for updater script to make directory in root of android ??

HassanMirza01 said:
any command for updater script to make directory in root of android ??
Click to expand...
Click to collapse
Creating directories in / and all the files contained therein must be redone on every boot. That said, you just need to make root writable and make the directory.
mount -o remount,rw /
mkdir /whatever
mount -o remount,ro /
Note: Every time you wish to create, modify, or delete files you'll have to make root writable.
Sent from my LG-H811 using Tapatalk

egingell said:
Creating directories in / and all the files contained therein must be redone on every boot. That said, you just need to make root writable and make the directory.
mount -o remount,rw /
mkdir /whatever
mount -o remount,ro /
Note: Every time you wish to create, modify, or delete files you'll have to make root writable.
Sent from my LG-H811 using Tapatalk
Click to expand...
Click to collapse
Actually.... I wanna add some files within folder in root of android root... So i need to use above three commands nd then after making directory, i should extract files to that folder ??

HassanMirza01 said:
Actually.... I wanna add some files within folder in root of android root... So i need to use above three commands nd then after making directory, i should extract files to that folder ??
Click to expand...
Click to collapse
Yes.
Sent from my LG-H811 using Tapatalk

:good:

[Q] How do I delete system apks?

I can't figure out how to delete some of the system apks off my rooted Nook Simpletouch. Running 1.2.1, and Nootered it. Tried to ADB uninistall Phone.apk, but it just reports failure. I could use some help.

/system is usually read-only.
To make changes in its content you need to remount it read/write:
Code:
stop
mount -o rw,remount /dev/block/mmcblk0p5 /system
The stop is to be on the safe side, it stops the android subsystem.
After you are done making changes it's best to:
Code:
reboot

Renate NST said:
/system is usually read-only.
To make changes in its content you need to remount it read/write:
Code:
stop
mount -o rw,remount /dev/block/mmcblk0p5 /system
The stop is to be on the safe side, it stops the android subsystem.
After you are done making changes it's best to:
Code:
reboot
Click to expand...
Click to collapse
Just rename them. add ",bak:" to the end or similar. This will disable them, and if you notice instabilities because of getting rid of them you can just remove the appended extension. If everything runs well, you can then delete them with no worries.
I've renamed some of the recommended ones and have an error that comes up. "A problem has occurred, contact support". I need to figure out what is causing that to happen. its annoying but doesn't seem to be an actual problem.

What does "mmcblk0p5" represent?

mmcblk = multimedia card block device, 0 = first device, p5 = fifth partition

Thanks Renate, but It's not working. In order to rename or delete an apk off my Nook simpletouch, would someone please give me step instructions? I feel I'm missing something.

Code:
stop
mount -o rw,remount /dev/block/mmcblk0p5 /system
cd /system/app
mv BoringApp.apk BoringApp.bak
mv TediousApp.apk TediousApp.bak
reboot
And don't tell me that you have no boring or tedious apps!

The advice here is correct, better to rename sysapp extensions (.bak or .ap_) than delete as some might be needed by future apps/sys hacks/kernels. For those who can't adb by cable or keep it up wifi-wise, this is the easiest way even easier than root explorer:
https://play.google.com/store/apps/details?id=com.ghisler.android.TotalCommander
for sys or user app removal if you have to and can't use adb or even total commander, but then you shouldn't if not knowing sys file structures (I use Pro version, for removing many apps i just tested in a batch, sorted reminder):
https://play.google.com/store/apps/details?id=com.jumobile.manager.systemapp
I renamed talk telephone music audio etc apks on nst but Gallery is the only one I removed on all android devices & nst as it's just nasty which has never been missed by later hacks and quickpic is much better anyway:
https://play.google.com/store/apps/details?id=com.alensw.PicFolder

I created another directory under /system called archive. I move apps I don't what to use and fonts I change into /system/archive then I can just move them back if I have issues.

This still isn't working. My commands keep getting rejected. It isnt allowing stop to work. Also, I tried "adb cd /system/apps" and when that didn't work, I tried
"adb shell"
"#cd /system/apps"
No dice.
EDIT: Got it. needed to call it shell instead of adb. I also accidentally wrote "apps" instead of "app".

Need help: ad-blocking via hosts file android 7 nougat

Hello dear community,
I'm now struggling for some days to enable ad-blocking on my Huawei Nova with Android 7 Nougat (CAN-L01C432B340). I simply only need root to edit the hosts file and then un-root my device (that can be easily done by flashing boot.img via fastboot again). Reason for un-root is to be able to play Pokemon Go which has a root-block.
Following steps have been tried with root enabled
First things first: The normal way of using AdAway to create a hosts file does not work anymore: It seems to be impossible to remount the /system partition with r/w (read more) with the app.
So I tried many things so far to gain r/w while Android is booted up
Reversed the order on how we give the options to mount as suggested in chainfires posts: mount -o rw,remount /system fails (same does mount -o remount,rw /system)
Installing busybox to have another (probably working) mount command: Installation fails because of no rw on /system (doh)
Flashing busybox installable zip: The binaries seem to be gone when Android is booted up (but are visible in TWRP)
Using another busybox installer seem to be able to at least temporary flash busybox to /system/bin. Yet, busybox mount -o rw,remount /system did not make /system rw.
Flashing systemless AdAway also fails (similar to flashing busybox, the files are written but mystically, all changes are gone after booting into android).
Now I unrooted my device
Then I thought, why not use TWRP and mount the partition with rw there and copy my own custom-made hosts-file to /system. And hey, mounting with rw works! Also even writing and all kind of stuff.
But now the bummer: No matter what I do, the hosts file, formerly written to e.g. the /system partition is reverted back to default after a reboot to android. The strange thing: My modification is still there and visible in TWRP
Investigating on how the hosts file is managed in a booted-up android, I found out, /system/etc/hosts is symlinked to /vendor/etc/hosts.
So I mounted the /vendor partition in TWRP and copied the hosts file there.
mount /dev/block/platform/soc/7824900.sdhci/by-name/vendor /system && cp /external_sd/hosts /system/etc
After a reboot, I noticed /vendor/etc/hosts (= /system/etc/hosts) just has the default entries :crying: Strangely, when I now root my device again, the hosts-file shows my entries (but I need to be un-rooted )
It seems like that all changes done to any partition are somehow reverted back by the kernels drive-mapper. Does anyone have an idea on how to write a hosts-file to my system, which persists when I boot up android and does not require to be permanently rooted?