quoting
01-31-2013, 10:21 AM
dmtchico "Lack of the option to use the extsdcard more is due to lazy app developers, not Samsung. IMO."
Before fingers get pointed, please understand that Android App Developers are at the mercy of the SDK API given to them, and that the request to create a directory & files for External Public Storage is sent to ~/storage/sdcard0.
(symbolic link equivalent to ~/sdcard and ~/mnt/sdcard0)
i.e. assuming we have set the write permission in the app manifest (this request for app permissions is what you see before you install an android app)
we check that the 'external storage' is mounted for read/write
if (Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState())) {
and then to retrieve the value of the Pictures subdirectory on 'external public storage',
In API Level 8 or greater, use getExternalStoragePublicDirectory(), passing it the type of public directory you want, such as DIRECTORY_MUSIC, DIRECTORY_PICTURES, DIRECTORY_RINGTONES, or others. This method will create the appropriate directory if necessary.
If you're using API Level 7 or lower, use getExternalStorageDirectory()
This is in the SDK, there is nothing developers can do to change that, they can only work around it by hard coding specific mountpoints for every OEM who chooses to mount the EXTERNAL sdcard on a separate mountpoint, such as /storage/extSdCard for Samsung Galaxy S3 on Android v4.1.2
That obviously requires knowledge of all OEM's way of handling storage naming conventions, at all variable SDK levels and cutover points of new methods and deprecation.
Please also understand that the point of using the SDK conventions is the antithesis of writing hardcoded workarounds.
Just as an example, Android SDK frowns on hardcoding variable string assignments inside code, it nags developers to put all static values into a strings.xml file and to refer to variables stored in that abstracted file.
Android SDK itself is bad enough with deprecation where developers have to code at least two logic paths for both pre and post deprecated target API levels and also code precompiler directives to avoid getting more warning or error nags in the IDE such as Eclipse...
I have been trawling forums and am still looking for a non-rooted workaround for this, but it seems like hardcoding is the only way, and adding an option for the user to manually choose their own save locations via a directory browser widget in a separate settings activity.
And how many users would know the difference between ~/storage/sdcard0 and ~/storage/ExtSdCard or to know to use it in the first place rather than ~/sdcard or ~/data or any number of other directories?
The Android SDK link even says that this 'external storage' may in fact refer to a partitioned section within internal storage:
Storage Options | Android Developers
NOT Helpful.
Update 2013/04/28 - found this as the best answer for developers to use 'removable' external storage -
How can I get external SD card path for Android 4.0+? - Stack Overflow
This other reference is full of condescension to the developer from some posters who smugly point out that 'external storage' in Google's 'original definition' has never meant 'removable storage'...
java - File.canWrite() returns false on some devices although WRITE_EXTERNAL_STORAGE permission provided - Stack Overflow
They also advise that the 'need' to use removable storage is 'flawed' and
"The devices are fine -- your expectations are not. Please fix your expectations."
WTF? Seriously?
I acknowledge this does not help the OP who just wanted to know how to save files to a 'removable' sdcard rather than to the device's internal 'external' storage, but it should help any developers reading this looking for same solution as I am.