Hi Jon,
On 18 November 2013 18:59, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Mon, 2013-11-18 at 14:56 +0530, Vishal Bhoj wrote:
Hi Tixy,
I am still trying to get sdcard mounted on pandaboard and Arndale. For
the
current issue you are facing, I think its related to the one discussed in CM. Here is the thread: http://forum.xda-developers.com/showthread.php?t=2524316
Can you please tell if this fixes the issue.
Unfortunately it doesn't fix the error I'm seeing.
I am seeing the same error on Arndale as well after fixing the sdcard detection issue. I will be trying it on Pandaboard which is using a 3.2 kernel. It will give a better clarity if the issue is related to upstream changes in newer kernel.
-- Tixy
On 16 November 2013 02:02, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Fri, 2013-11-15 at 11:08 -0800, John Stultz wrote:
On 11/15/2013 09:55 AM, Jon Medhurst (Tixy) wrote:
So, hacking getFatVolumeId to return a value other than -1 means
the
system works and files on 'external' sdcard are seen and usable by
apps.
I guess the issue is that the file system is 'fuse' not 'vfat' and
the
fuse filesystem doesn't implement VFAT_IOCTL_GET_VOLUME_ID.
So it would seem logical that the config is wrong somehow the the non-emulated external media shouldn't be using fuse. However, the description at http://source.android.com/devices/tech/storage/index.html says:
Starting in Android 4.4, the owner, group and modes of
files on
external storage devices are now synthesized based on
directory
structure. [...] These synthesized permissions are
accomplished
by wrapping raw storage devices in a FUSE daemon.
???
So I've just been barely following along here, but that quoted
paragraph
is a little frightening. Instead of using a filesystem with actual granular permissions, they've added a permissions meta-layer over FAT via fuse? Eww.
As far as the rest of the issue goes, it sounds like you've managed
to
work it out. But if it ends up being a problem with either of the GET_VOLUME_ID ioctls, let me know.
By the way, this sort of hiccup (and its workaround) is something we probably should be documenting and publicizing.
My 'work around' was to hard code the FileUtils.getFatVolumeID function on Android to return 0x12345678 for the volume ID, which is not something that I would want to commit to the Linaro tree. Not very good if there is more than one media partition, or if it isn't mounted yet (which comments in the code seem to anticipate) and I don't know where else that function might get used.
The only reason I tried the hack was to see if there were other issues with getting storage devices to actually work.
I'm still assuming we must have something configured wrong, unless KitKat is just simply broken and I'm the first person to notice.
I'll try an come up with a cleaner hack next week if I find time to understand all the uses of that function...
-- Tixy
linaro-android mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android
linaro-android mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android