Hello guys!
I've rooted my Z without unlocking the bootloader, so I cannot install a custom recovery. This left me with just the choice to debloat the hell out of the stock rom LP 5.1.1.
So far I've managed to lower the number of system apps form 274 to 70!
I've been looking into the system and found two folders:
- odex.app folder
- odex.priv-app folder
Please note that both folders have the odex. extension, so I'm not talking about the folders without it.
Whenever I try to delete files or folders inside these I get the error that it's a read-only file. I've mounted the system partition to rw in terminal and adb, but I still get the same error.
Are those folders read-only all the time or I'm doing something wrong?
On another level, is there a way of completely disabling some hardware components that I never use like Bluetooth, radio, NFC, DLNA, GPS, camera?
The closest thing I got was a code to disable the GPS from booting in build.prop, but I was looking for something more permanent.
I was hoping there may be a command similar to "pm hide" or "pm disable" for hardware features.
xzdualrecovery - twrp on locked bootldr
Related
Hello Everyone,
So I unfroze all of my apps in Titanium Backup and flashed the OTA that is posted in the development forum for the Droid 3 and it seems to have worked great other than one small problem. Every time I try to use the camera or camcorder they will open for about 2-3 seconds and then they close and I end up back at my home screen. Does anyone have any ideas on what I can try to make my camera apps work again?
EDIT: Sorry, forgot to mention that I did try rebooting the phone as well as clearing the cache for the camera app, no change. Also Camera Zoom FX stays open but just has black where the camera image would normally be.
Thanks!
Maybe you... forgot to unfreeze the camera app lol.
No but id check what you do have frozen, maybe there's a service the camera app is dependent upon you might have accidentally frozen (assuming you rerooted after update)
Sent from my DROID3 using Tapatalk
I did re-root after applying the OTA update and then I froze about 15 apps that I found to be annoying/un-needed, however even after unfreezing all of them, any app involving the camera still isn't working. I also just noticed that my flashlight app that worked before the OTA is not working either.
First thing I would try is "clear data" for the Camera app and reboot.
rtbrjason said:
First thing I would try is "clear data" for the Camera app and reboot.
Click to expand...
Click to collapse
Tried that a couple of times but no change. I just also noticed that the camera app flashes a small message up at the bottom of the screen really quickly stating that the camera is unable to initialize.
Uninstall any third-party app that uses the camera (if you have any) the try again.
kishin14 said:
Uninstall any third-party app that uses the camera (if you have any) the try again.
Click to expand...
Click to collapse
Thank you for the suggestion, I hadn't thought of that. Unfortunately that did not work either. No change, still getting the same message for about a second or two and then it closes.
Try re-uploading the camera apk and odex files, might need to set permissions the same as the other system apps.
Unzip and use something like rootexplorer, delete current BlurCamera.apk and BlurCamera.odex, set write access on system/app folder then copy these.
-smc
The problem is the camera firmware, amongst other things, is first deleted and then replaced during the OTA update - if something happens, that firmware is never copied back causing the camera to fail.
The problem I had was too much stuff installed in /system and it simply ran out of space. This also caused my recovery to fail to update which then failed checksum if I tried to boot to recovery.
I had a bunch of binaries I installed in /system/xbin taking up several MB of space. I deleted them - including busybox - and reran the update. Now everything works fine.
If your recovery is hosed, I posted how to fix in the update thread.
If you need help and haven't wiped /cache yet, post /cache/recovery/last_log
limaxray said:
The problem is the camera firmware, amongst other things, is first deleted and then replaced during the OTA update - if something happens, that firmware is never copied back causing the camera to fail.
The problem I had was too much stuff installed in /system and it simply ran out of space. This also caused my recovery to fail to update which then failed checksum if I tried to boot to recovery.
I had a bunch of binaries I installed in /system/xbin taking up several MB of space. I deleted them - including busybox - and reran the update. Now everything works fine.
If your recovery is hosed, I posted how to fix in the update thread.
If you need help and haven't wiped /cache yet, post /cache/recovery/last_log
Click to expand...
Click to collapse
also, one note, i'm seeing alot of people reporting issues with the stock apps AFTER they've removed bloat (any method). the first thing people should do is put the bloat back, or in worse case scenario, do a wipe to see if there's really something wrong.
i froze an email service and it cause my text messenger to stop working. you don't know what libraries are shared with what. freeze with caution.
640k said:
also, one note, i'm seeing alot of people reporting issues with the stock apps AFTER they've removed bloat (any method). the first thing people should do is put the bloat back, or in worse case scenario, do a wipe to see if there's really something wrong.
i froze an email service and it cause my text messenger to stop working. you don't know what libraries are shared with what. freeze with caution.
Click to expand...
Click to collapse
I agree, and would suggest to anyone to use the script for removing and replacing the bloat - it makes it much easier to do (especially from adb when you foul it up) and keeps track of what you've done.
That said, I highly doubt that is the issue here. The update script first checksums everything that needs to be patched and deletes everything that is to be replaced. So if you have anything removed, it will either cause it to fail (if the file is to be patched) or not matter (if it is to be deleted or simply isn't touched). In other words, if you have anything missing that is needed, the update wouldn't touch anything.
Furthermore, I don't think any of the commonly removed bloatware serves as a dependency for the camera. At least not as far as I can tell.
I can tell you that /system is filled to the brim with all of the bloatware. The current ROM is just barely shoehorned in there. Many 'for-root-users' apps like to install stuff to /system and since the updater script doesn't check for free space, it may very well fail to extract in the middle of execution even though it already deleted a bunch of files.
So I think more importantly than restoring bloat, you should remove anything you added.
I tried your directions and re-ran the update after fixing recovery, however my camera still doesn't work because of the same basic issue, running out of space before the update completed. Upon re-rooting and going in to my system directory with root explorer I noticed that I now only have 195k free there. I checked the xbin folder and do not see busybox or anything else there that I recognize that I could delete to free up space. How can I tell what is safe to delete and what isn't so I can free up enough to fix my recovery again and hopefully get the update to work properly?
You can see a breakdown of disk usage with this command:
Code:
du -sh /system/*
Here's mine with busybox removed:
Code:
147.6M /system/app
7.5M /system/bin
11.0K /system/build.prop
5.5M /system/etc
5.1M /system/fonts
35.5M /system/framework
75.7M /system/lib
1.0K /system/lost+found
19.2M /system/media
0 /system/preinstall
304.0K /system/recovery-from-boot.p
4.6M /system/tts
8.3M /system/usr
135.0K /system/xbin
And my free space is
Code:
$ df /system
Filesystem Size Used Free Blksize
/system 320M 317M 2M 1024
Other than su, the only files you need in xbin are (don't worry about the symlinks)
Code:
backup dexdump drm1_func_test run_backup run_restore ssmgrd
I think the only extra bits I now have on /system is su.
I also found the system dump from this post to be very helpful.
Whenever I'm trying du It's saying that the command wasn't found. What are you using for your terminal access?
Hmm it seems du isn't a standard binary even though I have it in bin. I sure don't remember putting that in there...
Anyway, I use adb or Better Terminal Emulator Pro, depending what mood on in.
To use adb, you'll need to install busybox to /data somewhere (I have mine in /data/local/bin) and use
Code:
$ /data/local/bin/busybox du -sh /system/*
BTEP has a fairly complete set of CLI tools included - such as du - so you don't need busybox.
I figured out how to do the command through busybox and have come up with some interesting results...
I am over yours on...
Code:
153.8M /system/app
1.9M /system/xbin
I am under yours on...
Code:
4.7M /system/bin
4.9M /system/etc
71.8M /system/lib
And I match yours on...
Code:
11.0K /system/build.prop
5.1M /system/fonts
35.5M /system/framework
1.0K /system/lost+found
19.2M /system/media
0 /system/preinstall
304.0K /system/recovery-from-boot.p
4.6M /system/tts
8.3M /system/usr
This is with busybox installed in the xbin folder so that is probably why I am over on that one, however the app folder is quite a bit over as well but I can't figure out why. The only file that I can find in there that doesn't seem to belong is Superuser.apk but it is only 191k.
UPDATE: I finally found a large app that wasn't present in the system dump that you had mentioned before. I backed it up to my sd card and removed it, went through the update, and now my camera is working. Thank you very much to everyone who helped, especially limaxray!
Glad I was able to help!
This is a great example for why we should always wipe data/cache before any rom update.
dsw361 said:
This is a great example for why we should always wipe data/cache before any rom update.
Click to expand...
Click to collapse
That wouldn't have helped here at all. If anything, it would have made it impossible to use adb in case of a boot loop.
These are not like community ROM updates and don't need anything wiped.
limaxray said:
That wouldn't have helped here at all. If anything, it would have made it impossible to use adb in case of a boot loop.
These are not like community ROM updates and don't need anything wiped.
Click to expand...
Click to collapse
Exactly. the last thing I would do is wipe data/cache if we encountered a bootloop. Adb is so important to us right now because we don't have a custom recovery or an sbf.
Sent from my DROID3 using Tapatalk
EDIT: Fixed! Procedure I used was to download Danifunker's system dump, move it to /sdcard/ via adb push, then run the following:
Code:
adb shell
su dd if=/sdcard/mmcblk1p21.img of=/dev/block/mmcblk1p21
This completely refreshed my /system folder. Original post below:
--------------------------------------------------------------
Hello XDA forumgoers, longtime reader first time poster here. I'm currently posting because I made a few mistakes. Several mistakes, actually.
1. In my quest to de-bloat my XT860, I accidentally removed one file too many, which caused my phone to mysteriously not have a cell signal. (com.motorola.service.main kept crashing.) So I hit the forum and grabbed a system dump from this thread (thanks Willis111):
http://forum.xda-developers.com/showthread.php?p=17501981
I had bought the phone with some version of Cyanogenmod Recovery installed by the previous owner, so I was able to use that and ADB to stick the .apks and .odex files in the /system/app folder, chmod 644 them, and even factory reset for good measure.
2. As I soon found out, I had somehow made things worse. The phone, when boot into, shows the "press android to begin" page, but com.motorola.service.main and some other apps keep FCing on me, and I can't progress past that screen. In my haste, I didn't backup any of my system folders at all, though, I still backed up my apps with Titanium.
Tl;dr:
presumably none of the /system/app apks boot, most notably com.motorola.service.main. How do I fix this? Can I?
Try to flash
http://forum.xda-developers.com/showthread.php?t=1288823
You also need to chown 0:0 both the apk and the odex
Have you tried using my original system dump? It was taken with dd, so things like symlinks and the other sort should be functional. The only caveat is that a number of apps were frozen at the time, so you may need to unfreeze them with titaniumbackup.
http://www.multiupload.com/SORQERFAYT
DoubleYouPee: Is this that chinese rom I've heard of? I heard that if I flash this, I can't root my phone. So I think I'll save this one as a last resort.
eww245: chown'd, no result.
daniflunker: how do I open this?
jonsicoli said:
DoubleYouPee: Is this that chinese rom I've heard of? I heard that if I flash this, I can't root my phone. So I think I'll save this one as a last resort.
eww245: chown'd, no result.
daniflunker: how do I open this?
Click to expand...
Click to collapse
What about rootkeeper?
DoubleYouPee said:
What about rootkeeper?
Click to expand...
Click to collapse
I can't get past the "click android" screen, so I probably can't install or run it. Any way to do it via adb or Cyanogenmod Recovery?
I really appreciate the help.
jonsicoli, if you want to restore your *entire* /system folder (not just apps) you would run a similar command-set as this.
1. Copy the file to the internal memory
adb push c:\path.to.folder\mmcblk1p21.img /sdcard
the file will be located in the root of the sdcard (or you could drag and drop the file in USB storage mode)
2. Do a full restore on system memory *I have not checked to ensure this is working... but a command similar to this should work
adb shell
su dd if=/sdcard/mmcblk1p21.img of=/dev/block/mmcblk1p21
- wait -
(it would have to write about 500mb and replace all of the contents of /system )
reboot
_______________________________________________________
Okay, if you just want to look at the files, you could use a linux machine to mount the filesystem (it is a standard ext3 FS) or you could do what I have done on my windows system:
Install EXT2FsD from http://sourceforge.net/projects/ext2fsd/files/latest/download?source=files
Then install OSFMount from http://www.osforensics.com/tools.html
Point the OSFMount program to the img file that you downloaded and assign it a drive then voilla!
I am pretty sure this is a bit of overkill, but this should completely restore your system close to factory (minus the APKs that were upgraded/disabled, plus the fact root was done)
Thanks Danifunker! I reset my entire /system folder, and restoring my user app backup. I'm just relieved to have my phone back. Now to mark this thread as solved.
Awesome!!!!!! Glad to hear my system dump works! Thanks for testing
My command lines were written correctly also I guess?
Sent from my XT860 using XDA App
searched for like 8 hours until i found this thread. Just what i needed, i had system image for 2.3.6 from your other post but no command.
Hello all,
After switching to cyanogenmod, I noticed that items are stored in a different directory. This resulted in a complete data loss on first boot. I was able to move over some folders from /system/media to get my data back, but it seems that these directories are somehow linked. (Deleting files/folders from one deletes the others)
What is the best way to correct this and get rid of these oddities?
I am fairly adept with ADB commands, so I just need to know why this issue exists, and if I need to somehow remove some symlinks.
I've been trying to read Magisk modules documentation and I've made a few personal modules to replace/add files, but how to remove files?
For instance, what do I need to do in a module to remove some system app like it was never installed?
Use this:
https://github.com/topjohnwu/Magisk/blob/master/docs/tips.md#remove-folders
It'll be like all files in the target folder is deleted.
@Didgeridoohan That's it, thanks. How do I mark your answer as accepted?
Thank you.
With all the respect to topjohnwu, the linked answer is not 100% precise. If you replace system files with the empty copies, their functionality will be disabled of course, but their existence in the system will still be detectable, though the files cannot be considered as "really deleted". I can personally think of at least few scenarios when the above makes difference.
For example, there is a popular issue with Netflix not working at all on many devices with tampered boot partition (and tampering boot partition is unfortunately
required when installing any systemless root solution like Magisk...) due to the fact that the HD playback DRM library located at /system/lib/liboemcrypto.so (or /vendor/lib/liboemcrypto.so) cannot access DRM keys located in Trusted Zone and fails to do its decoding job. The popular solution is to delete the liboemcrypto.so from the system, then device shall stop trying to play HD content via non-functional HD DRM engine and it shall switch to SD DRM mode which is not dependent on hardware decoding. In result, Netflix will start to work (in SD only mode, though, but it's more than nothing...).
In above scenario, replacing liboemcrypto.so with empty file with the same name will not work. That's because Android assumes that the HD DRM is available basing only on the liboemcrypto.so existence, without checking its content or size.
My own solution when making a Magisk Module which aims to delete some file is to override that file with its copy (and its content does not really matter, it might be 1:1 copy of original as well as 0 bytes empty file...) and additionally: to set its permissions to 000 - it can be easily achieved by editing the permissions part of module's config.sh when creating a module. After installing and enabling such a module, the subject file will still exist, but it won't be seen by the system and apps at all, as the 000 permissions make it absolutely forbidden to interact with the file at all, in any way, by any user (including "system") except root.
In the summary: approach proposed above should guarantee not only that the selected files functionality will be disabled but also that the system and third party user apps shall consider that files as totally non-existent, which i find a real equivalent of deleting the file.
I'm not sure I understood everything you said but the solution above works for my use case. For instance, I have this on my module:
Code:
REPLACE="
/system/priv-app/InCallUI
"
And after enabling my module and rebooting the device, browsing to /system/priv-app/InCallUI/, there's only one file there, ".replace". The .apk from that app is not available/visible anywhere. Launchers to do not detect this app, apps which list installed apps (user or system) do not show this "removed" app.
For all intents and purposes, it works for what I personally want to achieve.
Good day,
I recently discovered malware in the root directory under the / prism folder that installed an app called Yandex into my system and contained various hidden APKs. (and files with .sogou at the end).
These manipulated my internet browser in some way and I was only able to remove them by flashing the stock rom.
Now I get the message from TWRP that the partition / prism could not be mounted. Even so, everything seems to be working fine on the device.
Now there is no more content in the / prism directory. What is usually stored there and what is its purpose?
Do I have to rework something?
I can't find an explanation anywhere else on the Internet ...
Thank you and best regards
According to https://github.com/PrismLibrary/Prism
Prism provides an implementation of a collection of design patterns that are helpful in writing well-structured and maintainable XAML applications, including MVVM, dependency injection, commands, EventAggregator, and others.
Click to expand...
Click to collapse
In short Prism is a framework to build applications which in turn it's built on top of another framework called Xamarin (XAML for Android).
As of why it's in the root directory I suspect is part of AppCloud, Samsung's system app, that basically does remote installation of apks.
If it is correlated to AppCloud (Big IF) then:
If you are rooted and on stock OS and have that app enabled it's not far fetched to think that there is an exploit for it out there and basically anyone could remote install any APK through root privileges and the backdoor that AppCloud system app gives the.
It's could be as easy as editing a file from within the malicious app which could change the behaviour and URL from which it fetches the needed apks. Whereas installing apks from within the malicious app needs explicit OS permissions (which AppCloud has).
I too had apps installed post-upgrade by the AppCloud system app, but I don't have root to analyse this further so all the above are just speculations based on the two things you said and my previous observations.
In the end you could have contracted the malware in a million different ways. That's how it goes with root access on OS and careless root management.
I have to admit that I was too careless with root privileges and experimented with little knowledge.
Hope that helps others to deal with it more intensively beforehand.
Your explanation helped me, the problem is a bit more serious, it is probably about corrupt security certificates in the system that are administered from outside
In this case, is it even possible to reset or delete the CA certificates? I guess I fell into a spoofing trap.
Maybe flash the stick rom again through Odin?
Is that embarrassing: D
Sorry for the graveyard post but I don't see any other threads about this.
Prism is the name of the NSA surveillance program. I guess that this is exactly that.
It's hidden because you can only see that it exists with root and most people don't have root.
I have this folder too on my rooted Galaxy Fold 4. It was already in the stock ROM and I cannot remove it because the directory is mounted as read only.
If found the mounts file (which is also read-only) and it says:
Code:
/dev/block/platform/soc/1d84000.ufshc/by-name/prism /prism ext4 ro,seclabel,relatime,i_version 0 0
I tried to give me the permission to write / delete the folder but "permission denied" ... and yes I did that as root.
Nexariuss said:
Sorry for the graveyard post but I don't see any other threads about this.
Prism is the name of the NSA surveillance program. I guess that this is exactly that.
It's hidden because you can only see that it exists with root and most people don't have root.
I have this folder too on my rooted Galaxy Fold 4. It was already in the stock ROM and I cannot remove it because the directory is mounted as read only.
If found the mounts file (which is also read-only) and it says:
Code:
/dev/block/platform/soc/1d84000.ufshc/by-name/prism /prism ext4 ro,seclabel,relatime,i_version 0 0
I tried to give me the permission to write / delete the folder but "permission denied" ... and yes I did that as root.
Click to expand...
Click to collapse
did you ever find anymore about this? ive found it on two of my phones. both samsung. cant find much online about it...