Develop Reference

SDCard access on Lollipop and higher permission

I read this post which seems to explain this feature. But, I still don't know few things:
In my file explorer:
When should I ask for this permission
How do I ask (I know the intent->onActivityResult but, how do I check if I have to ask ?)
What do I do when I want to do something with this SDCard permission ?
Thanks in advance

Acolleague just pointed me at this issue. What's the problem exactly? I see in the code that the manifest has:
It also needs the READ_* permission likely. That should give it full access to external storage. Storage Access Framework is a completely different system for interacting with user documents across apps, has nothing specifically to do with write access to sdcard.
And you've always needed that permission to read/write sdcard without root. Old apps didn't have it. The change in KK is that you can now read/write to your private data folder on sdcard WITHOUT needing the permission -- you only need it if you want to touch outside your private data.
So is the real problem that syncthing doesn't USE external storage (sounds confusing, but it only has the WRITE permission), doesn't expose it to the user as a target, or is there simply a bug under the hood somewhere...
Hope that helps!

Protecting files on android

My group and I have an application that will work with protected content files that could (or not) contain pretty sensitive information. So we have to ensure they will not be copied by the user.
This question is specifically about the micro USB port. Is there a way to programmatically block it so that the user will be unable to mount trough it to copy our files?
Any and all help/counsel/answers are appreciated. :)
Additional Information:The application will be pat of a custom home application, so we will have that to out advantage, if that is any help.

There is no 100% safe solution for file storage. If you store the files on the SDCard they will have zero protection. If you store them on the internal filesystem you will be protected by file system permissions, which will generally prevent other apps getting to your files. But if the user roots their phone, nothing will stop them getting the files off the phone. Most phones can be rooted.
If you want to protect the sensitive information from your users, look for a way to store it on the network instead. If you only want to protect against other apps, for users that haven't rooted, the internal filesystem should be good enough.

The above are correct and to add, suppose you do disable the USB? Then I'll just Bluetooth them off. Ah, you disabled Bluetooth. OK, I'll use ADB shell over WiFi. Damn, you thought of that too. OK, I'll copy them with Root Explorer to my Dropbox folder. Wait, you got me, I'll email them instead...
You get the picture ;)
I am of the opinion that there is no totally secure file in Android. It's just a question of how difficult you can make it to lock out the 99% of "average" crackers.

Is /data/data/ a reliable assumption for installation path?

I am messing around with node.js on Android through this project, and I need a way to deploy js files to a private directory (to hide the source code, and prevent users from tampering) which also physically exists on the filesystem (an apparent requirement for node.js).
Is it correct to place my javascript files in /data/data/com.skabbes.android/node_modules? And if not, what would be the correct way to accomplish my goal?

Well, if you are wanting to store something on the internal storage, it is not recommended to use an absolute path like /data/data/..../ because while that may be the correct path, it can potentially change with different devices or different Android versions because /data/data/ the internal file structure is not specified in official Android documentation.
I also want to point out that even if you are storing information in the /data/ directory it is still possible that someone could access it if they have a rooted phone.
But, what you should do is see This. That will save information on the internal storage of the device and neither the user nor other apps can access the files you save with that method unless the device is rooted.

You should use the getFilesDir() method of Context which basically abstracts the absolute path.
It will most probably be something like /data/data/<package-name>/files but it's a better way to make sure your app is compatible with all versions of Android and all devices.

Android, which device's dir should I write data to, to be able to read it back?

I'm writing an Android app which uses wi-fi, so I can't easily debug to emulator (no wi-fi support... ;-), so I go with my real device (a Samsung Galaxy S).
I would like to be able to read data files my app writes, to debug and test.
If I use, say:
new File(getFilesDir(), "myfile.xml");
I get my data file written to /data/data/MYPACKAGE/files/, but that directory is non accessible via adb (nor via Eclipse's DDMS).
My device is not rooted (and I'd prefer to avoid rooting it, if possible... ;-)
Where should I write my data file to?

It probably makes sense to put the files on the sdcard during development, formally you should call getExternalStorageDirectory() to find it and of course will need external storage permission.
Alternatively, you could give public access to your private files in the debug version; just don't forget to turn that off before you ship (as a certain Internet telephony company reportedly did). However, this will not make the private files browsable as the intervening directories are not, you would only be able to adb pull them via their exact path name.
A third choice would be to leave the data internal and private, but have a debug function to copy it over to the sdcard for analysis. You could even do this in a separate .apk establishing a shared user id with the first, meaning no changes at all to your application.

Simply use external storage!

You can write to your SDcard. You should use getExternalStorageDirectory() to get your SDcard's path. You will have to include the <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> in your Manifest to do that.

The answer differs depending on your API level. Review the section in the documentation on external storage to get the answer for this.
http://developer.android.com/guide/topics/data/data-storage.html#filesExternal
For a somewhat generic answer, the sdcard directory that you should be storing files in is the directory returned from getExternalStorageDirectory() (which should be the root of your sdcard or possibly internal expanded storage as with my Captivate), with subdirectories of /Android/data/your.package.name/files
Oh yes, and as another poster mentioned, don't forget the WRITE_EXTERNAL_STORAGE permission in your manifest.

Android: Problem setting file permissions when filename has a space

Have an app where I store .png images in the app's cache directory, and as I am sharing these files via messaging, etc, I need to make the files readable temporarily by everyone (i.e. chmod 755).
As suggested in another thread, I am running Runtime.getRuntime.exec() to do this:
Runtime.getRuntime().exec("setperm chmod 755 /path/to/filename.png");
This works fine, and as I am filtering / and \, any name works... except a name with a space, unsurpisingly. This fails:
Runtime.getRuntime().exec("setperm chmod 755 /path/to/file name.png");
So, coming from linux, I try wrapping the file path in quotes, which works on linux, but still fails to change the file perms on Android:
Runtime.getRuntime().exec("setperm chmod 755 \"/path/to/file name.png\"");
or
Runtime.getRuntime().exec("setperm chmod 755 '/path/to/file name.png'");
Any ideas?
Thanks,
Paul

Have an app where I store .png images in the app's cache directory, and as I am sharing these files via messaging, etc, I need to make the files readable temporarily by everyone (i.e. chmod 755).
Don't put them in the cache dir. Use openFileOutput() and set MODE_WORLD_READABLE.
As suggested in another thread, I am running Runtime.getRuntime.exec() to do this:
Whoever suggested that to you is a moron. No Android application should be using exec(). There are no command-line binaries that are part of the SDK and that you can rely upon being there.
UPDATE
In a related android-developers thread, Dianne Hackborn (#hackbod) writes:
The recommended way to do this is to write a content provider, which the other app can call ContentResolver.openFileDescriptor() etc. It is actually really easy to write such a content provider -- it doesn't need a database or anything, just to implement ContentProvider.openFile().
Every situation I have seen where MODE_WORLD_* is used it causes more troubles than just writing a content provider. I regret having made that.

The exec() solution works well when in development you want to get access to your app's data but don't want to root your phone. I agree that it shouldn't be used in production code, but it sure saved me a lot of time firing up emulators just to get at my database.