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
Mods: Sorry if this thread was posted in the wrong sub-forum, I didn't realize till I was done typing that I was asking a question! Please move to Q&A if it belongs there.
One of the major features I was looking forward to with my new Razr Maxx HD was finally being able to have device encryption similar to what I had with my Blackberry. That's one thing BB really nailed on the head. Today, I finally get around to set up encryption on my phone and I contacted Motorola to ask a few questions. I asked about how to copy files to a PC and what happens with the data on the SD card if the device breaks. The agents reply?
"I do recommend that you don't encrypt your device. Just do the normal process."
I asked her about several scenarios and was told every time that there is no way to copy files from the device to a computer and no way to guarantee that the files will be retrievable even with regular use of the encryption feature that they falsely represent in sales tactics as "government grade encryption" for the device. They use the term to try and sell the phone to serious business people like me, then tell me that they advise against using it at all because the data on the phone may never be able to be retrieved if something happens to the phone. Not to mention that there is no way to copy the files to a PC if you want to do regular backups. I was the one who asked about the possibility of just emailing important files form the phone to myself or uploading them to dropbox, she couldn't even recommend that on her own. All in all, it's a very pathetic situation.
So, what I'm wondering is. Is there anyone who uses device encryption? Have you figured out any way to get around the issue of being unable to backup your files to a PC? I really want to use encryption, I've been missing it for over two years since I switched from BB. I'm not a top secret FBI agent or anything, but I do feel more secure with my personal and business information encrypted. What I'm thinking is, set up Titanium Backup to do a scheduled sync to Dropbox. I haven't done that before, but I think Titanium will do that. This should cover pretty much anything on the phone itself. Now, what I am wondering, is there something similar to Titanium Backup that can backup contents of the SD card to the cloud? I already have Dropsnap uploading my photos to Dropbox, so those are safe, but I would like to backup the rest of my data from the SD card too. Seems any way the phone can send the files to a server would basically be a good way to backup data in an unencrypted state. I just don't know of any solution for that for the SD card.
This is a very disappointing thing about the encryption, I'm hoping someone here has some ideas!
gadsden,
One app that I am fond of for transferring any type of file from my phone to the cloud is FolderSync. It can sync any type of file to the more popular cloud services (Dropbox, Box, Google Drive, etc.), and it has a lot of additional functionality such as move files around on your phone (internal storage to SD, SD to cloud, cloud to SD, etc.), instant syncs, scheduled syncs, widgets for syncing on demand, and more.
It's just under $3, but it's well worth the functionality it brings and it may be what you are looking for. Definitely worth a look at regardless.
madkel said:
gadsden,
One app that I am fond of for transferring any type of file from my phone to the cloud is FolderSync. It can sync any type of file to the more popular cloud services (Dropbox, Box, Google Drive, etc.), and it has a lot of additional functionality such as move files around on your phone (internal storage to SD, SD to cloud, cloud to SD, etc.), instant syncs, scheduled syncs, widgets for syncing on demand, and more.
It's just under $3, but it's well worth the functionality it brings and it may be what you are looking for. Definitely worth a look at regardless.
Click to expand...
Click to collapse
Cool, that seems like it will do exactly what I want. I'm definitely going to give it a try, thanks!
So I'm selling my old Meizu M2 Note which is running Flyme OS that doesn't allow me to encrypt the whole phone. How can I ensure the data is actually gone before selling? Normal wiping doesn't erase everything.
That's a good but hard to answer question.
A good old fashioned hard drive can be single pass overwritten (debate about overwrite passes is still an open discussion) making it unrecoverable for anything but an MFT, Mobile devices use flash memory just like a USB drive or an SSD.
What is the difference? Wear leveling (https://en.wikipedia.org/wiki/Wear_leveling).
Because of that people came up with crypto-shredding or crypto erase which only truly works with Hardware Encryption because Software encryption can never, with 100% certainty, know how the wear leveling reacts on every device.
You already said this isn't an option so what can you do to be sure nothing can be recovered? The answer is unfortunately short, nothing.
However recent research showed that multi pass overwriting caught a lot of data but even the Gutmann method (35 passes) did not get rid of everything (I forgot the link to the Whitepapers).
That said, you aren't selling it to a forensic specialist.
My best suggestion is to use one of the higher rated wiping apps (Shreddit for example) to first destroy your files, then factory reset and download a few good recovery apps and again a wiping app. Make sure you can't recover your own files anymore (if you have very sensitive data you can connect it to a PC and use even better recovery or, if you are paranoid, forensic tools) then overwrite it with as many passes, rounds and algorithms you feel comfortable with. Check recovery tools again and call it a day when you feel satisfied.
This WILL eat at the wear level so keep that in mind when you want to start overdoing it.
Not everything will be gone but it's as good as it's going to get and I highly doubt the person you sell it to will be able to recover anything.
Good luck!
GU42 said:
So I'm selling my old Meizu M2 Note which is running Flyme OS that doesn't allow me to encrypt the whole phone. How can I ensure the data is actually gone before selling? Normal wiping doesn't erase everything.
Click to expand...
Click to collapse
#noob guide incoming
(potentially useless and harmful)
i just thought of it
shred memory
download custom rom and flash
fill memory with stuff
shred again
xD
TheMarchHare said:
That's a good but hard to answer question.
A good old fashioned hard drive can be single pass overwritten (debate about overwrite passes is still an open discussion) making it unrecoverable for anything but an MFT, Mobile devices use flash memory just like a USB drive or an SSD.
What is the difference? Wear leveling.
Because of that people came up with crypto-shredding or crypto erase which only truly works with Hardware Encryption because Software encryption can never, with 100% certainty, know how the wear leveling reacts on every device.
You already said this isn't an option so what can you do to be sure nothing can be recovered? The answer is unfortunately short, nothing.
However recent research showed that multi pass overwriting caught a lot of data but even the Gutmann method (35 passes) did not get rid of everything (I forgot the link to the Whitepapers).
That said, you aren't selling it to a forensic specialist.
My best suggestion is to use one of the higher rated wiping apps (Shreddit for example) to first destroy your files, then factory reset and download a few good recovery apps and again a wiping app. Make sure you can't recover your own files anymore (if you have very sensitive data you can connect it to a PC and use even better recovery or, if you are paranoid, forensic tools) then overwrite it with as many passes, rounds and algorithms you feel comfortable with. Check recovery tools again and call it a day when you feel satisfied.
This WILL eat at the wear level so keep that in mind when you want to start overdoing it.
Not everything will be gone but it's as good as it's going to get and I highly doubt the person you sell it to will be able to recover anything.
Good luck!
Click to expand...
Click to collapse
Thanks for your amazing reply!
I finally found the solution I was looking for: as Avast! support told me, you can still use Avast! Mobile Security to securely erase your phone (by overwriting data), it's just a hidden feature. You just have to deactivate the Device Administrators permission for the app.
Then you just use the "erase device."
Was that research about multi pass overwriting done on SSD, or HDD? I always thought that one pass is enough on a standart HDD.
Can you recommend me any good forensic tools to use to check if the data is truly erased, please? And does the phone need to be rooted in order to restore deleted data?
Thanks for all your insight and advice !
GU42 said:
Thanks for your amazing reply!
I finally found the solution I was looking for: as Avast! support told me, you can still use Avast! Mobile Security to securely erase your phone (by overwriting data), it's just a hidden feature. You just have to deactivate the Device Administrators permission for the app.
Then you just use the "erase device."
Was that research about multi pass overwriting done on SSD, or HDD? I always thought that one pass is enough on a standart HDD.
Can you recommend me any good forensic tools to use to check if the data is truly erased, please? And does the phone need to be rooted in order to restore deleted data?
Thanks for all your insight and advice !
Click to expand...
Click to collapse
Avasts shredder works but it's a single pass on flash memory so it doesn't clear everything with 100% certainty because of the wear leveling but no algorithm does. I'm pretty sure that's a feature they added after purchasing CCleaner.
They also added it as a module in their windows platform.
The multi pass research was done on Solid State Drives and I still can't find the link. Just from a research paper in 2011.
SSD's are still closest in comparison to the kind of memory used in Mobile devices.
As for HDD's it's an open debate. Forensics have claimed to be sble to read past 200 writes in the past but there is no research to support this. I believe that they showed that 1 pass PRNG is enough in 2005, however the DoD was still developing machines to perform 7 pass DoD standard wipes so, I have to say that I have no idea.
If you want serious forensic tools you're looking at these kind of distributions (infosec just made me laugh, SSL_ERR_CERT_COMMON_NAME_INVALID, it's infosec! ??).
http://resources.infosecinstitute.com/computer-forensics-tools/
But if anyone you sell it to would try something it would be more along the lines of Recuva and similar software.
On phones you can just download a bunch of high rated recovery tools and see if anything pops up.
You do not need root for most of them.
You could run fstrim which I'm pretty sure has no root requirements either. This would mark all blocks as invalid so Garbage Collection can pick it up as well. Even though GC has been show not to clean everything it doesn't hurt.
Hello,
I have a rather interesting question, if someone (expert only please) can help, it would be very much appreciated
I have bought a new phone (Huawei Mate 10 Lite) which already has the preinstalled Android 7 OS.
After I turned it on, I've upgraded it to Android 8 (and EMUI 8) via the Software Updater.
So now, I am running Android 8 on Huawei Mate 10 Lite.
Until here, everything works like charm
The problem starts here: I'm used to having my ENTIRE user data partition (phone/device, call it as you wish) ENCRYPTED.
I am using my phone very much in different environments and if I accidentally loose it or it gets stolen, I want to ensure that nobody can access my private data by any possible means.
So, when I go to the classical place for encrypting phones: Settings -> Security & Privacy, I noticed that the "Encrypt Phone" option is MISSING.
I have only "Encrypt SD Card", but I do not have an SD Card, nor do I use one. I use only the internal flashdisk memory.
I even turned on the Developer mode and searched for that specific setting, but I cannot find it.
I googled about this problem and what I found even deepens the mystery, as there are some contradicting information and it doesn't paint a clear picture on how the hell encryption works on Android 7/8...
- In one place, it says that starting with Android 6 phones, the option of encrypting the entire phone is no longer available, as all phones with Android 6+ preinstalled are already encrypted !
Bump ! Really ?
- Somewhere else, someone says that the Full Disk Encryption (FDE) has been replaced with File Encryption and Google is slowly marking full disk encryption as obsolete...
I found the File Encryption on my phone and I have the possibility to create a file encryption "folder" or "vault" or what is that, but I do NOT want that, as I want the entire partition to be encrypted !
I am using VPNs, SSH keys, Pictures, E-mail accounts, Web browsers with stored passwords, basically the entire user partition contains secrets ! I cannot move everything to a secure container... maybe I forget something, and that something remains unencrypted ?
I cannot move everything to a secure SD Card or to put it in that encrypted "folder", because some secrets are files, some secrets are particular app settings or credentials.
Yes, I read about the fact that in Full Disk Encryption mode, a PIN is required for startup (as I had with my previous phone, which was great for me, by the way), and that PIN can prevent the booting of some basic functions of the device or the functioning alarms or something like that.
To tell you honestly, I don't care about those functions. I only want ENTIRE device encryption with one single PIN code.
I have already changed my SIM PIN (which is another thing, it doesn't relate to this), and I generated a phone PIN & Fingerprint on my phone, and set my phone to Lock after 15 seconds.
For everyday usage, the PIN/Fingerprint is enough to keep others from accessing my content, but what about plain disk access (using some other tools that read the flash disk) if I loose my phone or if my phone gets stolen ?
I liked the previous encryption method.
So, basically, I want to encrypt ENTIRE partition (FDE encryption) with one PIN, not SD Card encryption, not other file encryption solutions, not special vaults, not other stuff... I want my classic encryption back !
Please explain me:
1. Are all the new phones starting from Android 6 already encrypted ?
1.1. If so, why is there a file encryption tool to further encrypt particular files if the user partition is already encrypted ?
1.2. If so, what is the encryption key ? or what kind of encryption is that which does not require a PIN or something ? that means that the key is stored in plain text ? (if I don't offer it a PIN, it means that it must read the key from other places in order to decrypt the data (key that can be read by a thief, too?))
2. If Android 6+ phones are not encrypted, how can I implement full device encryption, and why the hell does Google abandon this kind of full, quick and not-giving-extra-security-thoughts encryption ?
I would kindly ask only experts to reply me.
If you are an expert or you know these things for sure, please reply.
I need a correct, documented (if possible), answer, because the security of my phone depends on it !
Thank you !
Well... anyone ??? Is this really such a hard question ???
I was getting so excited when I read your question, because I am looking for the exact same answer. But then I saw there aren't any answers.
Please can someone who knows about this answer this for us?
Mar0615 said:
I was getting so excited when I read your question, because I am looking for the exact same answer. But then I saw there aren't any answers.
Please can someone who knows about this answer this for us?
Click to expand...
Click to collapse
I'm not an "expert" but I can tell you your data is safe & encrypted by default, that is why you can't find an encryption setting.
As I understand it
1. Yes (Google makes manufacturers sign agreement)
1.1 The data is encrypted on phone but you may choose not to lock it. Also you may allow some other people access to your phone even if you set screen lock or it's possible somebody may get your phone before it automatically locks, that is why here is a separate encryption system that some people may want ho use to encrypt certain files. (I'm assuming this is what you are referring to as I have never used Huawei)
1.2 Yes the system can generate it's own key from it's internal information automatically (note also, if you put in a simple passcode it is just one element the phone will use to generate a long key, so hackers can't crack a simple passkey to get into your phone as it also uses it's internal data to generate the key)
2, All your data is encrypted, ok maybe not all eg if you consider an alarm time your data, as some apps may be able to access limited data eg alarm times.
A quick search produced these two articles that are not overly technical & also show the numerous security improvements that all go to make your phone more secure. I hope it puts your mind at rest (though of course nothing can be guaranteed 100% secure if a well resourced group has physical access to your phone eg a government)
https://m.androidcentral.com/how-android-n-addresses-security
https://www.computerworld.com/article/3220446/android/android-8-oreo-security.html