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
Update 03/08/11
NotEnoughSpace has finally graduated to the Android Marketplace!
Beta testers can currently get it at its "thank you" price of $0.99.
I will set the regular price in a week so hurry
*** *** *** ***
Note #1: your phone needs to be ROOTED to use this application.
Note #2: so far, only tested on Droid Incredible and HTC Desire.
From the built-in help:
About this application
This application's goal is to help you understand and possibly work around a common vexation of using Android; i.e. these messages:
"not enough space"
"Low on space. Application data space is low."
What is happening?
You've checked your phone's vitals and it appears that it has plenty of space left, both internal storage and SD Card storage. So, what's happening?
Android allows your applications to store their data, primarily, in a dedicated partition whose size happens to be much smaller than even the phone's internal storage space. Generally south of 150 MBs.
This is the partition that fills up so quickly and that Android has been complaining about.
And the help goes on and on so I'll stop here.
The short version
Using this application, you can see which applications use up most of your phone's data space and decide what to do with them.
You can also move the biggest directories to the phone's SD Card.
Additionally, you can use the app to cleanup the Dalvik cache but it's not the app's primary function.
Please, help test it!
I will gladly welcome any constructive criticism; I expect most of it to be along the lines of "The tool is not quite accurate" and that's what I wish to address first.
To create a debug report (these are very important):
Simply select the "Debug" menu and follow the on-screen instructions.
The whole email business is so that you can copy/paste from a desktop client.
The .apk can be downloaded from nexus.zteo.com/projects/beta/
Update 12/04/10
The application should now display correct stats for phones/ROMs that use Busybox. If you have already tested it and it said "NaN" please try it again.
This should be interesting, maybe kinda Android GpartED?
cyansmoker said:
Using this application, you can see which applications use up most of your phone's data space and decide what to do with them.
You can also move the biggest directories to the phone's SD Card.
Click to expand...
Click to collapse
Curious, does this mean you can move and symlink data, or are you talking about Froyo Apps2SD?
teorouge said:
This should be interesting, maybe kinda Android GpartED?
Click to expand...
Click to collapse
Obviously not, he's managing what's there, he's not partitioning anything.. Did you read?
khaytsus said:
Obviously not, he's managing what's there, he's not partitioning anything.. Did you read?
Click to expand...
Click to collapse
Come on, what's the matter dude? I did read, and from what I read I thought whole partition handling was the only thing this app would be missing. Single files is a good start, but making that "kinda GpartED" would be killer. Though I fear you should be in bootloader/recovery to work on those, don't know how Android deals with them (i.e. in Windows you have programs you can change partitions size "on the fly" with). Now that I elaborated more, are you still angry?
This application would be genius. I'm wondering however, will the phone still be able to access that data once it is moved off of the system memory and onto the SD Card? And is it possible to actually partition the /data/data section so that it will use more than the allowed 150mb that it has, like open it up so that instead of it being partitioned to a small amount, it just roams free with the rest of the 748mb or whatever that is in the system memory.
A promising app, thanks.
Navigon, however, doesn't like its data to be moved to SD card. Even after moving it back with the app, it FCs (Android 2.1). I think I have to reinstall. So be careful if you're trying to do the same.
Edit: After reinstalling the .apk (without doing anything with the maps), Navigon works again. The packet installer didn't ask me if I wanted to replace the existing installation (as is otherwise usual in such a case).
Edit2: There seems to be a general problem. The next app I tried was mediaU. It has a large database which I moved (using NES) to the SD card. It also FCed after having moved its database, and restoring to the old location (again using NES) also didn't succeed. No error message during restore, but app still won't run.
Phone: Galaxy 3, Android 2.1 (original ROM).
mizch said:
A promising app, thanks.
Navigon, however, doesn't like its data to be moved to SD card. Even after moving it back with the app, it FCs (Android 2.1). I think I have to reinstall. So be careful if you're trying to do the same.
Edit: After reinstalling the .apk (without doing anything with the maps), Navigon works again. The packet installer didn't ask me if I wanted to replace the existing installation (as is otherwise usual in such a case).
Edit2: There seems to be a general problem. The next app I tried was mediaU. It has a large database which I moved (using NES) to the SD card. It also FCed after having moved its database, and restoring to the old location (again using NES) also didn't succeed. No error message during restore, but app still won't run.
Phone: Galaxy 3, Android 2.1 (original ROM).
Click to expand...
Click to collapse
Tonight I'm gonna try for sure and report back, this does look promising! Did you succeed with some apps?
teorouge said:
Did you succeed with some apps?
Click to expand...
Click to collapse
K9 seemed to work. However, I had to reflash for another reason, and now K9 reports its lib as being in the standard location (reported by NES). For now, I have stopped testing NotEnoughSpace so I can not say more.
mizch said:
K9 seemed to work. However, I had to reflash for another reason, and now K9 reports its lib as being in the standard location (reported by NES). For now, I have stopped testing NotEnoughSpace so I can not say more.
Click to expand...
Click to collapse
eh? K9 has native use of the SD card if you enable it... Why would you use this on it?
Thanks for doing this testing, guys.
I will install these apps and test them myself.
teorouge: you moved the database/ directory, is that it?
mizch: so, you re-installed K9 after reflashing, right?
Everybody: what about the "free space" numbers reported by the app? Do they seem correct to you? I had to use a dedicated algo to compute them, taking block size in account, and I've had reports of fairly surprising discrepancies.
Free space doesn't seem to update after moving, though I see the difference in the Titanium Backup count: tried for a couple of apps (G Earth and well... don't remember!) and it did move everything, free up space on /data and I can still use those apps. Still afraid to move many apps, just moving one at the time and test.
I just tested it out on my Droid 1, which is running CM6.1RC5 (Not sure if thats relevant or not), and it doesnt seem to work very well on my phone. All apps came back as 4KB, at the top it showed this... Total:261.8MB Used:NaNKB Free: 259.1MB Database NaNKB Files: NaNKB Preferences:NaNKB Cache:NaNKB.
Heres the debug report: 1:/dev/block/mtdblock6 268032 224572 43460 84% /data
2:62855 /data/data
3:4096/0/265352
Sorry - never mind; found the info in FAQ.txt after downloading
cyansmoker said:
Note #1: your phone needs to be ROOTED to use this application.
Note #2: so far, only tested on Droid Incredible and HTC Desire.
From the built-in help:
About this application
This application's goal is to help you understand and possibly work around a common vexation of using Android; i.e. these messages:
"not enough space"
"Low on space. Application data space is low."
What is happening?
You've checked your phone's vitals and it appears that it has plenty of space left, both internal storage and SD Card storage. So, what's happening?
Android allows your applications to store their data, primarily, in a dedicated partition whose size happens to be much smaller than even the phone's internal storage space. Generally south of 150 MBs.
This is the partition that fills up so quickly and that Android has been complaining about.
And the help goes on and on so I'll stop here.
The short version
Using this application, you can see which applications use up most of your phone's data space and decide what to do with them.
You can also move the biggest directories to the phone's SD Card.
Additionally, you can use the app to cleanup the Dalvik cache but it's not the app's primary function.
Please, help test it!
I will gladly welcome any constructive criticism; I expect most of it to be along the lines of "The tool is not quite accurate" and that's what I wish to address first.
To create a debug report:
Simply select the "Debug" menu and follow the on-screen instructions.
The whole email business is so that you can copy/paste from a desktop client.
The .apk can be downloaded from nexus.zteo.com/projects/beta/
Click to expand...
Click to collapse
Do you have more details about this program anywhere? I went to the download page but see no further info...
Help Section Typo
Under A Quick user guide in your user guide(?) that prompts when you run the apk for the first time there is a typo in the last sentence:
You can touch any application to explore its content and figure out what is taking up some much space.
Click to expand...
Click to collapse
So far I havent run into any issues with the apk...
Not to burst anyones bubble, but Choose Install Location has been doing this in a comprehensive way for weeks. http://www.appbrain.com/app/choose-install-location-free/com.beidl.chooseloc
Free Memory?
bdt1995 said:
I just tested it out on my Droid 1, which is running CM6.1RC5 (Not sure if thats relevant or not), and it doesnt seem to work very well on my phone. All apps came back as 4KB, at the top it showed this... Total:261.8MB Used:NaNKB Free: 259.1MB Database NaNKB Files: NaNKB Preferences:NaNKB Cache:NaNKB.
Click to expand...
Click to collapse
I'm having the same problem as bdt1995. Running CM 6.1 RC1.. the only difference is the total memory is 196.2 and the free is:194.3 MB cuz I'm using a Nexus.. CM6 might be the problem?
bdt1995 said:
I just tested it out on my Droid 1, which is running CM6.1RC5 (Not sure if thats relevant or not), and it doesnt seem to work very well on my phone. All apps came back as 4KB, at the top it showed this... Total:261.8MB Used:NaNKB Free: 259.1MB Database NaNKB Files: NaNKB Preferences:NaNKB Cache:NaNKB.
Heres the debug report: 1:/dev/block/mtdblock6 268032 224572 43460 84% /data
2:62855 /data/data
3:4096/0/265352
Click to expand...
Click to collapse
Same here (total 196.2MB, Free 194.3MB, all apps 4KB), system details in my sig. Using apps2sdext, over 200 apps.
Debug info:
Code:
1:/dev/block/mtdblock5 200960 112144 88816 56% /data
2:96070 /data/data
3:4096/0/198951
Same problem as above with Cyanogen 6.02, However it looks promising.
I Think that moving data to standard SD can leads to security issue, because SD can be readed and written by any apps. Should be better if the app recognize /EXT partition, if exist, and move data here.
i'd like to try it and i get my lil sis to try it also she gets this problem a lot i have the droid incredible and my sis has the droid eris.
bdt1995, rnh16, britoso, mmorselli:
Thanks for the debug info. Indeed Cyanogen is a tad "exotic" for NES at this point.
Please download the latest version of NES -- I just uploaded it. It contains an extra debug line which should allow me to make it work so please paste your debug output here one more time.
JerseyFF:
Oops, thanks.
lhinsz:
Because it is a beta version, it hasn't been released yet and all the information you may need is contained in the Help screen. I tried to make it comprehensive.
BigNate:
Should work with HTC devices, yes. Could you or you sister paste her phone's debug screen here?
Zandog:
I do not think that both apps share the same goal so no lives should be lost (Seriously, not much of a bubble to burst?)
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?
So I check my Xoom out this morning and Boom "Low on Space 'Tablet storage space is getting low'. It is impossible that I filled all of the space. I looked at my breakup and i have about 6Gb of music and it says the rest is completely full due to applications. I look at my applications but I only have about 3GB worth of application and data attributed to saves (manually counting). For the most part, besides the stock honeycomb apps, these apps are the same that I have on my Droid1. Which has much smaller storage. Somehow some app is taking up all the space (which i can't identify), the OS is corrupted, or I have a virus. Everything else has been pretty mainstream applications.
I have the OTA update and my Xoom has never been rooted.
Is anyone else having this problem?
A lot of people got this issue. It is being discussed in the Motorola official Xoom forum. But still no one know what's the root cause.
Sent from my Nexus S using XDA App
gogol said:
A lot of people got this issue. It is being discussed in the Motorola official Xoom forum. But still no one know what's the root cause.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
Thank you for the quick response. I guess its good to know I'm not the only one. Hopefully it gets fixed soon.
The link to the issue on the moto forums is
https://supportforums.motorola.com/thread/46601?start=0&tstart=30
Hi Everyone,
For those users not yet experiencing this but wants to see whats going on, I made a video. There is also a way to check to see if this is occurring to you by checking out your internal storage on the Xoom.
http://www.youtube.com/watch?v=tWFeq0Qj3iA
Is there anyone else experiencing this issue on their Xoom?
It happened to me last night while playing WordFeud. I get the two line message "Low on space" and "Tablet storage space is getting low"
There is no way that I am using 25 gig in applications.
Thanks,
Dan
My initial guess is that it is Application specific. My xoom has 628Mb for Applications. I think maybe some app that each of you is using is continuing to pull in data and not deleting it over time. Maybe something like a news stream or something else. I would chat with the others having this problem and see what similar apps you have.
Just a thought. Sounds odd, I agree.. but.. a place to start. Maybe akin to a memory leak.
Thanks for the quick reply, eaglecomm. Your suggestion makes sense. In looking around a little this morning, I see that some people thought it might be the Google Body app, which I had installed. I uninstalled it, but it didn't make a difference.
It turns out that there is a fix coming in the next update.
The thread is at the Motorola Owners Forum titled 'XOOM Storage is Full' problem - 47 apps takes up 27 GB?
Since I am a new member here, I cannot post the actual link.
I thought I would post this info for any other Xoom owners that are have this concern.
I am glad to see it is being addessed.
Thanks,
Dan
My Xoom is not indicating that it is low on storage, but the applications do seem to be taking up an inordinate amount of space. Funky little bug.
On a positive note, it is good to know that the functionality of this device will only get better over time.
Tombstones
Are any of you able to look at the sizes of the files in /data/tombstones? I had the same problem and did some digging and found a tombstone file that is 19 GB. It appears to have been generated by a browser crash. If any of you are having the problem can you open a terminal and go to /data/tombstones and find the biggest file and type cat (name of biggest file) and tell us the name of the process (listed after pid). You may need to be rooted and may need busybox for cat to work. I doubt it's only the browser... I'm curious to know if it's a honeycomb thing with how it tombstones app crashes.
Have you tried using a cache cleaner ? I use 1 Tap Cleaner and Fast Cache Cleaner .
Try using DiskUsage to view what is using up your storage. If you're rooted it gives you even more options to view specific folders. If you've ever used WinDirStat then this is the closest thing android has to it that I've found.
https://market.android.com/details?id=com.google.android.diskusage
Although Moto is promising an update "soon" to fix this, the problem has been getting reported on for over 45 days now. Some people were hit with this early and some more recently - like myself. This one was sort of the last straw for me. I had to do a factory reset on mine (in Settings) in order to resolve this issue; which hasn't reared its ugly head again since. However, between that mess, and no SD card, SMS, etc, I finally got fed up and rooted mine so that I could use the Tiamat kernel and at least add a 32 GB SD card in the slot provided. Rooting also allowed for Clockwork Recovery (which I love) so making modifications is much easier. If and when Motorizon decides to provide us with the 4G update, then I'll flash it back to stock. However, in the right here and now, I needed a tablet for my work and didn't have the luxury to sit around with my hands tied and wait for Moto to finally have pity on us and provide what they hyped us with. The XOOM has become too integral a part of my work and home life. The product answered a lot of needs - some I didn't even realize that I had. I'll just have to do the extra step now of flashing back to stock when (and if) update time finally comes around. Until then, I'm moving forward and I've got WORK to do!! Yippee kyy-yaayyyy!!
I have this problem and looked in my folders trying to find large files using ES File Explorer. I have found a repeating set of folders here:
/sys/module/usbhid/drivers/hid:generic-usb/module/drivers/hid:generic-usb/module
These folders keep going and going and going. I tried to look at the properties of the sys/module folder but the file size kept going and going and going. I ran it all night and it was still running in the morning at 1.25GB and counting. Is it safe to delete the repeating set of folders? Does anyone know what these folders are used for?
Deanne
DeanneJensen said:
I have this problem and looked in my folders trying to find large files using ES File Explorer. I have found a repeating set of folders here:
/sys/module/usbhid/drivers/hid:generic-usb/module/drivers/hid:generic-usb/module
These folders keep going and going and going. I tried to look at the properties of the sys/module folder but the file size kept going and going and going. I ran it all night and it was still running in the morning at 1.25GB and counting. Is it safe to delete the repeating set of folders? Does anyone know what these folders are used for?
Deanne
Click to expand...
Click to collapse
Looks to me like a recursive bug where the folder or device is continually being created inside itself, it would cause everything from unstable os to complete unresponsiveness and even filling up the storage.
Macbots drool as I XOOM through the Galaxy to my hearts Desire.
i've returned 2 note pro's thinking they were defective and realising now that the issue of rebooting was due to a corrupted file in my system, i have identified it is one of my comics files i had stored years ago on cd disc, the problem is there are like 1000 comics i can't check each one individually.. does anyone know of an app or a way to scan the tablet to find the rogue corrupt file?
originally when it caused the reboot the comics were stored on my sd card, the second time stored in the device storage and third time in device storage again.. apart from checking one by one is there a short cut way that will tell me which file is damaged?
i know years ago i remember encountering one of the comics would not open that was the corrupt file however i cannot remember which one it was it was years ago i last checked.
A simple corrupted non system file shouldn't be causing the issue. However a simple look at file sizes may point to an issue, it may be more related to filename structure if very long or has non standard naming conventions not used in Unix.
If you have the files on cd and are moving over just move a portion over at a time to narrow the problem down.
Sent from my SAMSUNG-SM-P907A using XDA Free mobile app
Connect it to a computer and let explorer search for 0kb files. Ignore the .nomedia and playlist files.
Any mediafiles that show up as 0kb are corrupt.
Sent From My Samsung Galaxy Note 3 N9005 Using Tapatalk
rodnok1 said:
A simple corrupted non system file shouldn't be causing the issue. However a simple look at file sizes may point to an issue, it may be more related to filename structure if very long or has non standard naming conventions not used in Unix.
If you have the files on cd and are moving over just move a portion over at a time to narrow the problem down.
Sent from my SAMSUNG-SM-P907A using XDA Free mobile app
Click to expand...
Click to collapse
Thanks maybe it is a file name issue. Im definitely sure it's the comics as all 3 have rebooted constantly because of iti just cant figure out wht it is. Is a filename which is too long likely to cause reboot?
i know it's not a software or firmware issue per se but i can't figure it out what's causing the reboot. Whenevr i play videos and lock the screen it reboots but it's only after i transferred the comics over
What would be considered a non standard naming structure..it is baffling why it keeps rebooting im transferring the comics away now to see if it stops
Only alphabet, numbers, underscores and dashes should be used, spaces are not great(depends on what you are doing). basically nothing else should be used(there are exceptions depending on Unix version but this is Linux) or Linux will hate the naming convention. Dots are fine also.
Did you load a comic app to read these or are they just. Jpg or similiar?
Sent from my SAMSUNG-SM-P907A using XDA Free mobile app
rodnok1 said:
Only alphabet, numbers, underscores and dashes should be used, spaces are not great
Click to expand...
Click to collapse
Lolwhut... :laugh:
I have about 80.000 pdf's and comics in one folder. ALL have spaces in the name.
Comics are usually in cbr, cbz (both are .zip variants) or pdf format. Can you honestly imagine having to load every single page in jpg? Lol.
Exclude the folder from mediascanner by dropping a .nomedia file in it, and scan the thing with Windows Explorer or Apple Finder for 0kb files. (regular search, in english the string is size:empty ) That should be more than sufficient.
ShadowLea said:
Lolwhut... :laugh:
I have about 80.000 pdf's and comics in one folder. ALL have spaces in the name.
Comics are usually in cbr, cbz (both are .zip variants) or pdf format. Can you honestly imagine having to load every single page in jpg? Lol.
Click to expand...
Click to collapse
Being unfamilar with how comics are stored is why I asked...
Spaces can be problematic based on operating system and interface, Unix nor Linux like them so I avoid at all costs. Just because an app allows you to read them doesn't mean it cannot be an issue.
Unix interpretes a space as space between commands when using command line, since OP problem may be when files are being read outside shot a weird combo is actually causing an issue.
When switching between Windows, Unix, VMS worlds and having them all need to read all files properly either from web servers being hosted on them or from applications being run locally, spaces are one of the biggest issues. That and forward and back slashes.
rodnok1 said:
Only alphabet, numbers, underscores and dashes should be used, spaces are not great(depends on what you are doing). basically nothing else should be used(there are exceptions depending on Unix version but this is Linux) or Linux will hate the naming convention. Dots are fine also.
Did you load a comic app to read these or are they just. Jpg or similiar?
Sent from my SAMSUNG-SM-P907A using XDA Free mobile app
Click to expand...
Click to collapse
they are scanned comics from the 90s i had the stored for about 10years theyre .cbr files optimised for reading in comic apps like perfect viewer.
do you have any idea what is causing the reboot? ive removed the files now no more reboot..very frustrating.
f sake it seems the reboot is back despite removing all the comics...not as much as before only once since this morning howeve it is back..it didnt happen once when i got the tablet till up till putting the comics in..however i havent really been using the tablet since then watching videos or doing anything intensive tbh so it's hard to say the cause..do you think it's definitely a rogue app or firmware issue rather than hardware?
this is the 3rd tablet i have had the first one kept rebooting all the time..i updated to the latest firmware and disabled all the apps i could that i dont use.. on my replacement i kept it as simple as possible i kept the original firmware but did not disable any apps let it run as normal as possible but did add the comics in..in the morning it rebooted.. so i returned it. now this one is the third time and it's so annnoying i have to think that if ALL 3 are rebooting it cant be a hardware issue right? i cant be that unlucky that all 3 have hardware issues so surely it must be right to assume it is all firmware related etc?
it is such hassle doing factory reset each time sorting it out one by one filling in passwords etc.. that it doesnt look like i can resolve it now.. the comics are removed yet it still is rebootin for all i know the device would have reboot had i did more ram intensive stuff like watching videos..am i just going to have to accept it? being thankful it isnt a hardware issue.
ironically my second tablet didnt screen flicker when i was using the original firmware
Short of factory reset not sure how you're going to narrow it down to hardware/firmware or software.
If you removed offending app and comics completely and dalvik cache was wiped it eliminates that..
F sake i did a factory reset yet it is still rebooting it seems to be after ram intensive stuff this cant be right? It can't be hardware because all 3 have done it i just can't figure out what's causing it it has 3gb ram nd power saving is off why does it keep rebooting?
I think maybe the sd card may have some things in it from the comics but i removed the sd card and it still randomly reboots could my contacts crashing be the reason? I disabled contacts and contacts storage as i do not need itif idont it keeps bri gingup the warning unfortunately contacts has stopped.
rodnok1 said:
Short of factory reset not sure how you're going to narrow it down to hardware/firmware or software.
If you removed offending app and comics completely and dalvik cache was wiped it eliminates that..
Click to expand...
Click to collapse
im not rooted so cant do dalvik wipe. Wht on earth could be causing it?
like i said ithas been fine since i got it before i put the comics in i removed the comics factory reset and it keeps rebooting still what the hell i honestly can't figure this out all 3 did the same thing im about to give up
I'm not sure what you are doing after a factory reset but what I would do is remove any SD card and do a factory reset again. I would not allow restoration of any other software (when you get to the portion of setup where it asks if you want to automatically backup and restore day no) and I would simply run the device bare bones for a day or two without installing anything to rule out any application that I might be installing.
Sent from my SM-P900 using Tapatalk
ok so i rebooted a 2nd time (jeez im getting fed up of this) and did not load the sd card just incase i also decided to set up a brand new gmail account so that it does not sync my contacts from the other google account in case that was the issue.
so far so good. i also formatted the sd card did not transfer the comics over and all is good.. now i do not know whether it is indeed the comics or whether it's because of my contacts storage on the other google account i originally used.. and i dont really want to test it to find out..originally when i used the previous google account and did not add any comics it did not reboot once.. so what's weird is after the first factory reset where i did not format the sd card as soon as i left it in the sd slot it casued the reboot later no matter what i did.. how the hell is this thing so sensitive that it reboots just by having the sd card in..its like there's a file in there that as soon as u put the sd card in it causes a reboot.. remeber i removed all the comics from the sd card previously and the device and it kept rebooting inexplicably..
so right now i can't figure out if it's the fact i formatted the sd card and factory resetted it or whether it's because i use a new google account?
do any of you guys know how or why something as innocuous as comic books or remnants of it in the sd card is causing a reboot?
Given that the best way to troubleshoot technical issues is to approach things in a logical fashion it's important to isolate things one at a time. You can either do that by removing one thing at a time OR by starting fresh and adding things one at a time.
Just to explain my previous post . . . if someone asks the question at times like this whether or not it's a hardware issue the first thing I jump to is to yank the SD card, factory reset (personally I prefer a full wipe to stock using Kies and a factory image file) and then to NOT install anything on the device . . that right there is fresh out of the box experience with no external influences other than any updates to preinstalled applications. If a person has the same issues with that then there's likely a hardware issue. Sometimes I see people assuming that they're not installing software after initial setup when in fact they are when they opt into Google's automatic backup/restore feature during lyncing to their Gmail account during setup. Its rare but it happens and at that point they're not evaluating a stock out of box experience, obviously.
Back to your last post . . its possible that your SD card has a bad sector on it and the act of formatting it simply erased files that would otherwise be scanned by media server/index services which was causing the reboot. One way to rule that out would be to use a computer and try to do memory testing of the card.
It can be difficult to narrow these issues down, as said I would run bone stock with no sdcard for a few days not even adding a Google account or any updates and see what happens. Google updates have caused me a few issues on other devices when updating an app and needed reinstalled even to clean things up is why i suggested no updating anything. The system is not going to scan the sdcard or use data off it unless called upon to do so. Adding sdcard and if a problem still switch to another even.
Recently a friend had a card that would only read certain movie files and then if reloaded onto card wouldn't read it then. Card was found to be bad(well it works for some files anyways) didn't show bad sectors either.
Sent from my SAMSUNG-SM-P907A using XDA Free mobile app
thanks for the advice.
well guys the tablet hasn't rebooted since meaning it must have been something in the comics which as soon as you add it to sd card or device storage and even if you remove all it's contents still leaves a lasting effect unless i format the sd card and factory reset.. i hate factory reseting it's such hassle going one by one spending days trying bit by bit when it really should just work out of the box with no problem.. however this prob isnt a samsung fault it's a rogue file or something in my comics folder which i cant figure out what it is?
do you know anyway i can scan the comics folder which is now on my laptop so i can fix it for any errors?
i bought this tablet specifically for reading comics and now i can't haha otherwise it'll reboot like crazy.. yes i know it's not the tablets fault it's my comics fold3er of scans where i cant identify the thing which is casuing conflict.. would checkdisk work?
im just fed up because i returned my original black wasted loads of petrol going round tryna find the same colour elsewhere ended up with white returned that and had to travel other part of town for the last black one and in process it's ended up costing me an extra 15 pounds total to get it as i lost the cashback i got buying the original and returning it plus the petrol plus also by returning i lost a goodwill refund.
anyway on plus side this one has less backlight bleed so pleased with that however the screen flickering issue concerned me which the other 2 did not have.. i've updated the firmware so no more flickering during video playback however i dont use high brightness so hard to say.. i do see random flickers from time to time but i think it may be slight glitches so bit paranoid.
anyway what is the best way to scan my comics folder in windows to identify bad sectors or anything corrupt that would cause the note pro to reboot?
i dont want to put comics back on or even read from a separate sd card as the evidence shows it'll reboot again unless i get to the root cause.