Related
At the android-platform group, we've been hashing out a scheme for adding in official apps-to-sd support to AOSP. We have a couple of google engineers following along/helping out and are now at a state where the initial testing implementation (we're using an incremental development approach) steps are defined in a fairly simple manner and we are ready to start at it from an actual implementation details/start coding perspective.
The actual thread is located here: http://groups.google.com/group/android-platform/browse_thread/thread/bf0709c157451cd9
Basically, if implemented, it will do the following;
1) totally obsolete current hacker apps2sd approaches by allowing actual sdcard removal from device.
2) ultimately ship with devices stock (when in a state where it is easy to use, stable, and at least as secure for non-root users as internal storage currently is).
3) keep application data on the same device as the actual application with no side-effects (like internal apps being broken while waiting for second partition to mount).
4) allow MULTIPLE sdcards containing apps to be swapped on the same device.
5) allow sdcard containing apps to be swapped between DIFFERENT devices.
Note: 4 and 5 are not in the initial implementation, first proof of concept and working system, then enhancement with additional features. 4 and 5 are not requirements for inclusion in AOSP, but they are cool features that ultimately should be implemented.
What we need:
Several good developers, web storage w/source/patch management, etc.
Anyone interested, please read the thread to get an idea of the current state of thought, and please don't pollute that thread with nonsense. There is a current state of organization, and though not set in stone, it should be considered as NOT open for major architectural changes (i.e., the google engineers don't have any major problems with the proposal that we can't work through). Minor glitches and implementation details will be handled along the way. If you must pollute a thread with nonsense, use this one.
Really? Nobody AT ALL is interested?
This is the *ONE* major feature missing from AOSP!
Id PM twistedumbrella and cyanogen and shafty
JAC would prolly be interested but hes been busy with personal stuff i guess?
Just keep bumping this thread to keep it at the top. this needs to be done, and is long overdue on android...
It's a must
I'm sorry that I'm not a developer. Good speed!
I really don't think a2sd is a good solution at all (I've been following the discussion at android groups), rather, I believe the lack of an a2sd solution will eventually lead to device manufacturers to increase the amount of internal storage available on the device for applications (this is what this project is all about, isn't it, not enough storage for apps?) like Samsung did with it's Galaxy.
We shouldn't assume that a device is going to be used a particular way because then we'll run into problems. We shouldn't assume that an user will want to have their device used that particular way, be it partitioned or with a custom, secure filesystem stored in the SD. How do we explain that they'll lose some of their sdcard to app storage? If we make it automatic, how do we allow the user to disable it if they do not want it? How do we make it if an user wants to have one SD card with apps on it and another one without them?
Again I believe we should let the demand for more storage drive the evolution for the next android devices instead of just making it work and have manufacturers ignore the real need for increased internal storage.
I disagree with it not being a good solution. Technology is always advancing, but people can't always follow suit with what is the latest. Be it financials or whatever, Having this as an option will allow older hardware to run more efficiently, Bring costs down for manufacturers and give everyone more options.
@Jubeh, All the questions you raised I believe could be addressed, Have a new settings menu and let them choose. If they select it, it will give it pop up saying "x amount of space will be reserved on your SD card for app storage".
And with AOSP, Android is not just a mobile phone os anymore, It is a mobile platform. Imagine if you buy and download apps on your phone, You save them to your SD card because of this suggested add-in. Now you also own a media tablet that runs android, For example something with a bigger screen usually used for movies and gaming, Now if we had this you could put your sd card in that device and have all your apps like that. I think that would be an amazing feature for android.
I can think of big issues being encryption, piracy seems like it would be easy to accomplish with something like this, but again this should still be addressed and at least attempted to make available. It would be a huge step for the android platform. My 2 and a 1/2 cents worth
I dont think its a bad idea at all...
Jubeh while i agree with your ideas, we definitely need to get more on board memory. But things like apps, and even most cache's shouldnt hinder or take up precious phone storage. I mean seriously, are we hoping for gigs in the near future? Probably not, lol. But the apps2sd is something we can and should change now, to help bring on future ideas.
And what about those already locked into their devices, or where purchasing a newer improved version isnt feasable? Its hard to rationalize a new smart phone every year, even though we all do it, lol. But some bought the g1 hoping to not have to purchase a new device for multiple years, dont they deserve some kind of back compatablity as well?
Whether it should or should not be implemented is not open to debate. The objective is to actually IMPLEMENT it -- in a manner that meets the stability and security requirements of AOSP. One way or another, community needs WILL implement this system, problem is that the current implementations are just crazy HACKS --- unstable, unreliable, etc. As someone who WILL be installing applications to sdcard, *I* want the system to actually WORK PROPERLY, and I'm sure that not only most everyone else (with VERY VERY few exceptions...) does.
Also, the fact that anyone (jubeh) would bring up those completely retarded points about "assumptions regarding use cases" proves in no uncertain terms that they didn't read the thread linked to (even if they did make themselves look completely retarded by replying in it).
In other words jubeh: If you don't read before you reply, you will make yourself look like an a$$. Now run along.
Oh, and what did I say about keeping the NONSENSE out of that thread? Really... you need to learn to READ.
lbcoder, I have to hand it to you. You killed your project quicker than anybody else possibly could have. While many users wouldn't necessarily agree with what jubeh said, he was raising what he considered were valid points in a fairly reasonable manner. Instead of pointing out that you had already worked on those points and that you didn't want to rehash them, you trashed him (three times) and made it pretty clear that you would be an a$$ to work with. I wish you luck in finding devs who want to put up with that.
I think either member have the right to say what they please.
While lbcoder was a bit harsh, I can understand his frustration.
They're both senior members however, and have both have contributed MASS amounts to the comunity. If they want to hash out a problem so be it.
All its doing is keeping this thread at the top
sykokenndogg said:
I think either member have the right to say what they please.
While lbcoder was a bit harsh, I can understand his frustration.
They're both senior members however, and have both have contributed MASS amounts to the comunity. If they want to hash out a problem so be it.
All its doing is keeping this thread at the top
Click to expand...
Click to collapse
i agree. this should DEFINITELY stay at the top non-rooted g1 users at the very least should have these a2sd AOSP updates... and everyone else can just get the regular updates because they have enough internal memory
lbcoder said:
the current implementations are just crazy HACKS --- unstable, unreliable, etc.
Click to expand...
Click to collapse
Not to fill this thread with more nonsense but I have to disagree with you on saying the current apps2sds are just crazy hacks. Hacks? yes. Crazy, unstable, and unreliable? No. The new roms that are out currently automatically move your apps to your ext partition on startup if the ext partition is there. If not then the apps will not move there. The fact that you can dual mount your sd now also illiminates any FCs while you have the phone mounted to a pc. I am not saying that the method can not improve but anyone that is currently running an Enom or Cyan rom can tell you if you didnt personally create the partition then you would have no idea that the apps were on the sd.
Agreed, A2SD is stable
If you follow the directions, Apps2SD is more stable than most of the apps on it, imho.
I think the problem that people are having with stability involve the several ways to get there, the fact that each is a multi-step process, and Android users seem to run the gamut from someone who could hack into Sun Microsystem's payroll to someone who just got their first ,uh, smartphone. Most of us tend toward the latter. If you wrest the control from the user and automate it, then I think we'd see the last of A2SD instability.
Internal memory isn't just for apps, and I think it'll grow regardless. People like high numbers on boxes. WM (WP?) has had this since pre-turn of the century, and the demand for more phone memory hasn't decreased. As a matter of fact, the ROMs just grew, and grew, and grew.
Hey, it's cheaper, it's pretty much just as fast, and if it's easy, people will be able to figure out what the different partitions are once they get them and have to manage them, so it'll teach the masses. I'm all for it. Can't code for diddly, but I like the idea.
Yeah. Bump.
Edit: Yes, you will catch more flies with honey. In the friendliest way I can say it, lose the 'tude, or you'll lose out on a lot, lot, lot of other stuff, and you likely won't be able to figure out why things aren't working out for you. You can't really look back and say what might've been, either. You can, and please do, still say what you need to say, maybe even more, but *how* you say it really matters.
a2sd is FAR from being a stable, reliable, sane solution to the device's storage problem, I've said it time and time again.
Being "Senior Member" is in no way a measure of reliability, experience, or knowledge. I could fill 10,000 posts with 4/5ths of them being "Reported 10 chars" and be a senior member. Also, although I've tried to help where I can, I don't think I've yet contributed anything significant, mainly to avoid the barrage of posts afterwards asking how to make it work... and that brings me back to topic; the storage of apps on SD-card would be hell for carrier's support lines. The implementation is mostly non-existent in MASS MARKET headsets, and although you're right to point out that Android is making strides beyond the phone market, I believe the implementation would be shunned by google for several reasons; the formerly mentioned carrier support hell, both carriers and manufacturer's desire for handsets to become obsolete, google's desire to keep android appealing to both carriers and manufacturers, and possible competition in the thin-portable client and netbook spaces against it's own upcoming Chrome OS.
At this point already, the hope that the feature will "2) ultimately ship with devices stock" is pretty, pretty slim.
As opposed to what most members here might think, we're in the minority (rooted Dream users), and although a2sd does cater to some rooted users, we're still talking about the minority of Dream devices out there (since really, it seems the only reason behind implementing a2sd is the Dream's stock 70 MB app storage space, most other devices at least double that amount). Normal people (read: not us geeks) change devices often almost as a fashion statement, so any solution, if it did make it as an update, would be to support the desire of a small fraction of an almost obsolete device.
Besides, even starting with the way apps are currently handled by the device, it would require a major re-working of the platform to get this monstrosity working. Currently, apps are handled in two spaces, system apps, which can't be un-installed, and user apps, which can be un-installed, updated, etc, but not by the user, but by the package-manager. A better solution would be a third app space for sd-card installed apps. The system/package manager would not install these apks downloaded directly to the sd-card's fat32, rather, they would just show up on the app launcher (we could have scans for new apps every time an sd-card was inserted/removed). With donut's on-demand dexopting, we could create another directory in /data, say, /sd-dalvik-cache, or even leave the .dex in the sdcard while the app was in use and remove it when the app stops (and clear any .dex on sd-card mount), and create a third category of apps that could be installed to sd (in lieu of it, apps would get thrown into /data/app and moved back to sd as soon as one was available, of course, after prompting the user). This way, developers would be able to choose for their apps to be installed to SD and they could take the appropriate security measures to ensure the safety of their code, if that's what they want.
A2SD should have been an option for android in first place. Windows mobile has it, why not android? Is it stable and usable the way it is - sure. But what happens if I want to take out my sdcard and put it in a card reader?
It's one of the major failures of android along with it not supporting adhoc
networks, bluetooth obex as default and some other significant issues.
Don't get me wrong here - there are many things I love abut the platform but
flaws are there too. I've had winmo standart, winmo pro and now an android phone and in terms of "getting the job done" all three have their + and -.
The *current* mechanism to install applications on SD is an EXTREMELY hacky piece of junk.
Though it will work, it will only do so under the following conditions;
1) the user is fully aware of the limitations of the system and doesn't do anything that will stress it out,
2) the sdcard is *always* in the device, never removed.
3) it is impossible to use multiple sdcards in the same device.
Let me pose this question to everyone;
WHAT HAPPENS if you are using hack-apps2sd and you remove the sdcard? You know, just PULL IT OUT... This is something that "regular" users do *all the time*.
This is only one of many conditions that need to be managed by an apps2sd system before it can be considered for inclusion in a consumer device.
Needs to be done;
1) The user needs to be able to chose whether or not to enable apps-to-sd and must set itself up on the phone itself by just the click of a button.
2) The user must be able to SWAP SDCARDS at will. This includes the case where they just rip the card out without unmounting it.
3) When an sdcard is inserted containing apps, the system must automatically set it up and add those applications to the package manager.
4) UID collisions must NEVER happen.
5) External apps must be able to be sanely removed from the package manager upon unmount (planned or unplanned).
6) Processes with open file handles must be politely shut down upon a planned unmount.
7) Processes with open file handled must be CLEANLY killed off upon an UNPLANNED unmount.
8) PROTECTED-APPS must be copy protected when stored on the sdcard to at least equal security to that used internally, i.e. they should be encrypted using a randomly generated key stored in a root-only location within /data.
9) The user must be able to chose where to install a new application.
10) Application home directory and dalvik-cache must be stored on the same media as the application is installed to, i.e. internally installed apps should have their home directory and dalvik-cache stored internally, externally installed apps should have their home directory and dalvik-cache stored externally.
11) Optional: Ability to grow/shrink the amount of storage on the sdcard devoted to applications.
In other words, the user experience should be like this;
1) With a regular sdcard inserted (or no sdcard inserted), the user experience must not be any different than it is currently.
2) User can go to Settings-->SD card & phone storage-->(SD card) Enable application install to SD card. This prompts the user for how much space to devote to applications (default, say equal to internal), and then sets it up.
2B) optional -- user can go to Settings-->SD card & phone storage-->(SD card) "Change SD card space reserved for applications". Prompts for new size (min size = current space used, max size = current available + total sdcard available).
3) User goes to install a new app, if the card has application storage enabled, the installer asks where to install the application to (internal or sdcard).
4) User safely unmounts sdcard -- if applications are running, prompt "There are applications running on the sdcard (list them), these will be terminated. Continue?", terminates applications, removes them from package manager, unmounts.
5) User unsafely pulls sdcard -- if applications were running, message "These applications were running on the sdcard. They have been terminated and any unsaved data has been lost."
6) User inserts or mounts sdcard, system scans if application install is enabled on the card, if it is, the applications are added to package manager.
discussion management
lbcoder,
The thread at groups.google is definitely the technical thread, so I am using this one to comment on your reply dated Oct 30 2:39 pm.
Hands down I believe that for the sake of keeping the discussion open (one of the pillars of the scientific method) is to allow comments that may or may not agree with your or anyone else's point of view.
I agree on that Armando's idea is wrong, just like you do. Although he does have some valid points, which anyone who reads carefully can see. He is probably out of line writing what he did on the technical thread instead of here; and should be scolded for that. But not for sharing his thoughts. I won't elaborate on my own ideas on the matter this because it is not my purpose with this post.
My purpose is to ask everyone working on both this and the technical thread to tone it down, please. XDA sometimes becomes a battleground, sometimes funny and sometimes wasteful and even annoying and both this and the technical thread at groups.google could be very valuable for the platform.
BTW: I'm a well seasoned developer, with well over 15 yrs of experience and who leads reasonably big projects.
Thanks for the thread. It is well worth it, whatever the outcome is.
fosormic said:
lbcoder,
The thread at groups.google is definitely the technical thread, so I am using this one to comment on your reply dated Oct 30 2:39 pm.
Hands down I believe that for the sake of keeping the discussion open (one of the pillars of the scientific method) is to allow comments that may or may not agree with your or anyone else's point of view.
I agree on that Armando's idea is wrong, just like you do. Although he does have some valid points, which anyone who reads carefully can see. He is probably out of line writing what he did on the technical thread instead of here; and should be scolded for that. But not for sharing his thoughts. I won't elaborate on my own ideas on the matter this because it is not my purpose with this post.
My purpose is to ask everyone working on both this and the technical thread to tone it down, please. XDA sometimes becomes a battleground, sometimes funny and sometimes wasteful and even annoying and both this and the technical thread at groups.google could be very valuable for the platform.
BTW: I'm a well seasoned developer, with well over 15 yrs of experience and who leads reasonably big projects.
Thanks for the thread. It is well worth it, whatever the outcome is.
Click to expand...
Click to collapse
There is no place in this discussion for opinions. Its not about battling, its not about opinions, its not about any of that BS. What I am asking is for anyone INTERESTED in CONTRIBUTING (either in code, or in rational discussion regarding implementation details) to come forward and do so. Everything else is irrelevant and out of place.
As for his having valid points... not relevant since ALL of his valid points have been addressed. His purpose (if he has any at all) is therefore simply to disrupt progress.
And since he has effectively destroyed this thread with his nonsense, I may cease monitoring this thread. Anyone interested in contributing, please contact me by PM. Anyone interested in being disruptive, don't waste your time -- really, just go away.
lbcoder said:
The *current* mechanism to install applications on SD is an EXTREMELY hacky piece of junk.
Though it will work, it will only do so under the following conditions;
1) the user is fully aware of the limitations of the system and doesn't do anything that will stress it out,
2) the sdcard is *always* in the device, never removed.
3) it is impossible to use multiple sdcards in the same device.
Let me pose this question to everyone;
WHAT HAPPENS if you are using hack-apps2sd and you remove the sdcard? You know, just PULL IT OUT... This is something that "regular" users do *all the time*.
This is only one of many conditions that need to be managed by an apps2sd system before it can be considered for inclusion in a consumer device.
Needs to be done;
1) The user needs to be able to chose whether or not to enable apps-to-sd and must set itself up on the phone itself by just the click of a button.
2) The user must be able to SWAP SDCARDS at will. This includes the case where they just rip the card out without unmounting it.
3) When an sdcard is inserted containing apps, the system must automatically set it up and add those applications to the package manager.
4) UID collisions must NEVER happen.
5) External apps must be able to be sanely removed from the package manager upon unmount (planned or unplanned).
6) Processes with open file handles must be politely shut down upon a planned unmount.
7) Processes with open file handled must be CLEANLY killed off upon an UNPLANNED unmount.
8) PROTECTED-APPS must be copy protected when stored on the sdcard to at least equal security to that used internally, i.e. they should be encrypted using a randomly generated key stored in a root-only location within /data.
9) The user must be able to chose where to install a new application.
10) Application home directory and dalvik-cache must be stored on the same media as the application is installed to, i.e. internally installed apps should have their home directory and dalvik-cache stored internally, externally installed apps should have their home directory and dalvik-cache stored externally.
11) Optional: Ability to grow/shrink the amount of storage on the sdcard devoted to applications.
In other words, the user experience should be like this;
1) With a regular sdcard inserted (or no sdcard inserted), the user experience must not be any different than it is currently.
2) User can go to Settings-->SD card & phone storage-->(SD card) Enable application install to SD card. This prompts the user for how much space to devote to applications (default, say equal to internal), and then sets it up.
2B) optional -- user can go to Settings-->SD card & phone storage-->(SD card) "Change SD card space reserved for applications". Prompts for new size (min size = current space used, max size = current available + total sdcard available).
3) User goes to install a new app, if the card has application storage enabled, the installer asks where to install the application to (internal or sdcard).
4) User safely unmounts sdcard -- if applications are running, prompt "There are applications running on the sdcard (list them), these will be terminated. Continue?", terminates applications, removes them from package manager, unmounts.
5) User unsafely pulls sdcard -- if applications were running, message "These applications were running on the sdcard. They have been terminated and any unsaved data has been lost."
6) User inserts or mounts sdcard, system scans if application install is enabled on the card, if it is, the applications are added to package manager.
Click to expand...
Click to collapse
well the extremely hacky piece of junk took a lot of hard work from the developers here......show some respect
This has been bothering me for quite a while, so I conjured a little story to help sooth my frustration.
Lets say my Android device is the new tenant of a nicely formated loft, this loft being 16gb of square space. To commemorate this new exciting space my device throws a house party. Most of the Apps he invites are pretty well behaved, but some start spilling drinks, then puking on the carpet, then having an orgy, then bukkake-ing the root directory. After discovering such acts, the device politely requests the disruptive guests force quit and leave. "I need more space on my phone." the device replied as each questioned on their way out. To his disbelief, NONE of the Apps cleaned up their mess! Even worse it seems some of the classier Apps, though more organized seem to have been influenced too. Unfortunately the device is forced to live with it, as the police force stopped responding to calls in his neighborhood. One man tries, but it always returns to a mess.
I hope that entertained someone.
i know exactly how you feel... there is at least 7 unused folders just wasting space on my phone. not to mention random mp3's hidden deep within my phone...
PhxkinMassacre said:
i know exactly how you feel... there is at least 7 unused folders just wasting space on my phone. not to mention random mp3's hidden deep within my phone...
Click to expand...
Click to collapse
I hope you understand about the unused folders and NOT the bukkake-ing!!
hello, nice story!
I won't say that I am even close to being a developer but I do develop some apps and the thing that I wan't to point out is that apps do not run when they are installed or uninstalled. It's not each application job to clear up the mess it may have created but package manager's which apparently leaves some files be just in case you would like to reinstall the app later(?)...
I would propose to look for a more efficient package manager or doorman/janitor for your loft
That's why I don't invite the guy whos only existence is to make farting noises!
Very good point. However, one thing I don't know is if uninstalling through the market cleans up the SD card better than using a third party mass uninstall app. Something you may want to experiment with.
Back at it again...
Here I am again, and I still don't flippin get it!
After reading some of your comments I realized my main point kind of got glazed over(no pun intended @Scudderb)
My big issue is that there's no hierarchy in place for this crap. In windows, program files are stored in the 'Program Files' directory. In Android (and I credit google and the developers for this sloppy BS) Apps are just throwing all their **** in with my stuff on the ROOT.
How is this acceptable. Seriously, HOW? And if its all cache files and/or temporary documents than WHY THE **** ISN'T ALL THIS CRAP BEING PUT INTO A TEMP/CACHE FOLDER.
I'm PISSED! Why does every app I install get to put their own folder on the ROOT WITH the FOLDERS and FILES that actually matter to me ex: like my music, pictures, movies, documents (OH and by the way, a lot of apps developers do a REALLY ****ty job with their NAMING CONVENTIONS so the folders being created may or may not even look related to the app that put it there!)
::end rant::
My apologies for the colorful language, folder structure and hierarchy are something I design as a web designer so when I see this crap going on in my phone like the inmates are running the asylum... I get angry.
Today I was cleaning up my SD card for the umteen'th time, and found that Foursquare was dumping its temp files directly onto the root of my directory. I blew my top and had to get it out of my system... so..
A MESSAGE TO ALL THE APPS PULLING THESE SHENANIGANS: GROW UP!
The problem here is that it's hard to do it right
For custom data, files are supposed to be saved into "/data/data/com.appname/blah" (that's from the top of my head, could differ slightly). That's the directory to use for data files, but there's one big issue with it: it's on the internal memory storage. We all know that internal memory on Android (without custom ROMs) is.. limited. That's probably why most devs are using SD for larger files.
There's also the "Android/data/com.package_name.blah/blah" directory on the SD card. This directory should be used by apps to store files into and is automatically deleted when the user removes the associated app (but only when you're running Froyo or greater).
The issue with this approach is that users (and developers too, when testing the app) will lose all their data when removing an old version of a specific app. Let's say there's a bug with the Market again and the app suddenly gets uninstalled. User will have to reinstall, result: data will be all gone. That's only one of the many doom scenarios.
I can't speak for other developers, but that's more or less the reason why I started to use a common directory outside of the preferred ones when I was doing apps. It's not a great situation, I fully agree. But would you rather have your data accidentally deleted?
If anyone knows a good way to get around this issue, I'd love to know more about it...
orly
Thanks for the reply @Stripeymilk
I can think of multiple solutions:
#1 Development community adopts a universal directory for files deemed 'User' or 'Save' data that should be stored for future use. (or Google creates this for developers)
#2 Development community adopts the practice of allowing users to pick the directory users want to store an apps data in. (prompt at app's first start)
#3 Store files/data in the cloud.
#4 Users dump trash in the lobbys/living-rooms of developer's and see how quickly they find a solution.
#5 USE THE "Android/data/com.package_name.blah/" FOLDER WHEN ALL YOU'RE REALLY DOING IS STORING CACHE/TEMP FILES!!!
BOTTOM LINE: Its not hard to do it right, Its just hard to get people to do it.
You make it sound so easy
1) I'm all for it, but Google needs to put its weight behind an approach like that because otherwise people will say "I like /Data better than /data or /Mydata or /MyData". It's a bit like coding conventions: everyone wants to be different.
2) Good for techy people, not so good for "normal" users. Could make it easier with a small "file manager", but that's too much work for indie devs. Could be a nice idea for a new open source project though.
3) Great idea, could actually work if the associated account would be created automatically (like in Cut the Rope for Android with Scoreloop), but:
- The backup functionality in Android for storing data in the cloud is available for API level 8 and greater, making it of not so much use when you're targeting API level 5 or 6 and greater. Could be fixed by using something like Google Storage combined with Jets3t instead, but that would be useless for apps written in C++, like many games are.
- Cloud storage isn't free. Developers can't pay for that as it would be too expensive. If every Android user would've gotten free cloud storage from Google it could be a nice alternative, but (yeah, there's always a but) most current users don't have that.
4) If you're prepared to send your trash by plane to another country, go for it!
5) Agreed. Useful for temp data.
I'm not trying to make it sound easy, believe me I know how it isn't. I'm trying to make it sound simple, because really.. it is...
In response:
1) I agree and this is exactly what I mean by the real hard part is getting people to do it. This requires widespread endorsement by developers big and small - that this is a 'best practice' that should be adhered to. I think the gate swings both ways though.
example: Twitter didn't invent hash tags, their users did, and with its widespread adoption, Twitter adopted/implemented it too.
2) Another good point, though this process can be curated to drive the user in the right direction (holding their hand). The XBOX 360 does this for every game you play, the first thing it does is ask you which storage device you want to use for game saves.
example: in combination with solution # 1, the default folder the app saves to could be '/data/theAppsName' and the prompt could say "This app saves files to your SD CARD in '/data/theAppName'. Would you like to choose a new location?" [Yes] [No] [?]. The [Yes] option brings up a simple file manager, the [No] option uses that location, the [?] option brings up an easy to understand write up on what its asking and why its asking it.
3) We'll get there eventually, my point really was if you've got the resources, why not. Its a solution better than #1 and #2
4) I plan on sending human clones to create trash individually and exponentially
5) AMIRITE~!
In all seriousness though, thank you @Stripeymilk for taking the time to go in depth and have a conversation about this. I seriously think it doesn't take an act of Godogle to solve this (to what I beleive) is a big issue!
I can't agree more with you.
As developer (Windows, iSeries) I try to make my programs as structured and readable as possible. The same goes for the files and folders used used by the programs, but sadly, even with all the available resources, some people (colleagues) make a complete mess of it, cause "that's not/less important", as long as the program does what it's intended to do ...
It's all about the resources and people using them the right way!
Cool, didn't know about the hash tags on Twitter
Well, we're on a great site here with developers on it. If everyone here would adhere to the same standard, it could at least be a nice push to make the Android SD card world a better place.
What's the directory we're going to settle on? Any pros and cons?
Hi!
Yeah, yeah, I know, I know, I'm a noob... Well, sort of actually coz even if it's my first public message I've been roaming this forum for quite a while. And thanks to you guys I understood how to root, how to flash a CD Rom and so on. Without disturbing anyone, ain't it nice?:good:
But now I have a question, I couldn't find the answer anywhere on the web hence this post.
I'm rooted on both my Galaxy Mini and my Galaxy Tab P6210 and I noticed that some apks leave files like webview.db, googlestats etc. on the data/data/whateverapk/databases folders.
On the Mini I found how to prevent those annoying files from polluting my system(yep, I don't like cookies and similar spying stuff) by changing the databases folder's perms to --x --- ---, or even sometimes -- --- ---. For the most stubborn apks I rwx --- --- the databases folder, then I erase all the text in the unwanted file and finally I lock the file's perms to --- --- ---. It works with most apks including Dolphin Mini and Opera Mini, cool. Only one or two resist and FC if I attempt to modify too much the perms but it's OK, I don't use then that often and I don't mind to delete the trash manually.
The problem is that on the Galaxy Tab it doesn't work on most apks, it makes them FC. I've tried all the possible perms combinations but nope, FC.
I guess, since the concerned apks are the same on my Mini and on my Tab, that it has to do with the OS, Gingerbread for the Mini, Honeycomb for the Tab. I noticed as well that some of the files on the Tab are different, on the Mini it's mostly googleanalytics.db, webview.db and webviewCache.db files, whereas on the Tab I have, apart from the above mentioned ones, some webview.db-shm, webview.db-wal, webcookieschromium.db and webcookieschromiumprivate.db files.
I guess .db has something to do with dropbox, but I don't use any dropbox, and I even deleted the (empty by the way) folder in my system. When I open those files I can see that they have something to do as well with sqlite, but I don't have any built in sqlite. I have one that has been installed by an apk in the /xbin folder but I erased it and it didn't change anything (don't worry, I put the sqlite back afterwards). It's very annoying, those files spy on us guys, they record all the web sites we visited, the email(s) or facebook accounts we use etc.
For now I have put bookmarks on my home screen and I delete manually the troublesome files just after I opened the relevant apk but hey, it's not very convenient!
Anyone knows how I can prevent them from coming back everytime I use an apk?
Thanks a lot for your help, and sorry for the long post:angel:
Already 3 days and over 50 views but no answer yet, what's wrong?
Is it that my question is of absolute no interest?
Or that the way I explained my problem was not clear?
Or that no one knows how to do it?
Or a bit of the 3?
It seems that you want to remove unnecessary garbage files that have been left out by some applications. I recommend that you use SD Maid, free is good enough, but of course PRO is better.
Anyway, SD Maid can clean File Corpses and clean the system files like the ff:
/data/log
/data/tombstones
/data/system/dropbox
/cache
Temporary Files
Log Files
Gallery Thumbnails(This one can really build up even with just the same files. I'm not exactly sure as to why it adds again and again but it saves me a lot. Like 300~600MB)
Empty Directories
LOST.DIR Directories
It can also optimize DBs. All of these are available on the free version.
As for cookies in browser, you can uncheck "accept cookies" but this might cause some websites to malfunction or not work.
Other things like cache you can use History Eraser, One Tap Cleaner and etc.
Hope I helped.
I think most don't want to delete them because they are normal caches and cookies, also some apps' settings are stored on those database files. I don't see any advantages in deleting those files (apart from saving couple of MBs storage space...) They aren't any "bad" or "spying" files.
By the way, the .db means database, not dropbox.
Sent from my GT-P6210
miksumortti said:
I think most don't want to delete them because they are normal caches and cookies, also some apps' settings are stored on those database files. I don't see any advantages in deleting those files (apart from saving couple of MBs storage space...) They aren't any "bad" or "spying" files.
By the way, the .db means database, not dropbox.
Sent from my GT-P6210
Click to expand...
Click to collapse
Correct me If I'm wrong but it is necessary to clean caches and cookies once in a while because it can hog the device. Sometimes old caches are stored even if they are of no use anymore. It's like the principle of filling up your internal storage too much that you can see a dramatic decrease in performance. These kind of files updates a lot and does not seem to overwrite existing files or at least delete those that are unnecessary. It is not needed however to clean it every after use. Just once or twice a week is good enough.
Thanks for your answer but it's not what I was meaning, let me explain more clearly.
Take any app, say a mp3 cutter. It doesn t need any internet connection to work but when one downloads it one sees that it requires internet access permission. One thinks it s ok and one downloads it. But then in the mp3 cutter databases one finds those webview.db files, and this is why I say that it spies on us coz why this mp3 cutter needs such databases? The same with offline dictionaries, or one tap cleaner (a very bad one by the way, put it through privacy blocker and you ll be amazed of all the infos it takes from you), or mp3 players etc. On browsers like dolphin it s the same story, and when one views those files one sees that they record all the sites one has been through although the apk doesn t need it (I know it for sure coz I delete the files before my browsing cession and it still works). Disabling the cookies doesn t help, it just prevents you from accessing web sites that need cookies like gmail, yahoo and the like. Apps like LBE or privacy blocker show partly what those apks do in our back, taking our IMEI number, our contacts, reading our sms and sending everything to who knows where and for who knows what purpose. But they don t show the databases leaks...
As I said in my first post another parameter is that for a same apk, with the same version, let s say dolphin 2.3, on my Galaxy Mini running GB I managed to block the perms and thus to prevent those files to pollute my system but on my Tab running HC it doesn t work and FC the apks. Plus the files are not the same, there are more of them and with different extensions on HC (again using the same apk on both GB and HC).
So the answer lies somewhere in the OS but I couldn t find where due to my limited knowledge and that s why I m here
Any hint or idea on how to eradicate those files from their source? Of course one can delete them manually and that s what I do but it would be so nice not to have to do it all the time. It s not about saving space, those files weight next to nothing, it s about privacy.
By the way I deleted most google apks and this is already a big relief. Other setting I did include blocking all the perms of the usagestats folder, of the throttle folder (well I just left r--, ---, --- otherwise it bootloops). Download testlogging and you will see for exemple of many spying stuff the google apks put on your tablet...
Anyway, back to the topic:
how can I permanently block those files? Many people on this forum and elsewhere are very concerned with their privacy, to the extend that some create privacy watching apks, but to my knowledge nobody ever bothered about those databases files although they represent a big privacy hole in our systems...
Thanks a lot for your help!
Send from my barebone Galaxy Tab P6210, 34 system apks left and counting down
Apart for some real serious stuff, apps need some way to persist information. If you prevent them to, you should expect fc when they try, no?
That's too much paranoia for me.
Enviado de meu MB525 usando o Tapatalk 2
Graffiti Exploit said:
Correct me If I'm wrong but it is necessary to clean caches and cookies once in a while because it can hog the device. Sometimes old caches are stored even if they are of no use anymore. It's like the principle of filling up your internal storage too much that you can see a dramatic decrease in performance. These kind of files updates a lot and does not seem to overwrite existing files or at least delete those that are unnecessary. It is not needed however to clean it every after use. Just once or twice a week is good enough.
Click to expand...
Click to collapse
Yes, the caches can get bloated if the app doesn't remove unnecessary things automatically. In that case a clean is ok.
Sent from my GT-P6210
@unclefab
If the mp3 cutter that you mentioned in your example has ads it needs the internet permission for them, and some ad providers make the database files automatically. They just contain some ad web address cache and only "personal" information saved is your language setting, at least from my experience.
And blocking the apps saving the information doesn't help with privacy really much because they can still access the info, they just can't save it in the databases. A malicious app can send the info without saving it too.
Sent from my GT-P6210
leodfs said:
Apart for some real serious stuff, apps need some way to persist information. If you prevent them to, you should expect fc when they try, no?
That's too much paranoia for me.
Enviado de meu MB525 usando o Tapatalk 2
Click to expand...
Click to collapse
I have to agree with this one. Messing up with permissions can cause issues to certain applications and it really seems that he is paranoid.
If your concerned about such privacy, you shouldn't download the app on the first place. Although some developers get rid of such permissions because of some people's concern, this is unlikely to happen to every application. HC is a different platform from Gingerbread and so such issues that you have mentioned may occur.
Have you tried firewalls like DroidWall? I'm not sure if it really works, but it might lessen your burden from manually deleting files or privacy concerns like your data being accessed/used. Again, not sure.
Don t worry, I m not paranoid, my Tab is well protected, I have rather intricated settings between Privacy Blocker, LBE (by the way and FYI, LBE conflicts with Droidwall, both can t work together) Rom Tool Box, Logging Test and Permissions denied, so I don t think that any apk can steal any info from me!!!
Actually it s more a matter of principle, why apks like let s say Dolphin or Opera record all the sites I ve surfed, eventhough they don t need to do so (coz they still work after I deleted those files manually). And about the exemple given above, why apks which don t display adds need to have an internet permission and to put such webview.db files in the databases? Of course I m not obliged to download them, and actually I ve already erased many such apks, but for some I don t have any choice, specially for dictionaries (I travel a lot and need such stuff).
Plus it s a matter of curiosity, where the heck lies the source of those files? And why can I block those files easily on GB but not on HC? Yes, it s because the OS is different, I know, but how does it work? I don t know so much about Android OS but I like it and I want to learn more.
So back to the question, how can I tweak my system in order to prevent those files from appearing everytime use an apk? There are enough experts on thsi forum so hopefully someone knows the answer.
And BTW, when I see the difference between GB and HC, I mean more spying from the Google/Android OS, then I feel less eager to upgrade to ICS coz for sure it will get even worse, not to mention JB...
You're not saving passwords in your browsers/webview-based-apps, right?...
Do you mind explaining why webview.db databases have you concerned?
Thanks.
They are saving information from him, that's why. Nothing can save his information, I think that is the point.
Dude relax, there are spy apps, there loggers, but you are blacklisting all webview based ones.
And as some guy told before, if they want to spy you, they don't need to save anything.
But seriously, you don't need to study much on Android OS to known why what you are doing are causing fc. Take any app in any platform that have internal Conf and db files. Corrupt them and mess with permissions, you should get something similar.
Enviado de meu MB525 usando o Tapatalk 2
Thank you for explaining me why they Fc but I had understood it by myself from the very begining, I m what you call a noob but I m not brain dead:silly:
All what I want to know is what generates those files in the OS, and how to prevent it from happening, provided that it s possible.
Apart from that it s ok for me if other people don t mind having files in their databases which record their web activity, and if they don t feel uneasy to know that the more advanced the Android OS the more files there is and the more difficult it is to block them (I said already 2 times that on Ginger Bread I block all those files and that the apks don t FC, which prove that the files are not required by the apks to work normally).
Thanks
I am not calling you noob buddy, but you were trying to solve a problem with no elegance at all.
Contact developers and ask why they are using webview and that you are not comfortable with files it creates. But if you use a program that uses it you have to accept those files, simple.
A lot of details of stuff like webview are API specific so changes version to version. So access of those files may changes on each version of android, as well as file location, name or how to handle errors. So the fact that what you did worked on gb, helps you with no conclusions.
Enviado de meu MB525 usando o Tapatalk 2
I didn t mean thay you (tu) called me a noob but that you in general (vos) call newbies noobs. Sorry for the misunderstanding, it s one of the many limitations of english compated to latin or germanic languages
So it sounds like what I was asking about is impossible to do, well, well, I will see what I can do with apktool, maybe I can change something in the manifest or ressources or I don t know where. Just for info, here s what s insideone of those files when it s newly created and before it starts spying:
SQLite format 3@
-� g
�� �k �6 � ` � ��" �tablepasswordpassword CREATE TABLE password (_id INTEGER PRIMARY KEY, host TEXT, username TEXT, password TEXT, UNIQUE (host, username) ON CONFLICT REPLACE)/
C indexsqlite_autoindex_password_1password �+ �)tablehttpauthhttpauth CREATE TABLE httpauth (_id INTEGER PRIMARY KEY, host TEXT, realm TEXT, username TEXT, password TEXT, UNIQUE (host, realm) ON CONFLICT REPLACE)/C indexsqlite_autoindex_httpauth_1httpauth
�" �tableformdataformdataCREATE TABLE formdata (_id INTEGER PRIMARY KEY, urlid INTEGER, name TEXT, value TEXT, UNIQUE (urlid, name, value) ON CONFLICT IGNORE)/C indexsqlite_autoindex_formdata_1formdataR}tableformurlformurlCREATE TABLE formurl (_id INTEGER PRIMARY KEY, url TEXT)J%cindexcookiesIndexcookiesCREATE INDEX cookiesIndex ON cookies (path)�� tablecookiescookiesCREATE TABLE cookies (_id INTEGER PRIMARY KEY, name TEXT, value TEXT, domain TEXT, path TEXT, expires INTEGER, secure INTEGER)W--ctableandroid_metadataandroid_metadataCREATE TABLE android_metadata (locale TEXT) ��en_GB
@unclefab
Even if the webview.db has always all the fields it doesn't mean they need to have a value or string. For example the "password" field is almost always emtpy.
Sent from my GT-P6210
A little old, but worth the reading:
forensicsferret.wordpress.com/2010/09/30/android-browser-forensics/
Sent from my GT-P6210 using Tapatalk 2
Why would I use such apks?
I said it already, it s because I need them. I deleted some and replaced them by similar apks more privacy friendly, but for some I don t have any choice. For exemple browser. I managed to lock the perms on opera mini and it still works but you know opera mini, on some sites it doesn t display correctly so I have to use dolphin whose perms can t be locked. Talking about it I will try boat browser, it s not as good as dolphin but if it doesn t have those files it could be a solution...
Same stories with dictionaries. I m a language teacher who lives in asia and I need far eastern languages dictionaries. Try to find a thai english or thai indonesian dictionary which can work without those files... BTW if you are interested I found a good english chinese which works without any .db garbage;-)
Thanks for the links, interesting article, some food for thoughts...
I have previously posted this question in the Samsung S7 Edge section here http://forum.xda-developers.com/s7-edge/help/gc-cc-logs-mozilla-consuming-huge-space-t3397783 but didn't get any response. It is possible that the topic didn't get any attention as it is in the wrong section and I also feared that my problem could be due to malware and some other security bugs.
My problem started when I was suddenly told that my S7 is running out space without any new huge apps being installed. I tracked down the sudden lose of storage space to a folder named "memory-reports" inside the default Download folder. The folder content comprise multiple logfiles with each file sizes averaging 30mbs, and the number of files gradually increase and eventually hogging over 3gigs of storage space. I deleted the entire folder with the logfiles but the folder appeared again with similar logfiles.
after Googling around, I found the description of the logfiles here https://developer.mozilla.org/en-US/...GC_and_CC_logs. it seem to relate to Mozilla Firefox and I doubt this problem is specific to Samsung S7 Edge although this is the phone I am using now and the problem only occurred to me for the first time recently. couldn't find any mention of similar issue anywhere else via Google, but maybe some of you guys are better at digging them up. Seeking some comments, suggestions as to what cause, possible solutions...
NOTE: My phone is NOT rooted. the logfiles are still being generated periodically and have to be deleted to recover the space. deleting them don;t seem to affect the operation of any apps and especially FIREFOX, which is the only connection I can find with mention of those logfiles name with MOZILLA. The problem seem unique to me at the moment as I still couldn't find any reference on Google to them. Any head-up suggestion on possible reason and ways to track down exactly which apps, background process are generating the log files are certainly welcomed.
I am experiencing the same issue on my Motorola Nexus 6.
Thanks for this. I was facing the same problem. I just deleted the files. It didn't seem to hurt firefox. ]
Hi! I'm new in this forum. I have a problem in a tablet that uses a custom rom. After a while using the tablet (some weeks), the applications start to crash due to lowmemory. Trying to find the causes of this problem, I've discovered that the "logs" folder of the tablet have files (created when some applications crashed) over 800 MB sometimes, and the tablet is out of space... Almost all the available space is occupied by these files!
I want to know how I can avoid the creation of these files if they're bigger than 10MB (for example) in this folder or if I can find some solution to this problem.
Important: The problem of applications crashes stops if I empty the logs folder, but what I want to know is how to avoid the creation of the files, because my objective is to made a custom rom for a certain model of tablets that many users are going to use.
Thank you!