Does anyone know where I can view a guide regarding the file structure on the Mini pro? I want to try and understand what everything does. For instance where is browser cache / temporary files stored? Do programs contain many attributes spanning multiples folders or do they just act like a portable app residing in the /system/app folder? Where are emails stored from the email.apk? If anyone knows of a guide I can start with that would be cool.
Its basically the standard linux directory structure. If you search google you'll find plenty of info.
Yes but where are things like temp files stored, browser cache etc?
Related
Hey all, I'm a noob. But I got my NT pretty much where I want it to be. I realize now that the extra space is in the data file system (yeah, I can use the extra gigs). Now, my biggest problem is that my .cbz .cbr files do not have a default program or association. This is a problem because my root accessible comic readers will read to the data folder but when you open up the data folder it says nothing is there. At this point, I just need a comic app that links up .cbz .cbr s as the default program for those file types so that I can open the file from on of my file expolorer programs. Or I need to figure out a way that allows my rooted comic apps to actually go into the data folder. Why won't these programs look into the file system past data?
Now,
I did try the permanence method to link a usrdata file to the mnt/internal file, but while it creates the mnt/internal file it does not fill it in with my files...which sucks (I just folled the instructions and I think it may require the snowball mod). I do like the B&N reader for my epubs, so I don't want to use the snowball mod
And even in snowball could not work, in OP is posted that many apps can still be incompatible
Sent from XDA using one of my Android Toys
I am trying to sync a rostering app between two devices using dropsync.
The .db files that need syncing are in the /data/data/com.blah.blah/databases directory. Using Root explorer I can change the permissions to give full rw permission to others. The two .db files will then upload to the dropsync server.
The problem is that whenever the app is opened and anything modified, the permissions change back to default and thus dropsync can't access the modified .db
Is there anyway to change this or am I wasting my time? what is the 'sticky' box option in RE?
I'm not sure precisely what "sticky" means, but it's not what you want--it doesn't involve persistence or "sticking".
You could try to make the files not owned by the app but set it so the group is the app. Make sure the group can read/write/execute, or whatever it needs. This way, the app can still use the file but won't be able to change its permissions.
Of course, it could see that it doesn't own the file and refuse to run. I'm not sure what sort of checks the program's authors implemented. This also won't work if the file is deleted and created anew--the new file would be owned by the app.
Yeah thanks for that,
I tried the ownership and group swap earlier, and am pretty sure the app re- writes the db.
Don't think is going to work.
cheers
Well its obvious that the app, when opened sets the permissions to the .db files so that they wont be usable by others. The way you describe the problem is more likely to be a file owner problem and not with the permissions. Try to set the app and the files to the same owner and see if that works. You could always make a script that would change the permissions/ownership of the file.
FYI,
The sticky bit is a special part of the permissions mask for a file or directory. When set on a directory, it tells the system to prevent anyone but a containing file's owner from deleting files in that directory. This is handy if you have a directory that's being used by multiple users on a system as scratch space as it prevents people from wiping out others' files.
For files....the behavior isn't defined.
Hope this helps,
- chris
Hey,
I haven't proven this yet but I think I've got a method for securely deleting files on any OS. The reason people need to do "secure delete" rather than simply deleting files is because this only removes the directory to those files, a fact that can be exploited by anyone motivated to see whatever file it is you're trying to trash, Complex programs that can be used do some sort of shuffling to accomplish a more secure delete. This is all necessary until the space is used up again, at which point it can't be storing both the old and the new file.
All you gotta do is:
take any group of files,
copy and paste them repeatedly
keep filling in the free space until there's none
delete copies
jobs done
I'd love to know if and why this isn't true, it does seem too simple. Anyone know how to extract deleted files (to test it)?
Hey,
i read some stuff about SQLite databases to use them within my own application.
so for this point, it should work.
BUT:
for most of my data stuff i need a database that i can directly put into my application. i read on stackoverflow that it's possible to put up to 1,2mb files in the assets folder and then copy them anywhere else to use them.
my question is:
is it possible to acces those databases in the assets folder directly to read from them? there's no need to insert data into this database, it's just a data storage to read from? is it possible? and if it is than how could i do this?
regards,
Sh4itan
so there's no one hre with the answer of my question? or an idea to achieve this?
Hello xda-developers,
I'm trying to figure out the proper way to transfer app data from an Android image disk. I'm very new to this, so I hope I'm not missing something basic.
Situation. I have a .img disk image file obtained from a .vmdk file via a virtualbox conversion , the latter being created by an Android emulator. I'm trying to recover some app data and transfer that to a new, working, .img disk. The emulator works on Android 4.4.2, if that matters.
What I did. I extracted apks and copied app data folders (com.<devname>.<appname>) from/to the /data/data directory. I did that using a file manager (ES file explorer) or via the cp command, as I found in many tutorials and guides. Others suggested to copy those folders to /Android/data instead, so I did try that as well. These procedures were ineffective, because they both messed up with folders and files permissions. Although cp -ar retains folders/files permissions and ownership, that was of no use after the import into the working image. Those operations were performed on Ubuntu 18.04.
The problem (and a workaround). When the apks are installed, a new uid (in the 10000 group) is generated for them. These values are unknown when I import the data folders, hence they are destroyed at phone boot. A log in /data/system/uiderrors.txt confirms this. The only way I could make it work was to install the apk from scratch, open the app so that the new data folders are created with a proper uid, replace those folders with old ones and manually change ownership and permissions accordingly (for every apk). This turned out to be effective but it's a very tedious and error-prone process.
What am I doing wrong? How do ADB push, pull and backup commands manage folders permissions/ownership and app uids? Could they be useful in my situation? If so, how can I use them on a .img file?
Thank you.