I have been reading about "Fixing permissions" and I can see that ROM Manager on my Nook (running Phiremod v5.2 with CM7) has that function.
But what exactly does "Fixing permissions" mean?
When do I need to do that?
And what are the consequences?
Hope anyone can explain it to me - or guide me to a "ROM Manager/Fixing Permissions for Dummies"
http://en.wikipedia.org/wiki/Filesystem_permissions
Fixing Permissions does exactly what it says really. It fixes the file system access permission to the correct settings if for some reason they aren't set right which seems to happen from time to time. As far as I know there are no issues or consequences to running the script outside of wasting a few minutes while it runs since it's basically restoring things back to how they should of been.
Thanks for the reference and the answer.
Regarding the Nook, what interests me is why this is necessary from time to time. But maybe I shouldn't think about it too much
Caspar...as you add new apps or change ROMS, the filesystem permissions often get changed. sometimes they get changed to values that are detrimental(like a file getting set to read only when it needs to be writable). That's why the need for fixing the permissions.
If you don't do this, you sometimes end up with a scenario where an app expects to be able to write some information and can't. This generates an error, which if the app isn't able to handle it, crashes the app.
A well written app will have thought of this already, but most times developers just expect the proper permissions and don't add in error handling code, saving themselves work and the program some size.
Related
I found that whenever I flash an updated ROM or apply some themes that quite a few of my apps stopped working and had to be re-installed, especially private apps. The fix has always been re-install. This drove me nuts as some of the apps required a reboot (i.e. mobiledefense) I took a look at my logcat and saw an error (sorry, don't have exact as I figured it out after closing the logcat) regarding a mismatch between odex and dalvik cache. I went through and deleted my app-private/*.odex files. They ALL started working without a reinstall. I have since gone through and removed all of my .odex files and have created a script to do so in assuming this could happen again.
I had a hard time figuring it out because it wasn't all apps, just some. What I discovered was the userinit.sh and user.conf here as a default set this:
odex_auto=1 # perform auto create or del odex for applications installed or removed within 3 days
So it would create .odex files within the parameters outlined. I've since turned it off.
I know .odex has something to do with optimization, and I noticed they are not re-created at any noticeable time. My question is, are there any detrimental effects from deleting them? Will it decrease performance or have any other ill effects on the applications?
If it actually helps performance, I can delete and rebuild them after I do a flash that has this issue. I just don't know if it is worth the effort.
Thanks for any input that may be coming!
Usually there isn't a problem deleting odex files since the system recreates them anyway, but on a similar note, instead of doing that, since you run latest Cyan recovery..go into console mode and type "FIX_PERMISSIONS", it should fix the force closes issues you may be having. This basically fixes the mismatch issues you may be having.
prash said:
Usually there isn't a problem deleting odex files since the system recreates them anyway, but on a similar note, instead of doing that, since you run latest Cyan recovery..go into console mode and type "FIX_PERMISSIONS", it should fix the force closes issues you may be having. This basically fixes the mismatch issues you may be having.
Click to expand...
Click to collapse
Thanks Prash. I've tried fix_permissions from the recovery console and even the new and improved one here previously, which I think is now integrated into Cyanogen's build with no luck. That's when I decided to look a little deeper. I don't know if it was a timing issue with the userinit being set the way it was, but deleting them always worked.
Question from this then for curiosity's sake. When do they get recreated? I have rebooted, updated (maybe not re-installed) numerous times and still don't have any new ones since disabling it in the userinit script.
I also remembered and re-found this, where Cyanogen himself said "Don't .odex your apps, it's a waste of time.".
So, I guess I'll start blowing them away Thanks!
Forgive me if this is the wrong place or a stupid question, but I've been looking for days and not finding what I need.
I have ~95 Galaxy tabs, we're rooting them (but leaving them stock) and then executing a rather long script to install software, copy data, uninstall market, disable anything we don't want the employees to access. The last piece of this is I am trying to execute several commands on each boot of the device (some iptables rules need to be re-loaded, couple of other simple commands)
I can't seem to find the init scripts I need to change - ie /init.rc gets recreated every boot losing any changes made, there doesn't seem to be an init.d anywhere, I don't know what support the stock kernel has. I've read so many incorrect (for this ROM) ways to go about running something that I think my eyes crossed.
Any help would be appreciated. And if there's another way for my iptables rules to survive a power-down I can take that as an answer.
so does anyone know if this is *not* possible with the stock kernel? I'm basically out of ideas and have to either scrap the project entirely or get it implemented.
Or, alternately if I'm in the wrong area let me know...
Hello!
I'm on a rooted Cricket Android 4.4.2 device.
ROM Version: 1.11.506.1
Software Number: 1.11.506.1
HTC Sense 6
Baseband: 1.101.1372.19
Can somebody please tell me how to get rid of the annoying software update that has been coming the last week?
Is there way to somehow either change my software number to trick the phone into thinking I'm updated or perhaps I should update? If so, how?
I appreciate the help.
Using a root file explorer and freezing the updater app manually would probably be the safest (personally I like Root Browser by JRummy hasn't been updated in awhile but if ain't broke it don't need to be, and it is a tool I know will always perform these critical tasks correctly)
By freezing the the system updater app in the following way, you will be able to easily reverse the process using the same process. While there are some mods that can hide the notification itself (eg.: Xposed FW), this method completely disables the update check process, thus freeing up system resources. Twofold if you look at it this way imo, rather than adding potentially harmful additional resources.
# Open your root fs explorer
# navigate to fs root:
/
# then to:
/system/priv-app
# locate the file:
Updater.apk
# append ".bak" to the file name. In other words rename it to:
Updater.apk.bak
# note: no need to mess with it's .odex file, it never hurt no one. Also depending on your fs explorer and personal settings, the app's icon thumbnail has likely changed to a blank white square/unkown/generic file icon and is totally normal.
# profit and celebrate the newly liberated space in your notifications and don't forget to miss that pesky "remind me later" pop up.
#should there be an update that your are feeling compelled to (try) and install simply remove ".bak" from the files name and proceed as usual. Note that the only thing you should be changing in all this is +/- ".bak" from the file name. Don't go trying to change this or other apps file name. It don't work like that. Speaking of other apps, I urge great caution against going ape$#¡+ and doing this carelessly, especially for apps anywhere under "/system".
# The Disable button on the App Info pages should be the primary resource for disabling apps for most users. Know what the app does and is used for on your system BEFORE making changes or worse yet, deleting it.
~/#: print <INSERT STANDARD DISCLAIMER, AKA CYA STATEMENT HERE>
Don't just say it, hit that thanks button if I helped you in any way!!!
Sent from my HTC Desire 510 using Tapatalk
wow thank you so much :laugh:
jackunoff said:
Using a root file explorer and freezing the updater app manually would probably be the safest (personally I like Root Browser by JRummy hasn't been updated in awhile but if ain't broke it don't need to be, and it is a tool I know will always perform these critical tasks correctly)
By freezing the the system updater app in the following way, you will be able to easily reverse the process using the same process. While there are some mods that can hide the notification itself (eg.: Xposed FW), this method completely disables the update check process, thus freeing up system resources. Twofold if you look at it this way imo, rather than adding potentially harmful additional resources.
# Open your root fs explorer
# navigate to fs root:
/
# then to:
/system/priv-app
# locate the file:
Updater.apk
# append ".bak" to the file name. In other words rename it to:
Updater.apk.bak
# note: no need to mess with it's .odex file, it never hurt no one. Also depending on your fs explorer and personal settings, the app's icon thumbnail has likely changed to a blank white square/unkown/generic file icon and is totally normal.
# profit and celebrate the newly liberated space in your notifications and don't forget to miss that pesky "remind me later" pop up.
#should there be an update that your are feeling compelled to (try) and install simply remove ".bak" from the files name and proceed as usual. Note that the only thing you should be changing in all this is +/- ".bak" from the file name. Don't go trying to change this or other apps file name. It don't work like that. Speaking of other apps, I urge great caution against going ape$#¡+ and doing this carelessly, especially for apps anywhere under "/system".
# The Disable button on the App Info pages should be the primary resource for disabling apps for most users. Know what the app does and is used for on your system BEFORE making changes or worse yet, deleting it.
~/#: print <INSERT STANDARD DISCLAIMER, AKA CYA STATEMENT HERE>
Don't just say it, hit that thanks button if I helped you in any way!!!
Sent from my HTC Desire 510 using Tapatalk
Click to expand...
Click to collapse
I'm gonna chime in here and I know you're trying to help but this really isn't helping because you didn't actually freeze the app like you said. All you did was change the apps name so now when the system actually calls upon that app it's simply going to error out and actually cause it to use more resources and not less as you said albeit it will not show up anymore but that's not the way to stop it! If I go into /system/priv-app and change Phonesky.apk to Phonesky.apk.bak the play store is going to break and then send me the error to my screen every second until I fix it and that uses more resources and the only reason you're not seeing the error on the screen for the Updater is because it's doing it behind the scene in a log. Now the real way to stop this app is to actually really freeze it or uninstall it so the system actually knows the app is no longer there and there are plenty of apps in the play store that can do that.
---------- Post added at 06:17 AM ---------- Previous post was at 06:16 AM ----------
Khiddfrost said:
wow thank you so much :laugh:
Click to expand...
Click to collapse
You should read my post above.
The first tweak/fix is for a GPS update/change.
Starting with Android 5.0, GPS has been flaky for a lot of people. The device picks up satellites, gets a lock, but then loses the lock. Sometimes it then gets a lock again and holds it, sometimes it just drops it again.
This was not fixed with 5.0.1, 6.0, or 6.0.1. It took Google over a year to even acknowledge it was an issue.
A user suggested a fix in the official bug report thread:
https://code.google.com/p/android/issues/detail?id=81140#c695
They suggest telling the device to not attempt a Mobile Station Based update of GPS information.
This can be done by changing the "CAPABILITIES" value in /system/etc/gps.conf.
I've made a file to automate this. It can be flashed from TWRP.
Nexus_5_GPS_Update_0.1.zip changes /system/etc/gps.conf to not use "MSB" updates.
Nexus_5_GPS_Restore_0.1.zip changes /system/etc/gps.conf back to the default of using "MSB" updates.
-----
The second tweak/fix is for CDMA users. I use my Nexus 5 on FreedomPop (a Sprint MVNO), and on almost every boot I'm greeted with this lovely message:
"Unfortunately, Update Device has stopped."
Its crash message mentions this:
java.lang.IllegalArgumentException: You cannot keep your settings in the secure settings.
From what I've read, moving an app from /system/app to /system/priv-app is supposed to fix this. The two problem files (OmaClient.apk and UpdateSetting.apk) are both located in /system/app, not /system/priv-app.
I figured, "why not move them to priv-app?"
So I've made a file to automate this. It can be flashed from TWRP.
Nexus_5_Sprint_Update_0.1.zip moves the apps from /system/app to /system/priv-app
Nexus_5_Sprint_Restore_0.1.zip moves the apps back from /system/priv-app to /system/app
-----
I tested these on CyanogenMod 13 (May 10th nightly build). There is no binary in the zip, each just contains a script to update the system, so you can easily view them in plain-text. Since both of the issues experienced seem to be impossible to purposely reproduce, I cannot say for sure if these fix the issue.
That's why I wanted to see if the files work or help others.
You can boot to TWRP and flash the zip files there. If you use something like CM Downloader, you can add them as additional zips to flash after any ROM update.
Let me know!
My GPS has been really useless these days. I guess I have to root my phone to try this out..
If I want to do it manually, what do I have to change it to?
ashirviskas said:
If I want to do it manually, what do I have to change it to?
Click to expand...
Click to collapse
Open /system/etc/gps.conf
Change this:
CAPABILITIES=0x33
To this:
CAPABILITIES=0x31
It's been around 8 years since I attempted to mod a phone. So far I've installed the latest Proton Rom, rooted with Magisk, installed Smali Patcher and installed the Proton Kernel. I'm not a programmer by any means and my experience outside of Windows is pretty limited; but, I've done what I feel like is a copious amount of research and I can't figure this out. I'm trying to move an .apk from /data/apps to /system/priv-app, but it keeps failing. I've tried installing Termux to execute ADB commands, but I'm way over my head there. I also installed root checker just to be sure I'm properly rooted. Trying to use root explorer or any other app returns the same error every time "Copy Failed". I know Android has changed a lot since Lollipop, including the file system from what I understand, but beyond that I'm generally a cut 'n paste modder.
I feel like this is probably something pretty simple or common knowledge, so hopefully y'all can help me here.
Appreciate it.
PariahNine said:
It's been around 8 years since I attempted to mod a phone. So far I've installed the latest Proton Rom, rooted with Magisk, installed Smali Patcher and installed the Proton Kernel. I'm not a programmer by any means and my experience outside of Windows is pretty limited; but, I've done what I feel like is a copious amount of research and I can't figure this out. I'm trying to move an .apk from /data/apps to /system/priv-app, but it keeps failing. I've tried installing Termux to execute ADB commands, but I'm way over my head there. I also installed root checker just to be sure I'm properly rooted. Trying to use root explorer or any other app returns the same error every time "Copy Failed". I know Android has changed a lot since Lollipop, including the file system from what I understand, but beyond that I'm generally a cut 'n paste modder.
I feel like this is probably something pretty simple or common knowledge, so hopefully y'all can help me here.
Appreciate it.
Click to expand...
Click to collapse
Since android 10, you cannot write anything to the system partition.