Apache Cordova
  1. Apache Cordova
  2. CB-5398

Pick image from Library or Photo album on android 4.4

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.9.0, 3.2.0
    • Fix Version/s: 3.5.0
    • Component/s: Android, Plugin Camera
    • Labels:
      None
    • Environment:

      android 4.4

      Description

      An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI.

      Now android 4.4, when you select the above options, it opens an "open from" dialog that let you choose from new places as "Recent", "Drive", "Images" and "Downloads" (the names might not be the same as I use the device in spanish and translated it).

      If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format.

      I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1)

        Issue Links

          Activity

          Hide
          Mike Billau added a comment -

          This exists on 3.x as well.
          In the mean time a workaround is to go through the "Gallery" app.
          So when it says "Recent", "Drive", "Images", and "Downloads", at the bottom of that list will be "Gallery". As far as I can tell this opens up the Gallery app and then you can navigate through those folders and select any of the photos.

          I'm getting this in LOGCAT:

          11-15 12:16:24.017: D/CordovaActivity(7351): Incoming Result
          11-15 12:16:24.017: D/CordovaActivity(7351): Request code = 50
          11-15 12:16:24.017: D/CordovaActivity(7351): We have a callback to send this result to
          11-15 12:16:24.037: D/dalvikvm(7351): GC_FOR_ALLOC freed 34K, 3% free 16572K/17084K, paused 8ms, total 8ms
          11-15 12:16:24.057: I/dalvikvm-heap(7351): Grow heap (frag case) to 46.700MB for 31961104-byte allocation
          11-15 12:16:24.067: D/dalvikvm(7351): GC_FOR_ALLOC freed <1K, 2% free 47783K/48300K, paused 9ms, total 9ms
          11-15 12:16:24.227: E/DatabaseUtils(4667): Writing exception to parcel
          11-15 12:16:24.227: E/DatabaseUtils(4667): java.lang.SecurityException: Permission Denial: reading com.android.providers.media.MediaDocumentsProvider uri content://com.android.providers.media.documents/document/image:59 from pid=7351, uid=10083 requires android.permission.MANAGE_DOCUMENTS, or grantUriPermission()
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at android.content.ContentProvider$Transport.enforceReadPermissionInner(ContentProvider.java:457)
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:394)
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at android.content.ContentProvider$Transport.enforceFilePermission(ContentProvider.java:387)
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:339)
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:305)
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at android.os.Binder.execTransact(Binder.java:404)
          11-15 12:16:24.227: E/DatabaseUtils(4667): 	at dalvik.system.NativeStart.run(Native Method)
          11-15 12:16:24.237: E/AndroidProtocolHandler(7351): Unable to open content URL: content://com.android.providers.media.documents/document/image%3A59
          11-15 12:16:24.247: D/dalvikvm(7351): GC_EXPLICIT freed 31233K, 4% free 16554K/17084K, paused 2ms+2ms, total 25ms
          11-15 12:16:24.247: D/Whitelist(7351): Unlimited access to network resources
          11-15 12:16:24.247: I/CordovaLog(7351): Found start page location: index.html
          11-15 12:16:24.247: I/CordovaLog(7351): Changing log level to DEBUG(3)
          11-15 12:16:24.247: D/CordovaActivity(7351): Resuming the App
          11-15 12:16:24.247: D/CordovaActivity(7351): CB-3064: The errorUrl is null
          11-15 12:16:24.247: D/CordovaLog(7351): file:///android_asset/www/camera/index.html: Line 58 : URL: content://com.android.providers.media.documents/document/image%3A59
          11-15 12:16:24.247: I/chromium(7351): [INFO:CONSOLE(58)] "URL: content://com.android.providers.media.documents/document/image%3A59", source: file:///android_asset/www/camera/index.html (58)
          

          Looks like there is a new permission: MANAGE_DOCUMENTS: http://developer.android.com/reference/android/Manifest.permission.html#MANAGE_DOCUMENTS

          I tried to add android.permission.MANAGE_DOCUMENTS to the AndroidManifest.xml but even after doing this, compiling with ADB and installing, I'm still getting the above error and still unable to pick any photos unless I go through the "Gallery" app first. I made sure to set targetSDK=19 which is when this new permission was added.

          Joe Bowser do you have any ideas on why Android wouldn't be picking up the new permission? Is the problem in DatabaseUtils that I assume is some Android app?

          Show
          Mike Billau added a comment - This exists on 3.x as well. In the mean time a workaround is to go through the "Gallery" app. So when it says "Recent", "Drive", "Images", and "Downloads", at the bottom of that list will be "Gallery". As far as I can tell this opens up the Gallery app and then you can navigate through those folders and select any of the photos. I'm getting this in LOGCAT: 11-15 12:16:24.017: D/CordovaActivity(7351): Incoming Result 11-15 12:16:24.017: D/CordovaActivity(7351): Request code = 50 11-15 12:16:24.017: D/CordovaActivity(7351): We have a callback to send this result to 11-15 12:16:24.037: D/dalvikvm(7351): GC_FOR_ALLOC freed 34K, 3% free 16572K/17084K, paused 8ms, total 8ms 11-15 12:16:24.057: I/dalvikvm-heap(7351): Grow heap (frag case) to 46.700MB for 31961104-byte allocation 11-15 12:16:24.067: D/dalvikvm(7351): GC_FOR_ALLOC freed <1K, 2% free 47783K/48300K, paused 9ms, total 9ms 11-15 12:16:24.227: E/DatabaseUtils(4667): Writing exception to parcel 11-15 12:16:24.227: E/DatabaseUtils(4667): java.lang.SecurityException: Permission Denial: reading com.android.providers.media.MediaDocumentsProvider uri content://com.android.providers.media.documents/document/image:59 from pid=7351, uid=10083 requires android.permission.MANAGE_DOCUMENTS, or grantUriPermission() 11-15 12:16:24.227: E/DatabaseUtils(4667): at android.content.ContentProvider$Transport.enforceReadPermissionInner(ContentProvider.java:457) 11-15 12:16:24.227: E/DatabaseUtils(4667): at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:394) 11-15 12:16:24.227: E/DatabaseUtils(4667): at android.content.ContentProvider$Transport.enforceFilePermission(ContentProvider.java:387) 11-15 12:16:24.227: E/DatabaseUtils(4667): at android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:339) 11-15 12:16:24.227: E/DatabaseUtils(4667): at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:305) 11-15 12:16:24.227: E/DatabaseUtils(4667): at android.os.Binder.execTransact(Binder.java:404) 11-15 12:16:24.227: E/DatabaseUtils(4667): at dalvik.system.NativeStart.run(Native Method) 11-15 12:16:24.237: E/AndroidProtocolHandler(7351): Unable to open content URL: content://com.android.providers.media.documents/document/image%3A59 11-15 12:16:24.247: D/dalvikvm(7351): GC_EXPLICIT freed 31233K, 4% free 16554K/17084K, paused 2ms+2ms, total 25ms 11-15 12:16:24.247: D/Whitelist(7351): Unlimited access to network resources 11-15 12:16:24.247: I/CordovaLog(7351): Found start page location: index.html 11-15 12:16:24.247: I/CordovaLog(7351): Changing log level to DEBUG(3) 11-15 12:16:24.247: D/CordovaActivity(7351): Resuming the App 11-15 12:16:24.247: D/CordovaActivity(7351): CB-3064: The errorUrl is null 11-15 12:16:24.247: D/CordovaLog(7351): file:///android_asset/www/camera/index.html: Line 58 : URL: content://com.android.providers.media.documents/document/image%3A59 11-15 12:16:24.247: I/chromium(7351): [INFO:CONSOLE(58)] "URL: content://com.android.providers.media.documents/document/image%3A59", source: file:///android_asset/www/camera/index.html (58) Looks like there is a new permission: MANAGE_DOCUMENTS: http://developer.android.com/reference/android/Manifest.permission.html#MANAGE_DOCUMENTS I tried to add android.permission.MANAGE_DOCUMENTS to the AndroidManifest.xml but even after doing this, compiling with ADB and installing, I'm still getting the above error and still unable to pick any photos unless I go through the "Gallery" app first. I made sure to set targetSDK=19 which is when this new permission was added. Joe Bowser do you have any ideas on why Android wouldn't be picking up the new permission? Is the problem in DatabaseUtils that I assume is some Android app?
          Hide
          julio cesar added a comment -

          Yeah, the gallery works, the problem is just with the new android 4.4 options

          Show
          julio cesar added a comment - Yeah, the gallery works, the problem is just with the new android 4.4 options
          Hide
          Mike Billau added a comment -

          On Android 4.4, with Cordova 3.x, it looks like the app just doesn't get the image. However, on Cordova 2.x, the app actually will force quit.

          Show
          Mike Billau added a comment - On Android 4.4, with Cordova 3.x, it looks like the app just doesn't get the image. However, on Cordova 2.x, the app actually will force quit.
          Hide
          julio cesar added a comment -

          any updates on this? if you are talking about this on the developer mail list, can you provide us the link?

          Show
          julio cesar added a comment - any updates on this? if you are talking about this on the developer mail list, can you provide us the link?
          Hide
          Joe Bowser added a comment -

          I just tested this with the 2012 Nexus 7 running KitKat, and I get the new file picker, but I'm able to get an image regardless of where I pick it from. This includes photos from Google Plus. Perhaps there's an update between KitKat and KitKat MR1.

          Show
          Joe Bowser added a comment - I just tested this with the 2012 Nexus 7 running KitKat, and I get the new file picker, but I'm able to get an image regardless of where I pick it from. This includes photos from Google Plus. Perhaps there's an update between KitKat and KitKat MR1.
          Hide
          julio cesar added a comment -

          Joe, but did you use the destinationType.FILE_URI?

          If you use the return type destinationType.DATA_URL it works, but if you use return type destinationType.FILE_URI I get AndroidProtocolHandler, unable to open content URL: content://com.android.providers.media.documents

          tested on nexus 5 and nexus 7 2013

          Show
          julio cesar added a comment - Joe, but did you use the destinationType.FILE_URI? If you use the return type destinationType.DATA_URL it works, but if you use return type destinationType.FILE_URI I get AndroidProtocolHandler, unable to open content URL: content://com.android.providers.media.documents tested on nexus 5 and nexus 7 2013
          Hide
          julio cesar added a comment - - edited

          I've been doing more tests and "Recent", "Drive", "Images" and "External Storage"* fail
          "Downloads" works. (tested on a new 3.1 project)

          *To show "External Storage" tap the upper right button -> Settings -> Show advanced devices

          The code I use: http://pastebin.com/337r72aK

          Show
          julio cesar added a comment - - edited I've been doing more tests and "Recent", "Drive", "Images" and "External Storage"* fail "Downloads" works. (tested on a new 3.1 project) *To show "External Storage" tap the upper right button -> Settings -> Show advanced devices The code I use: http://pastebin.com/337r72aK
          Hide
          Mike Billau added a comment -

          2012 Nexus 7 running KitKat installed from https://developers.google.com/android/nexus/images#nakasikrt16o
          Seeing the same thing as julio cesar....
          1. everything works when destinationType = DATA_URL
          2. With destinationType = FILE_URI, I can get images from "Downloads", but any other file picker will return to the app but the image does not appear.
          3. With destinationType = FILE_URI, I can successfully access any image if I go through the "Gallery" app first
          4. I get the same logcat message (posted above) whenever it unsuccessfully returns to mobilespec after trying to get a picture from Recent, Drive, Images, or External Storage.

          Show
          Mike Billau added a comment - 2012 Nexus 7 running KitKat installed from https://developers.google.com/android/nexus/images#nakasikrt16o Seeing the same thing as julio cesar .... 1. everything works when destinationType = DATA_URL 2. With destinationType = FILE_URI, I can get images from "Downloads", but any other file picker will return to the app but the image does not appear. 3. With destinationType = FILE_URI, I can successfully access any image if I go through the "Gallery" app first 4. I get the same logcat message (posted above) whenever it unsuccessfully returns to mobilespec after trying to get a picture from Recent, Drive, Images, or External Storage.
          Hide
          julio cesar added a comment -

          I bug like this was affecting chromium too and they've fixed it.

          More info:
          https://code.google.com/p/chromium/issues/detail?id=278640

          Show
          julio cesar added a comment - I bug like this was affecting chromium too and they've fixed it. More info: https://code.google.com/p/chromium/issues/detail?id=278640
          Hide
          Nick Watson added a comment -

          Definitely having this issue too in Android KitKat 4.4 on my Nexus 5. It launches the file selector. It's ok if I click into gallery and choose the image that way, but selecting any of the files in Documents view does not return the FILE_URI, but a content URL (e.g. content://com.android.providers.media.documents/image:1288)

          Show
          Nick Watson added a comment - Definitely having this issue too in Android KitKat 4.4 on my Nexus 5. It launches the file selector. It's ok if I click into gallery and choose the image that way, but selecting any of the files in Documents view does not return the FILE_URI, but a content URL (e.g. content://com.android.providers.media.documents/image:1288)
          Hide
          Pablo Reyes added a comment - - edited

          Someone found a solution for this?

          i post it in http://stackoverflow.com/questions/20248178/kitkat-error-while-trying-to-load-an-image too but i'm still in the same.

          Show
          Pablo Reyes added a comment - - edited Someone found a solution for this? i post it in http://stackoverflow.com/questions/20248178/kitkat-error-while-trying-to-load-an-image too but i'm still in the same.
          Hide
          Andrew Grieve added a comment -

          Likely this is the same root cause as CB-2432

          Show
          Andrew Grieve added a comment - Likely this is the same root cause as CB-2432
          Hide
          Mike Billau added a comment -

          I followed the suggestion here to force it to always open the Gallery app and that seemed to work as a temporary solution: http://stackoverflow.com/a/20177611/368762

          Andrew Grieve, Joe Bowser, what are the conditions for a ticket to be a blocker? This has workarounds but I don't think we should release a 3.3 "to fix android 4.4 issues" without resolving this.

          I didn't see CB-2432, thanks for pointing that out.

          Show
          Mike Billau added a comment - I followed the suggestion here to force it to always open the Gallery app and that seemed to work as a temporary solution: http://stackoverflow.com/a/20177611/368762 Andrew Grieve , Joe Bowser , what are the conditions for a ticket to be a blocker? This has workarounds but I don't think we should release a 3.3 "to fix android 4.4 issues" without resolving this. I didn't see CB-2432 , thanks for pointing that out.
          Hide
          Joe Bowser added a comment -

          There are no conditions for it to be a blocker. Nothing should block a release short of compile-time failures and security vulnerabilities.

          Show
          Joe Bowser added a comment - There are no conditions for it to be a blocker. Nothing should block a release short of compile-time failures and security vulnerabilities.
          Hide
          Joe Bowser added a comment - - edited

          Also, we're not fixing Android 4.4 issues in this release, we're building against Android 4.4 and turning on Android 4.4 features. We MAY fix issues, but that's not the point of this release.

          Show
          Joe Bowser added a comment - - edited Also, we're not fixing Android 4.4 issues in this release, we're building against Android 4.4 and turning on Android 4.4 features. We MAY fix issues, but that's not the point of this release.
          Hide
          Joe Bowser added a comment -

          The reason we don't block the release for this is because this is a Camera Plugin issue, and not an issue with the core platform. Since plugins are released separately from the actual platform, there is absolutely no reason to block this release.

          Show
          Joe Bowser added a comment - The reason we don't block the release for this is because this is a Camera Plugin issue, and not an issue with the core platform. Since plugins are released separately from the actual platform, there is absolutely no reason to block this release.
          Hide
          Joe Bowser added a comment -

          BTW: We need to properly decode the URI, since it's coming in escaped.

          Show
          Joe Bowser added a comment - BTW: We need to properly decode the URI, since it's coming in escaped.
          Hide
          Joe Bowser added a comment -

          OK, This is true broken-ness!

          KitKat in theory handles these URI's like this:
          content://com.android.providers.media.documents/document/image:3951
          KitKat in practice gives you permission to this URI:
          content://com.android.providers.media.documents/document/image%A3951

          So, if you were to decode the URI and try to access the actual image, you get a permissions error, because that's not what you were given permission to access. These permissions are per document and per intent, so just giving your app MANAGE_DOCUMENTS permission isn't going to fly either. This isn't going to be fixed any time soon, and I don't want broken Android behaviour to hold up our release.

          Show
          Joe Bowser added a comment - OK, This is true broken-ness! KitKat in theory handles these URI's like this: content://com.android.providers.media.documents/document/image:3951 KitKat in practice gives you permission to this URI: content://com.android.providers.media.documents/document/image%A3951 So, if you were to decode the URI and try to access the actual image, you get a permissions error, because that's not what you were given permission to access. These permissions are per document and per intent, so just giving your app MANAGE_DOCUMENTS permission isn't going to fly either. This isn't going to be fixed any time soon, and I don't want broken Android behaviour to hold up our release.
          Hide
          Andrew Grieve added a comment -

          Joe - what you describe seems like expected behaviour to me.

          This is a valid URL:
          content://com.android.providers.media.documents/document/image%A3951

          This is not a valid URL:
          content://com.android.providers.media.documents/document/image:3951

          Maybe I don't understand?

          Show
          Andrew Grieve added a comment - Joe - what you describe seems like expected behaviour to me. This is a valid URL: content://com.android.providers.media.documents/document/image%A3951 This is not a valid URL: content://com.android.providers.media.documents/document/image:3951 Maybe I don't understand?
          Hide
          Mike Billau added a comment -

          I'm going to add a note under Android Quirks for getPicture() documenting this quirk for 4.4 and linking out to the stackoverflow post above as possible solutions. Sound good? When we resolve this we can remove the quirk in the documentation.

          Thanks guys for looking at this. Sorry I don't have anything to add yet but want to do more investigation today.

          Show
          Mike Billau added a comment - I'm going to add a note under Android Quirks for getPicture() documenting this quirk for 4.4 and linking out to the stackoverflow post above as possible solutions. Sound good? When we resolve this we can remove the quirk in the documentation. Thanks guys for looking at this. Sorry I don't have anything to add yet but want to do more investigation today.
          Hide
          Mike Billau added a comment -

          Pull request for the quick here: https://github.com/apache/cordova-docs/pull/163

          Show
          Mike Billau added a comment - Pull request for the quick here: https://github.com/apache/cordova-docs/pull/163
          Hide
          Joe Bowser added a comment -

          Andrew Grieve I think we agree on what a valid URL is:

          This is valid, but is rejected by Android as invalid: content://com.android.providers.media.documents/document/image%A3951
          This is invalid, but gives a security error: content://com.android.providers.media.documents/document/image:3951

          The first URL has the READ permission passed back, which is correct. Since we don't have permissions to do anything with the invalid (yet correct according to StackOverflow) URI, we can't access this. This wouldn't be the first time a URI encoding bug broke something on Android.

          Show
          Joe Bowser added a comment - Andrew Grieve I think we agree on what a valid URL is: This is valid, but is rejected by Android as invalid: content://com.android.providers.media.documents/document/image%A3951 This is invalid, but gives a security error: content://com.android.providers.media.documents/document/image:3951 The first URL has the READ permission passed back, which is correct. Since we don't have permissions to do anything with the invalid (yet correct according to StackOverflow) URI, we can't access this. This wouldn't be the first time a URI encoding bug broke something on Android.
          Hide
          Andrew Grieve added a comment -

          Gotcha! Thanks for the clarification.

          Show
          Andrew Grieve added a comment - Gotcha! Thanks for the clarification.
          Hide
          ASF subversion and git services added a comment -

          Commit 9b42839124026c7ed65ae57910927ebd99a580b4 in branch refs/heads/master from Mike Billau
          [ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=9b42839 ]

          CB-5398 Add Android 4.4 quirk about StorageAccessFramework

          Show
          ASF subversion and git services added a comment - Commit 9b42839124026c7ed65ae57910927ebd99a580b4 in branch refs/heads/master from Mike Billau [ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=9b42839 ] CB-5398 Add Android 4.4 quirk about StorageAccessFramework
          Hide
          Mike Billau added a comment -

          Still broken in 4.4.2.
          Should we file a bug against Android since this is a URI encoding bug and pretty different than the one posted earlier in the thread?

          Show
          Mike Billau added a comment - Still broken in 4.4.2. Should we file a bug against Android since this is a URI encoding bug and pretty different than the one posted earlier in the thread?
          Hide
          Nick Watson added a comment -

          It would be nice if by default behaviour, the gallery was launched and not the file picker

          Show
          Nick Watson added a comment - It would be nice if by default behaviour, the gallery was launched and not the file picker
          Hide
          julio cesar added a comment -

          AFAIK, you can't force to launch the gallery

          Show
          julio cesar added a comment - AFAIK, you can't force to launch the gallery
          Hide
          Yahor Kazlou added a comment - - edited

          Did anyone solve this problem?

          Show
          Yahor Kazlou added a comment - - edited Did anyone solve this problem?
          Hide
          Mike Billau added a comment -

          Joe Bowser, can you please explain how you were able to determine that the first URI "has the READ permission passed back to it"? I couldn't find a bug report for this on the Android tracker and would like to file it but I'm not sure if I understand enough to actually file a decent bug report.

          Show
          Mike Billau added a comment - Joe Bowser , can you please explain how you were able to determine that the first URI "has the READ permission passed back to it"? I couldn't find a bug report for this on the Android tracker and would like to file it but I'm not sure if I understand enough to actually file a decent bug report.
          Hide
          Joe Bowser added a comment -

          I used the debugger to check what the intent was returning. You could also throw console.logs in as well to see what the string is when you get it out. It should be on line 397 in the CameraLauncher.java app, in the onActivityResult method.

          In other news, we should refactor this plugin. The methods are too large.

          Show
          Joe Bowser added a comment - I used the debugger to check what the intent was returning. You could also throw console.logs in as well to see what the string is when you get it out. It should be on line 397 in the CameraLauncher.java app, in the onActivityResult method. In other news, we should refactor this plugin. The methods are too large.
          Hide
          Joe Bowser added a comment - - edited

          Actually, you should just run mobile-spec and look at the URI that's passed back. That shows the encoding error

          Show
          Joe Bowser added a comment - - edited Actually, you should just run mobile-spec and look at the URI that's passed back. That shows the encoding error
          Hide
          Mike Billau added a comment -

          I'm trying to figure out where in Android there is a URI encoding bug so that we can report it and have the problem fixed upstream.

          However, I'm starting to think maybe we need to make some changes to incorporate the new Storage Access Framework...more specifically, checking different ContentProviders. I was able to implement the solution here: http://stackoverflow.com/a/20559175/368762 and it seems to work well for accessing images from all of the providers except for Drive. The new way of doing things seems to craft the URI based on which provider the data came from instead of just assuming uri = intent.getData() will be valid.

          Show
          Mike Billau added a comment - I'm trying to figure out where in Android there is a URI encoding bug so that we can report it and have the problem fixed upstream. However, I'm starting to think maybe we need to make some changes to incorporate the new Storage Access Framework...more specifically, checking different ContentProviders. I was able to implement the solution here: http://stackoverflow.com/a/20559175/368762 and it seems to work well for accessing images from all of the providers except for Drive. The new way of doing things seems to craft the URI based on which provider the data came from instead of just assuming uri = intent.getData() will be valid.
          Hide
          Joe Bowser added a comment -

          You can file the bug, but it won't be looked at, mostly because the Android Team doesn't read its own Bug Tracker.

          Also, the bug is this: You're magically supposed to get a photo by using this URL: content://com.android.providers.media.documents/document/image:3951, but since the URI is encoded, it looks like this: content://com.android.providers.media.documents/document/image%A3951. Their goofy new URI system that doesn't use proper URIs is what's broken. They need to accept the proper encoding to get their photos.

          Show
          Joe Bowser added a comment - You can file the bug, but it won't be looked at, mostly because the Android Team doesn't read its own Bug Tracker. Also, the bug is this: You're magically supposed to get a photo by using this URL: content://com.android.providers.media.documents/document/image:3951, but since the URI is encoded, it looks like this: content://com.android.providers.media.documents/document/image%A3951. Their goofy new URI system that doesn't use proper URIs is what's broken. They need to accept the proper encoding to get their photos.
          Hide
          ASF subversion and git services added a comment -

          Commit 954a1723f1c0ebc432c68facfbda7975027554a2 in branch refs/heads/master from Andrew Grieve
          [ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=954a172 ]

          CB-5398 Work-around for KitKat content: URLs not rendering in <img> tags

          Show
          ASF subversion and git services added a comment - Commit 954a1723f1c0ebc432c68facfbda7975027554a2 in branch refs/heads/master from Andrew Grieve [ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=954a172 ] CB-5398 Work-around for KitKat content: URLs not rendering in <img> tags
          Hide
          Andrew Grieve added a comment -

          Finally got around to looking at this. Looks to be fixed just by reading the content: on the native side.

          Show
          Andrew Grieve added a comment - Finally got around to looking at this. Looks to be fixed just by reading the content: on the native side.
          Hide
          Ian Clelland added a comment -

          Andrew – the %3A may not be a sufficient indicator for this – I've seen other providers using different strings; Drive, for instance, encodes a string like "acc=1;doc=12345678" as "acc%3D1%3Bdoc%3D12345678".

          I think in general, all URLs using the content:// scheme may have to have their entire path decoded, or at least subject to remapping, as you've done.

          Show
          Ian Clelland added a comment - Andrew – the %3A may not be a sufficient indicator for this – I've seen other providers using different strings; Drive, for instance, encodes a string like "acc=1;doc=12345678" as "acc%3D1%3Bdoc%3D12345678". I think in general, all URLs using the content:// scheme may have to have their entire path decoded, or at least subject to remapping, as you've done.
          Hide
          ASF subversion and git services added a comment -

          Commit 7741312673e36607f4c985b538f07105e84ae0b8 in branch refs/heads/master from Andrew Grieve
          [ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=7741312 ]

          CB-5398 Apply KitKat content URI fix to all content URIs

          Show
          ASF subversion and git services added a comment - Commit 7741312673e36607f4c985b538f07105e84ae0b8 in branch refs/heads/master from Andrew Grieve [ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=7741312 ] CB-5398 Apply KitKat content URI fix to all content URIs
          Hide
          Andrew Grieve added a comment -

          Thanks Ian. I've modified it to apply to all content: URIs

          Show
          Andrew Grieve added a comment - Thanks Ian. I've modified it to apply to all content: URIs
          Hide
          Mike Billau added a comment -

          Thanks for looking at this!
          I've been testing the update and it all seems good, I can access images from any source now, no matter what I set the destination_type to.
          I did see that sometimes pulling an image from Drive with data_url will cause the app to quit with an Out Of Memory error, even when the same image can be opened with destination_type=file_uri. I can't reproduce this reliably though, I think it might be the known issue of the Camera app shutting down.

          Show
          Mike Billau added a comment - Thanks for looking at this! I've been testing the update and it all seems good, I can access images from any source now, no matter what I set the destination_type to. I did see that sometimes pulling an image from Drive with data_url will cause the app to quit with an Out Of Memory error, even when the same image can be opened with destination_type=file_uri. I can't reproduce this reliably though, I think it might be the known issue of the Camera app shutting down.
          Hide
          ASF subversion and git services added a comment -

          Commit 5211319f41c46ee287259ba6a48a3a3bc42fb95d in cordova-amazon-fireos's branch refs/heads/master from Andrew Grieve
          [ https://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;h=5211319 ]

          CB-5398 Work-around for KitKat content: URLs not rendering in <img> tags

          Show
          ASF subversion and git services added a comment - Commit 5211319f41c46ee287259ba6a48a3a3bc42fb95d in cordova-amazon-fireos's branch refs/heads/master from Andrew Grieve [ https://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;h=5211319 ] CB-5398 Work-around for KitKat content: URLs not rendering in <img> tags
          Hide
          ASF subversion and git services added a comment -

          Commit d4224e1098ae447a01ad22542b43c9866115d9fb in cordova-amazon-fireos's branch refs/heads/master from Andrew Grieve
          [ https://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;h=d4224e1 ]

          CB-5398 Apply KitKat content URI fix to all content URIs

          Show
          ASF subversion and git services added a comment - Commit d4224e1098ae447a01ad22542b43c9866115d9fb in cordova-amazon-fireos's branch refs/heads/master from Andrew Grieve [ https://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;h=d4224e1 ] CB-5398 Apply KitKat content URI fix to all content URIs
          Hide
          Ian Clelland added a comment -

          Well, Data-URLs can be very large; I don't recall what the internal representation of strings in WebKit is; but a base64 representation is at least 133% the size of the source; 266% if it's represented in UCS-2. I wouldn't be surprised at all if a file which technically could fit in RAM would cause an OutOfMemory exception if it were converted to a base64 string and then passed across the bridge.

          Show
          Ian Clelland added a comment - Well, Data-URLs can be very large; I don't recall what the internal representation of strings in WebKit is; but a base64 representation is at least 133% the size of the source; 266% if it's represented in UCS-2. I wouldn't be surprised at all if a file which technically could fit in RAM would cause an OutOfMemory exception if it were converted to a base64 string and then passed across the bridge.
          Hide
          Mateusz Wielgos added a comment -

          This issue is marked as resolved, but I am having problems. I am having this issue on Android 4.4.2. I am using latest cordova-cli, cordova-android, cordova-plugin-file-transfer and cordova-plugin-file from master branches.

          For navigator.camera.getPicture, I tried to use both NATIVE_URI and FILE_URI.

          FileTransfer error callback gets called. Looking at FileTransferError properties, they are as follows:
          code: null
          source: null
          target: null
          http_status: null

          The image URI passed in, with camera.DestinationType.NATIVE_URI is : content://com.android.providers.media.documents/document/image%3A85 . The image URI passed in, with camera.DestinationType.FILE_URI is exactly the same.

          I can't go the DATA_URL route as Android 4.0-4.3 support for Blob XHR is non-existent, see : https://code.google.com/p/android/issues/detail?id=39882 .

          Tried the same thing on Android 4.2.2, no issues.

          Ideas / help?

          Thanks!

          Show
          Mateusz Wielgos added a comment - This issue is marked as resolved, but I am having problems. I am having this issue on Android 4.4.2. I am using latest cordova-cli, cordova-android, cordova-plugin-file-transfer and cordova-plugin-file from master branches. For navigator.camera.getPicture, I tried to use both NATIVE_URI and FILE_URI. FileTransfer error callback gets called. Looking at FileTransferError properties, they are as follows: code: null source: null target: null http_status: null The image URI passed in, with camera.DestinationType.NATIVE_URI is : content://com.android.providers.media.documents/document/image%3A85 . The image URI passed in, with camera.DestinationType.FILE_URI is exactly the same. I can't go the DATA_URL route as Android 4.0-4.3 support for Blob XHR is non-existent, see : https://code.google.com/p/android/issues/detail?id=39882 . Tried the same thing on Android 4.2.2, no issues. Ideas / help? Thanks!

            People

            • Assignee:
              Mike Billau
              Reporter:
              julio cesar
            • Votes:
              4 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development