Related
I'm working on a tool I'm calling "applytheme". Basically you create a theme.zip, stick it in an archive with the included applytheme binary and update-script, sign it, and it will update the files on any of the Dream firmwares with the ones you've provided.
There are some limitations currently:
It can't yet determine space required before-hand, so you may run out of space in the middle. If you do, you can just restore the original theme with the restoration update.zip.
It can't add files - only replace existing ones.
The original files are stored in /data/original_theme.zip, which will eat your /data space, but only the replaced files are stored.
This version is a test release and may or may not have bugs. Be sure to back up your phone before trying it.
Please consult the example for figuring out what to put in the theme.zip, but it's basically full-path-to-filename-you-want-to-update/full-path-to-file-you-want-to-replace
So if you wanted to replace "assets/images/android_320x480.png" (the boot screen) in "/system/framework/framework-res.apk", you would have a file in your theme.zip called "system/framework/framework-res.apk/assets/images/android_320x480.png".
Case matters - please use the correct case (which is usually all lowercase).
Example theme (replaces boot animation only, with a cupcakedroid):
applytheme-200902090018-example.zip
Restoration update.zip (restores from /data/original_theme.zip then deletes original_theme.zip):
theme_restore-200902090018.zip
Source code (for developers or other curious people):
applytheme-200902090018.tar.gz
EDIT: 200902082117 fixes a couple of stupid bugs in 200902081755 :/
EDIT: 200902082316 removed extraneous/incorrect free space check; noticed that the update script stuff is significantly more stupid than I'd thought - update scripts should work now.
EDIT: 200902090018 close files so space can be reclaimed during patching
Reporting problems
If one of the applytheme updates fails, while still in the recovery mode please do the following:
Press ALT+X to get to the console
Press <enter> to get to the prompt
Type cp /cache/recovery/log /sdcard/recovery.txt
Type df >> /sdcard/recovery.txt
Type reboot to reboot.
Send the recovery.txt from the SD card to zinx <AT> users.sourceforge.net with the subject "applytheme error log"
If I don't have the log (or at least the error message from the log), I can't know why it's failing, and can't do anything to fix it.
I am looking at your post but don't see the benefits of doing it like this. you would still need to do this every time you add a theme or just a image and you still need to sign it or am I just not seeing the benefits of using it
kron2 said:
I am looking at your post but don't see the benefits of doing it like this. you would still need to do this every time you add a theme or just a image and you still need to sign it or am I just not seeing the benefits of using it
Click to expand...
Click to collapse
Current themes replace the whole system.
If you change as single file in /system/app/Browser.apk (say, an icon), you have to replace the whole file.
You don't have to do that with applytheme, so you can replace the icon no matter what firmware is being run.
This would be great themes wont need to be converted any more.
manup456 said:
This would be great themes wont need to be converted any more.
Click to expand...
Click to collapse
Indeed, for example:
More Vintage Less War via applytheme (theme by manup456 )
EDIT: Oh, I should note I tested this one with RC33. Didn't bother to time the progress meter though, so just wait until it tells you to reboot with home+back.
This looks like an amazing tool! I'm surprised more people haven't checked this out.
Let me get a few things straight before I give it a shot.
Let's say I was updating some basic images in the framework-res.apk. All I need to do is:
~Download your applytheme-example.zip
~Open up the theme.zip (remove current folders inside)
~Create the folders system\framework\framework-res.apk\res\drawable\
~Add the icons I've changed, with the exact original names
~rename applytheme-example.zip to update.zip
~load onto SD card and load onto phone as usual
~success?
I don't quite understand the backup system...
When you load the update onto the phone, it backs up the images you're replacing and puts them into a \data\original_theme.zip?
Then, if for some reason you want to revert to the original theme, you simply run the theme.restore.zip on the phone and it grabs all the \data\original_theme.zip images and places them in their original location?
Also, if the theme you're installing is a few megs, then the \data\original_theme.zip will get rather large, no? Will this cause any issues?
Thanks!
The steps are a bit more like this:
Download applytheme-example.zip
create system/framework/framework-res.apk/res/drawable/
add the files you've changed
create a theme.zip with the files above - MAKE SURE IT HAS THE PATH, STARTING WITH system/
replace the theme/theme.zip in applytheme-example.zip with your new theme.zip
sign the applytheme-example.zip with the replaced theme/theme.zip
put it on the SD card as /sdcard/update.zip and update as normal
success! (unless there was a problem during patching, then it may be partially applied and you can use theme_restore.zip to fix it)
MOONSSPOON said:
When you load the update onto the phone, it backs up the images you're replacing and puts them into a \data\original_theme.zip?
Then, if for some reason you want to revert to the original theme, you simply run the theme.restore.zip on the phone and it grabs all the \data\original_theme.zip images and places them in their original location?
Click to expand...
Click to collapse
Yep.
MOONSSPOON said:
Also, if the theme you're installing is a few megs, then the \data\original_theme.zip will get rather large, no? Will this cause any issues?
Click to expand...
Click to collapse
It can get large, yes, but keep in mind that it's only the original files that have changed that get put in it. Most themes right now are much larger .zips than they actually are, because they include much more than what was changed. If it gets too large to fit, the update will just fail part-way, and you can restore using the theme_restore.zip.
You can also delete it if you don't want to restore.
If you have any better ideas for any of this, I'm definitely open to suggestion - It's not anywhere near finalized yet
Great work. Definitely a step in the right direction for generalizing themes and allowing them to work with any build without modification.
Some thoughts for the next steps... Perhaps do a once-over of the files in theme.zip and compare their sizes with the existing files? This would just about double the time it takes to install, but should catch any out-of-space issues before any replacements had been made. Alternatively, perhaps there's a way to detect failures and automatically revert and display an error?
MasterBunnyFu said:
Great work. Definitely a step in the right direction for generalizing themes and allowing them to work with any build without modification.
Some thoughts for the next steps... Perhaps do a once-over of the files in theme.zip and compare their sizes with the existing files? This would just about double the time it takes to install, but should catch any out-of-space issues before any replacements had been made. Alternatively, perhaps there's a way to detect failures and automatically revert and display an error?
Click to expand...
Click to collapse
Automatic reversion can be done.
The update stuff is too stupid to let me display an error (Seriously. There's no way to display a message to the user. All I get is the unchangeable 'Failed on line 3'.) - an error is kept in /cache/recovery/log though.
Checking the file sizes would indeed take twice as long - everything is compressed, so I'd basically be creating every file touched, but discarding the output, then creating it all again. It already takes quite some time, and it should normally have enough space free, so I would prefer to go the automatic reversion route if people don't want to have to use the theme_restore.zip after a partial update.
So I tried throwing in your more vintage theme, but I get the error failed on line 4.
I feel like a leecher posting this message, but explain to me how it's done.
APrinceAmongMen said:
So I tried throwing in your more vintage theme, but I get the error failed on line 4.
I feel like a leecher posting this message, but explain to me how it's done.
Click to expand...
Click to collapse
Should just be putting in it; can you post the /cache/recovery/log from after it fails? May need to copy it somewhere before rebooting.
I expect it's due to lack of space, but it was ok here :x
In an effort to make it a bit easier initially, I've written "toapplytheme". It takes a theme update, the update it was based on, and outputs an applytheme compatible theme.zip - You still have to put in in theme/theme.zip in the applytheme update zip and re-sign it, though.
If you use something other than the update it was based on, you're going to end up with a lot of extra and/or missing files, so don't do it.
Ex:
Code:
toat MyExcellentTheme.zip JFv1.41_RC33_light2.zip theme.zip
toat-200902091613.zip
Worked for me
I have an ADP1 w/the latest JFv1.43h, I extracted Rusty Metal (from the RC33 version, using you tool). Put it there on the example, signed it all and voila...
The only thing I noticed is that the background did not get changed, but that is a minimal issue (and easily fixed).
Great job Zinx, I don't understand why all theme designers don't use this tool.
A matter of time I hope?
DanOtero said:
I have an ADP1 w/the latest JFv1.43h, I extracted Rusty Metal (from the RC33 version, using you tool). Put it there on the example, signed it all and voila...
The only thing I noticed is that the background did not get changed, but that is a minimal issue (and easily fixed).
Click to expand...
Click to collapse
I just applied Rusty Metal to my G1 using the standard way (not this tool) and the background doesn't install with it anyways, so it's not a problem with this tool, but the theme itself simply doesn't include it.
I searched as best I could, but couldn't find a match to this particular issue.
I do have a rather weird issue with Gallery3D, that I've noticed after switching to OpenDesire, in 4.0.10 and 4.0.15.
Until recently I have been using various Sense based ROMs, where photos taken with the phone are stored in DCIM/100MEDIA and I always just used HTC's gallery app.
Now I'm on OpenDesire 4.0.15, which stores phone photos in DCIM/Camera, and uses Gallery3D to display them.
The thing is, when I try to display photos from DCIM/100MEDIA, taken earlier on various sense ROMs, Gallery3D shows some completely random photos instead. The thumbnails in 100MEDIA display correctly, but when I tap any thumbnail, it expands to the grainy fullscreen version, and is then replaced with a sharp and refined version of *another* picture.
It shows photos that I have taken with this same handset, but imported to my computer and deleted from the phone long ago. That is, photos that aren't even *on* the SD card anymore.
I have tried the following:
1. settings > apps > manage > Gallery3D > force stop + wipe data and settings
reboot
no luck
2. rename 100MEDIA to something else.
repeat 1.
no luck
3. Create new folder DCIM/Test
Copy files from DCIM/100MEDIA to DCIM/Test
The copies in DCIM/Test work well.
Hm.
4. factory reset, wipe cache + dalvik
reflash OpenDesire (4.0.15)
no luck
5. Made a flashable zip with most recent Gallery3D.apk from this thread and flashed it over the one included in OpenDesire 4.0.15
No luck (yes the update succeded, different file size )
Ok, fine, so I kind of solved the problem in attempt number 3, right? Well, yeah, except that I'm uncomfortable about my phone magically raising photos from the dead that I've deleted long ago.
Have you guys got any ideas or input?
Well, your deleted pictures aren't exactly "dead", they just aren't in the master file table of your SD once you hit delete, but they can definetly read. But to avoid going offtopic, you can simply back up your files, format the SD card and restore the files. Everything should be ok.
As to why this happened, it's possible that your Master File Table got corrupted somehow (or Android's MediaManager isn't reading it correctly). But I can't really say much since it's difficult to tell what the real cause is (perhaps you didn't "safely remove"?).
Either way, reformatting should help. And keep using Gallery3D from that post, it's one of the best around
Reason
Even i experienced the same issue,,but couldn't find the solution,,,,but i figured out why it is happening..!!
My gallery 3d app was showing the images i took long back which are no more in the SDcard..!!!how can it be possible..??
The reason is,,
>When we delete the file in the sd card,,the operating system will just mark that that memory location with some special character ,,in fact the data will appears to be deleted but truly i won't ...!!
>when we add new files to the file system that space will be overwritten ,,,by the new file...!!
>So in our case the file which appears as the thumbnail is in exact same memory lactation as the old deleted image....so the thumbnails will be stored in different location as the cache,,,,,
>this is the reason why it show the thumbnail but when we click on that,,, it shows the original data resides there....!!
> its just a bug in the Gallery app
>And it will happen only when we delete the files inside the gallery app...
>Next time try to delete the files in Some file managers like Astro
I keep finding a "bugsensedata" and several "Ping_13621....." files on the sdcard. What is creating these?
creeve4 said:
I keep finding a "bugsensedata" and several "Ping_13621....." files on the sdcard. What is creating these?
Click to expand...
Click to collapse
What ROM are you running? Have you tried to open the files in a root browser to see whats creating them? Some apps like happy bay and certain weather widgets (just to name a couple) add tons and tons of images to your phone to easily access them in the future....try opening the files in a root browser....open them as a text or open them as a picture to see where they are being created....if you cant open them then long press and hit details to find some clues as to where they are coming from
I'm running AOKP. I'll open the files and see if there are any indications as to which app is creating them.
creeve4 said:
I'm running AOKP. I'll open the files and see if there are any indications as to which app is creating them.
Click to expand...
Click to collapse
Had the same thing happen to me. In root browser it has the time and date associated with the file I just eliminated specific apps that I know I didn't use on that day,after deleting bug and ping files, I then tried the ones that I did use until the bugsensedata showed up again.
Hope this helps...
I also suffer from the "Ping_..." files being created
creeve4 said:
I keep finding a "bugsensedata" and several "Ping_13621....." files on the sdcard. What is creating these?
Click to expand...
Click to collapse
Did you ever get to the bottom of what is creating these "Ping_13621....." files?
I too am getting these files created on each boot meaning they can accumulate quite rapidly. I don't even have the same device as you but your post appears to be the only entry regarding this on XDA. I hadn't noticed this issue until today and it is impossible to tell what is creating them as it happens each time i boot but with no identifiable data inside.
DraconianGothic said:
Did you ever get to the bottom of what is creating these "Ping_13621....." files?
I too am getting these files created on each boot meaning they can accumulate quite rapidly. I don't even have the same device as you but your post appears to be the only entry regarding this on XDA. I hadn't noticed this issue until today and it is impossible to tell what is creating them as it happens each time i boot but with no identifiable data inside.
Click to expand...
Click to collapse
Well i think i've worked this one out after removing/ reinstalling over 80 of my apps. The 'rogue' app appears to be the Argos app, a UK retail store. I did look through all apps on my phone to see if any version numbers matched the entry inside the Ping_ files (3.0.8:_ping:GT-N7100:unknown:4.1.2:1.2.3:English:1363794618802) but somehow missed the version number. The current version of the Argos app on the Google Play UK store is 1.2.3, which matches up. I have now recreated this issue a number of times with the same effect.
Of course, there might be other apps which work in the same way, creating multiple small 'Ping_' files.
bugsensedata in my sd card
In my phone, "Wattpad" is creating the bugsensedata. I noticed that bugsensedata appears whenever I open it.
I just changed my RoM to hyperion 7 and am installing my apps one by one. Then, after opening each app, I check My Files. So I am sure that Wattpad does it.
In /data/app folder make a new folder with name com.android.vending-1.apk
(to make the folder use a file manager app or the command "su" followed by "mkdir /data/app/com.android.vending-1.apk" with a Terminal Emulator app and Busybox installed.
NOTE: Making a new folder in /data partition require root permissions so the Andriod system must be rooted first)
That's it!
Hello everyone,
owners of smartphone with very limited internal storage, like Galaxy Y, will likely end up to be concerned of every single MB of free space lost; and the more the concern as the free space is getting closer to zero.
So there I am too.
I've put lot of effort to optimize the use of my Galaxy Y internal storage (/system, /data and /cache partitions all together) and I'm proud to have more than 50% of internal storage free and I like to have it that way for as long time as possibile.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
One day, few weeks ago, I got very disappointed when I realized that I suddenly lost 15% (actually 15MB) of free space for some unknow reason
Later, it turned out that the reason was that the Google Play Store had been silently updated in the background without any notification.
Actually the footprint of newer version of Google Play Store is only 4MB bigger but as the previous version was installed in /system partition then the update process doesn't actually perform a replacement of the old installation with the new one, but it just add the newer app leaving the old installation untouched (that means leaving in place the old apk file along with its davilk-cache file) but marked as disabled.
Uninstalling the update (that in my opinion, for my needs and usage, was useless) was just a matter of tapping one button... but then another background update would have happen soon after.
So, as I didn't find any related option in Google Play Store settings, I immediately started a Google search to find a way to prevent/avoid/stop any further self update.
What I've found is only two solutions:
- one is about to freeze/disable the app that manage the update of Google Play Store; but this app doesn't longer exist or it's used as the latest Google Play Store app handle the self update by its own.
- the other one is to make a "dummy" file in /data/app that will make the installation of the update to fail as the required name for the new apk is already in use by the dummy file.
Unfortunately for those smartphones, like the Samsung Galaxy Y, where the /data partition is formatted RFS (Robust File System from Samsung; basically a FAT 16/32 based file system with a sort of journalling system on it) this solution doesn't work because RFS doesn't support the immutable file attribute and therefore the "chattr +i" command will fail.
If the dummy file isn't set as immutable then the installation task will be able to delete it and make the new apk in /data/app folder.
As an attempt to make the second solution, the "dummy file solution", to work with my Galaxy Y, I made the immutable dummy file in another partition then I created a link in /data/app pointing to that file.
But that didn't work... same as for the not immutable dummy file, the link can be deleted by the installation task that will then proceed till completion.
So what to try next?
From what I've read around seems that there's no solution; owners of Galaxy Y (that didn't reformat the /data partition with a Ext2/3/4) and other smartphone with RFS filesystem are simply out of luck.
True?
No! False!
I then remembered the days I used to make a autorun.inf folder in the root of my FAT32 formatted USB thumbdrive to prevent removable drive spreading viruses to make their own autorun.inf file in the thumbdrive.
So... why not to try the same trick to make the installation of the Google Play Store update to fail due to the impossibility to make it's own com.android.vending-1.apk file in /data/app folder?
Tried it...
and tested...
SUCCESS! :victory:
As a side note I want to point it out that this trick doesn't prevent the Google Play Store to try to self update and download the latest installer in the /cache folder.
Anyway I've observed that after the first failure of the update there are no further update attempts neither new downloads... at least for a while (maybe till next new version will be released?)
I don't know how long it takes, after the first update failure, for the downloaded apk in /cache folder to be automatically deleted... if ever; so I advise you to give a look at the /cache folder and manually delete it if still there.
That's all folks!
Bye!
Why don't you just integrate update to system with link2sd app
It will just replace the system app with the new update - you get the latest update and you not using any extra space with two versions of the app
Root required & restart after integrating (or it will force close)
That could be done, of course, but still there's a loss of 2MB of free space in /data and 2MB in /system due to the bigger footprint of the latest version.
Anyway is completely up to a personal choice if to upgrade or not.
The point here is that if someone doesn't want Google Play Store to self update now there's a known way to do so
Another way to do this is to did a modded play store apk here on XDA. A modded apk has been signed with a different key and therefore it cannot be updated by Google.
Uninstall any updates to the Play Store and put the modded apk in the system apps folder replacing the one on your phone, make a backup just in case. Reboot and you should have a play store that doesn't update.
Sent from my XT1060 using Tapatalk
good trick bro :highfive:
save quota internet
vin2m said:
good trick bro :highfive:
save quota internet
Click to expand...
Click to collapse
:highfive:
Thanks for the highfive bro
Anyway I'm afraid that, as I pointed out at the bottom of my 1st post, even if the trick makes the update to fail (same as per the immutable "dummy file" trick) but it doesn't prevent Google Play Store to download the newer version (9MB of data or more) for the upgrade attempt; so the Internet quota is still affected.
How to stop updating play store WITHOUT root .. I need to have 4.x.x. installed but it auto updates to 5.x.x how to stop it
(cannot root my phone)
thnx
I'm sorry but I'm afraid that without root privileges there's no way to avoid the self update of Google Play Store as this app is designed to self update and doesn't expose any option/settings that the user might use in order to disable that function.
So, as the self update can't be disabled by power of user account, it's required to operate at system level and therefore root privileges are needed.
halnovemila said:
I'm sorry but I'm afraid that without root privileges there's no way to avoid the self update of Google Play Store as this app is designed to self update and doesn't expose any option/settings that the user might use in order to disable that function.
So, as the self update can't be disabled by power of user account, it's required to operate at system level and therefore root privileges are needed.
Click to expand...
Click to collapse
Fuking google bas****ds are they ?
Wow, sneaky! This is obviously a far superior solution to my chattr method. Wish I'd thought of it!
this fix is no longer working it still forced the new version right after the commands
RemixedCat said:
this fix is no longer working it still forced the new version right after the commands
Click to expand...
Click to collapse
Hi RemixedCat,
I've tried just now to install the latest version of GPS (6.0.5) and the installation fails with the usual "Out of space" error (as shown on the video I published) due to the presence of the empty dummy folder.
If the folder is removed the installation completes without errors.
So the trick still works.
If it doesn't work for you maybe your Android configuration is different from mine, or you made a mistake on following the given instruction.
In order to figure out why in your case the update still take places and then try to give you some advices, please tell us:
- what's the Android version running in your phone
- if it's rooted
- what's the GPS version installed
- if the GPS currently installed is an update or not
-if you want to keep the current update or not
- if the GPS currently installed is installed as System app or User app
- what's the apk filename of the currently installed GPS.
You might want to install Link2SD to check the informations related to the currently installed GPS.
LOL
Very funny... all the people that post here or on my video comments saying that the trick doesn't work, once they get an answer from me with few advices on how to make it to work, they almost never care to reply again.
Did my advices worked out so that the initial statement of "it doesn't work" has proved wrong? or they didn't even care to read my reply or to follow my advices or to give positive feedback in case they finally have been able to have the trick to work as supposed?
Only God knows
I'm having trouble with this as well. I have replaced my preloaded GPlay store apk under /system/priv-app/Phonesky with a 8.10.30 apk - and created folders in /data/app/ named "com.android.vending" "com.android.vending-1" "com.android.vending-2" and the same with .apk on the end of the file name. I used terminal emulator and the su command, and even tried chattr +i - but still, google Play Store silently updates itself after a while and I get a new "com.android.vending-3" folder with the new apk in it. I'm at my wits end at this point. I don't want any newer versions of the store because they cause horrible battery drain on my M7, whereas 8.10.30 gives me no trouble. But without the folder trick working, my only hope seems to be to use LuckyPatcher to try and disable autoupdating that way.
And I honestly am yet to see a download source for LuckyPatcher that looks the least bit trustworthy.
Aaren11 said:
I don't want any newer versions of the store because they cause horrible battery drain on my M7, whereas 8.10.30 gives me no trouble
Click to expand...
Click to collapse
Hi Aaren11
I don't know a single thing about M7, except that it's not a Galaxy Y phone and that for sure, according to what you said, the Android version running on your phone is different from the stock Galaxy Y Android version which is Gingerbread 2.3.1.
In Android 2.3.1 user apps apk file are stored in /data/app folder while in your case, according to your post, the app apk is stored in a subfolder of that path, so instead of /data/app/com.android.vending-1.apk you have /data/app/com.android.vending-1/<something_here>.apk
This changes the scenario quite much.
I did a bit of search on Google to figure out what's your Android version and what's the default apps apk store folder without having to ask to you and waiting for your reply.
What I found out is that M7 is an HTC made Android phone, and is running Android KitKat 4.4 or above.
According to what i've found in Android 4.4 the apps apk file path should be like this:
/data/app/com.android.vending-1/base.apk
where the apk file name is not <app_name>.apk but just base.apk.
Is that correct Aaren11?
Is the file name of the apk you found in /data/app/com.android.vending-3 folder, base.apk?
So, let's try to adjust the trick to match your system.
- First of all switch off your phone Wifi and uninstall the GPS update.
- Clean the /data/app folder from all the com.android.vending???? folders you previously made.
- Make this new empty foders /data/app/com.android.vending/base.apk and /data/app/com.android.vending-1/base.apk
- To try if the trick works, instead of waiting for the next auto update that you don't know when exactly is going to happen, go download the GPS apk, move it to your phone via bluetooth, or USB or SDcard and install it.
Btw my Google search didn't result in any GPS version above 6.0.5 which seems to me to be the latest so I really wonder how is possible your GPS version is 8.10.30 unless that's not the GPS version but another related number you read somewhere else.
Anyway you can download the latest GPS version APK from here http://www.androidapksfree.com/apk/google-play-store-apk-latest-version-download/
- Post here the outcome of the attempt.
If the trick works the apk installation should fail with a "out of space" error message.
Good luck!
Thanks for the reply halove,
Honestly I suspected that simply altering the tweak to fit the different file structure might work, but at the same time because every single post on this matter I've seen so far referenced the same set of folders with the .apk extension - I also was under the impression that their precise location was mandatory to the functioning of the fix. I'll try fitting with my current file structure and seeing if I have any success.
Just to answer some of your queries. The M7 runs up to Android 5.0.2, at least that's as far as HTC has deined to bless us with OTA's, anything beyond that requires a custom ROM.
And my google play services is indeeed 8.3.00, I was confusing it and my Play Store version of 5.10.30. Last I checked Play services only goes up to 8.4.89.
Yeah no luck there I'm afraid.
Doesn't matter how many 'com.android.vending' or 'com.google.android.gms' directories with 'base.apk's I make - there is always a new one created, and the update is installed. I went all the way up to 'com.android.vending-5' and it still persists creating a sixth directory and auto updating. Again, I'd have no problem with this, were it not for the fact that I get rediculously high cpu usage on anything above 5.10.30 and 8.1.14 - nevermind the inability to opt out of this update, or the rumours that Google keeps pushing new hidden features that I don't want collecting my personal information.
I've tried even intergrating the 5.10.30 / 8.1.14 apk's into /system/priv-app/ but neither copying the files directly out of /data/app/ and renaming them appropriatley, or using TiBu's 'intergrate to ROM' option seems to work.
I really am at my wits end here.
Hi Aaren11,
well, honestly I wasn't much confident the trick could work in your case (and in any Android 4.4 or above) because the failure would happen if in the folder the package installer is going to save the app apk file, there's already "something" (either a file or a folder) that already uses the same filename of the apk that has to be saved.
But given that the package installer makes a new empty folder where to store the apk, then there inside won't be anything that will interfere with the installer.
In earlier Android versions seems that the package installer doesn't recognize the existence of the dummy folder because, in order to chose the apk file name, the installer check only the existing FILES and there names, so it skip the folders... but when it's time to "write" the file, the presence of the folder with same name will make the installation to fail.
But in Android 4.4 for sure the package installer will check the folders name first, in order to chose the name of the folder that it will make to store the apk file inside.
So the dummy folder will be recognized and "skipped" by making a new empty folder with a different name.
So there's one last hope.
If in pre 4.4 Android the trick works because the installer check for existing files but not for existing folders, maybe in 4.4 the trick could work if the installer check ONLY for existing folders and NOT for existing files.
So here's the plan
Delete all the dummy folders you made.
In /data/app make a dummy file (a empty text file) and give it the name of the folder the installer will likely use (com.android.vending, com.android.vending-1).
If the installer won't recognize it, then likely it will fail when it will attempt to make the folder.
If it recognize it and will delete it first, then you have to make it undeletable by power of the "immutable" flag that you can set on the file using the chattr +i command; given that the /data partition is formatted with an Ext filesystem.
Once again... good luck!
halnovemila said:
Hi Aaren11,
Delete all the dummy folders you made.
In /data/app make a dummy file (a empty text file) and give it the name of the folder the installer will likely use (com.android.vending, com.android.vending-1).
If the installer won't recognize it, then likely it will fail when it will attempt to make the folder.
If it recognize it and will delete it first, then you have to make it undeletable by power of the "immutable" flag that you can set on the file using the chattr +i command; given that the /data partition is formatted with an Ext filesystem.
Once again... good luck!
Click to expand...
Click to collapse
Sadly, still no dice.
Even just using the installer apk for a more up to date version of Play Store, it simply creates a new folder, numerated after the files I've made. I created:
com.android.vending
com.android.vending-1
com.android.vending-2
As blank files without an extension. And the installer simply creates a 'com.android.vending-3' folder and installs there.
I'm going to try again with dummy base.apk files in the appropriate folders - but I doubt it'll work. The installer clearly seems capable of distinguishing dummy folders and files, and simply creating a new directory every time.
Edit: No luck with that route either. The installer still simply creates a new, sequential directory and installs to that. At this stage it looks like the only way to get out of either app auto updating silently would be to block that process from starting entirley, because simply trying to trick it with misleading directories clearly isn't going to work. I think I'm going to have to give lucky patcher another go. Thanks google -_ -
Aaren11 said:
The installer clearly seems capable of distinguishing dummy folders and files, and simply creating a new directory every time.
Click to expand...
Click to collapse
Nah, I don't think the package installer cares about the files and folders it finds in /data/app, either real or dummy... what the installer does is just to check the existing filenames so to make a proper new one.
And the trick works only if the package installer can't "see" the dummy folder/file before its attempt to make the new folder/file.
So, seems that the package installer of Android 4.4 (and above) is a bit smarter than the one that comes with earlier versions.
I was wondering if there's a way to "hide" the dummy folder/file to the package installer so it will end up to make a new folder that will actually match the dummy filename incurring in a system error, and then the failure.
Unfortunately there's no such a "hidden" attribute to files/folders in Android OS.
Removing all the read,write,execute permissions on a file/folder doesn't prevent to list those file/folders along the rest of the directory content.
At this point I only wonder if the package installer might fail because the new folder name it has to make has a "split" number (-1,-2...) that exceed an internal limit.
So, let's say that package installer can handle names till two digits split (-99), what will happen if there's a dummy folder with name com.android.vending-99?
Will the installation fail? or the installer will go further and will make a com.android.vending-100 folder?
How about com.android.vending-999?
Can you try this?
Make dummy folders with name com.android.vending-9, com.android.vending-99,com.android.vending-999,com.android.vending-9999,com.android.vending-99999,com.android.vending-999999 and see what will happen once again
Dear all,
I have been using RMN5 for a while and this is the most f**cking annoying error in this phone (or MIUI's error - i got it in my LG F180L running MIUI7 a long time ago and it happened too)
Every time i connected the phone to PC, i got this problem, I've followed the tips on XDA about disable media storage and download (force stop only in RMN5) and reboot, ok it fixed for a while, but not for long, next time i connect, it happen AGAIN.
I'm so tired of this sh*t and want to get rid of it.
Please, somebody please show me the way.
Thank you
Don't disable those apps instead go to the app settings media storage and download and clear both cache and data, hopes this will solve the problem and move this post to question and answer thread. It belongs there.
you disabled critical system app and complained why you get error messages
This is the Android Media Scanner, looking for files to index on your storage.
Some options are:
Try creating a file called '.nomedia' in every folder, and the problem should dissapear. In that case you may have a corrupted file somewhere, so try to delete the .nomedia file in some of the suspected folders to see if the problem comes back (or google something like 'android.process.media .nomedia' for a better explanation or solution.
You can also enable debuggind (via developer options), to inspect the problem with adb logcat, or to install a logcat related app from Play Store, in case the dump that should appear at the time of the error contains some hint.
rgawenda said:
This is the Android Media Scanner, looking for files to index on your storage.
Some options are:
Try creating a file called '.nomedia' in every folder, and the problem should dissapear. In that case you may have a corrupted file somewhere, so try to delete the .nomedia file in some of the suspected folders to see if the problem comes back (or google something like 'android.process.media .nomedia' for a better explanation or solution.
You can also enable debuggind (via developer options), to inspect the problem with adb logcat, or to install a logcat related app from Play Store, in case the dump that should appear at the time of the error contains some hint.
Click to expand...
Click to collapse
I'm having this issue after updating my Samsung GT-N8013 to lineageos 16.0. When you say to put a .nomedia file in every folder, do you litterally mean every single folder on both the tablet and sd card or a certain level of folder?
tcfulmer said:
I'm having this issue after updating my Samsung GT-N8013 to lineageos 16.0. When you say to put a .nomedia file in every folder, do you litterally mean every single folder on both the tablet and sd card or a certain level of folder?
Click to expand...
Click to collapse
The .nomedia flag file will stop the scan in the directory it's placed and all of the directories contained in it.
I ended up reinstalling the the OS 16.0 rom for my Samsung N8013. It took a total of running the installation 3 times but it finally became stable.