Needed to "Fix Permissions" twice now...

paintdrinkingpete

Well-known member
Dec 12, 2009
2,916
276
0
OK, you guys here are a pretty smart bunch and have offered me a good bit of help since I got my Thunderbolt, so here's my newest situation...

About a week ago, I rebooted my Thunderbolt (just standard maintenance, not installing anything), and when it came back up, a LOT of my apps instant started popping FC errors on my screen. I mean a LOT of apps. Pretty much nothing worked. So, I rebooted again. Same behavior. Then I remembered about the "Fix Permissions" option in the Das Bamf toolkit, and figured I'd give it a shot to see if it would fix it. It ran for about 10 minutes, but eventually asked me to reboot, and after that everything was working fine. Fantastic -- must have just been a weird bug or something. I had just installed my current ROM (BAMF 1.8) the day before, so I figured something got mucked up as I was re-storing my settings or something.

Now, I understand what this process does, as explained here:
Fix permissions - CyanogenMod Wiki


In Android, each app runs as its own UID (user ID) just like multiple people would have their own UID on a big UNIX system. The reasoning is the same, to prevent apps (people) from messing with each other's data. The data for each app has to be 'owned' by the UID the app runs as, and additionally the app itself (.apk file) has to be that same UID. Unlike big UNIX systems, these IDs are stored in the packages.xml file in /data/system. This file, in addition to storing UIDs, stores the android permissions of each program as described in its manifest (permissions like writing to the sdcard, monitoring phone state, turning wifi on and off, accessing bluetooth, etc). If the file is damaged, deleted, or otherwise unreadable, it is regenerated. The app UIDs are assigned initially in the order you install them (10001, 10002, etc.). When the packages.xml regenerates, it grabs the Android permissions from the .apks but doesn't know what the old UIDs were. That's where fix_permissions comes in.

Whether run from recovery or a booted system, fix_permissions reads through the packages.xml file and performs a chown/chmod command (which changes owner/change read-write-execute permissions) on each .apk and the data directory for it. It doesn't fix Android permissions (e.g. if phone.apk lost the ability to make calls, fix_permissions wouldn't help -- see below). While CyanogenMod udpates the version of fix_permissions in the ROM on a semi-regular basis, the version in any given recovery is probably older (and recoveries aren't upgraded on devices as often, either). So if fix_permissions in recovery doesn't work, the one in the booted rom might (or vice versa).

But then tonight, my Thunderbolt did the exact same thing again! I had gone into recovery and made a nandroid backup (which I do about once a week), and when finished I booted my phone and started getting the same FC errors. I did the "Fix Permissions" routine again, which worked, but now I'm starting to wonder why this has now happened twice within about a week's time without having really made any changes to my OS or anything like that.

I guess my real question is, how normal is this? Has anyone else ever had issues that require "Fix Permissions" to have to be run frequently? Should I be concerned?

Thanks!
 

Trending Posts

Forum statistics

Threads
962,571
Messages
6,990,938
Members
3,164,870
Latest member
wobblefix