Force access to external removable microSD card

Question

I\'m using a Samsung A3, Android 5.0.2. I\'m using this setup to compile apps, i.e. Android 4.1 Jelly Bean (API 16) target.

I precisely know the path of the external rem

Answer 1

Based on Doomsknight's answer and mine, and Dave Smith and Mark Murphy blog posts: 1, 2, 3:

1. Ideally, use the Storage Access Framework and DocumentFile as Jared Rummler pointed. Or:
2. Use your app specific path/storage/extSdCard/Android/data/com.myapp.example/files.
3. Add read/write permission to manifest for pre-KitKat, no permission required later for this path.
4. Try to use point2 directory and Doomsknight's methods considering KitKat and Samsung case.
5. Filter and use getStorageDirectories point 2 path and read/write permissions prior to KitKat.
6. ContextCompat.getExternalFilesDirs since KitKat remembering Samsung returns internal first:

Write My Package’s Android Data Directory is ok for primary and secondary storages:

In KitKat, full ownership of the app-specific data directories is given to the app’s unique user ID. This means that, going forward, no permission is necessary for an app to read/write to its specific directories on external storage...

The android.permission.WRITE_EXTERNAL_STORAGE permission now grants membership in sdcard_r AND sdcard_rw...

No permissions are necessary to use any external storage volume for application-specific files.

NOTE: In ls -la /mnt/extSdCard/... listings, the sdcard_r group has full +rwx permissions, which obviously is not true in practice... because the FUSE daemon is an active participant in modifying the permissions applied to applications at runtime.

Samsung: A Case Study

In Android 4.3, Samsung emulated the primary external storage volume on the device’s internal flash (NOT the removable SD card). The SD card had always internally been marked as the secondary external storage medium...

In Android 4.4, the primary external storage volume is STILL on internal flash.

Samsung made the choice to include an SD card slot but not mark that as the primary external storage medium.

---

Update:

As explained here and answering your comment about use root path to share files:

You can prior to Kikat using Doomsknight's method 1 and if/else code based on target version, or building multiple APKs.

Since KitKat, Third-party applications just can’t add more files of their own in random locations...

Why Now?

The answer, in an acronym, is CTS.

Rules stating that secondary storage volumes should not be writable by applications have also been in the document since 4.2

However, new tests were added in CTS for 4.4 that validate whether or not secondary storage has the proper read-only permissions in non app-specific directories, presumably because of the new APIs to finally expose those paths to application developers. As soon as CTS includes these rules, OEMs have to support them to keep shipping devices with GMS (Google Play, etc.) on-board.

What About Sharing Files?

It’s a valid question. What if an application needs to share the files it has created on a secondary external storage volume? Google’s answer seems to be that those applications who actively decide to go beyond primary external storage to write content should also expose a secure way of sharing it, either using a content provider or the new Storage Access Framework.

As I explained on the question you requested my help, I never tried this, but my opinion is that theorically you can use root path prior to KitKat using method 1, and these alternatives later.