I'm trying to get the local path of a image in order to upload it to a server. When using pre ICS it would get a standard path within the android device via getRealPathFromURI(theURI)
However with ICS URI will contain a uriString as something like : content://com.google.android.gallery3d.provider/picasa/item/12312312312312.
and running getRealPathFromURI(theURI) returns null
Do I now need to extract the above uriString and manually download the image via the API (if i detect that its a Picasa gallery image) rather than one locally stored? or am I completely missing something?
thanks for any advice
EDIT:
seems i was searching on the wrong question...
found the problem in the below link... which is pretty much what I expected I'd need to do. Pretty annoying google/android didn't handle this more elegantly.
To properly handle fetching an image from the Gallery you need to handle three scenarios:
The user selected a local image file
The user selected a Picasa image and the device is running Android version prior to 3.0
The user selected a Picasa image and
the device is running Android version 3.0 and higher
http://dimitar.me/how-to-get-picasa-images-using-the-image-picker-on-android-devices-running-any-os-version/
That's what I found out on device running Android 4.0+.
The ICS URI you gave as an example is an URI with content:// scheme, so there should be a ContentProvider responsible for that.
Hence, what is the use of that tricks getRealPathFromURI() uses? Just let ContentResolver do this work for you:
InputStream inStream = getContentResolver().openInputStream(theUri);
Bitmap bitmap = BitmapFactory.decodeStream(is);
Related
We have some old issues with similar words, but most of them are about converting one or the other.
What I'm looking here is the "Right" behaviour of URI usage with the new changes. Let me give some context:
Before when we get an image URI this would return file://... format.
But since the new OS permissions changes, where we should not use WRITE_EXTERNAL_STORAGE anymore we should use getUriForFile(..) that return content://... path.(Scope Storage usage Android 11 Storage FAQ)
This can be spot on some Android guides, like: taken photos guide
The "problem" is that many users got used to use the URI of a crop image (for example) to create a file of it and save it.
Now, with this changes come the question:
How should we use the URI?
Make some code to check Android version and if more than 29 we should create a new file path for the URI?
Let the URI be the path to the image (content of file) and if someone wanna save it would need to create it own file path
Something else that I don't get yet about how to use URI right.
Obs: Asking this, because of a Android Image Crop open source project handover, where we need to upgrade the permissions for Android 10/11 but now we have this content/file issue. More here
Edit:
As pointed on the comments
Code returning file:// (not valid anymore since the changes)
Uri outputFileUri = null;
outputFileUri = Uri.fromFile(
new File(context.getExternalCacheDir().getPath(),
"pickImageResult.jpeg")
);
Code returning content://
outputFileUri = FileProvider.getUriForFile(
context,
context.getPackageName() + CommonValues.authority,
File.createTempFile("pickImageResult", ".jpeg", getImage)
);
The "problem" is that many users got used to use the URI of a crop image (for example) to create a file of it and save it.
In the end, this is your library, and you need to document what any Uri that you return is suitable for. After all, a Uri could point to:
A file on the filesystem (file)
A Web resource (https, or possibly http)
An Android resource (android.resource)
An asset in the app (file://android_asset)
Some arbitrary set of bytes (content)
Your library is for image cropping. While I have not examined the implementation, I assume that it all works inside the app itself. If so, there is nothing wrong with returning a file Uri, if you want to do so. Your code is writing a file somewhere (e.g., getCacheDir() on Context). The app using your library must have access to that file, or else you would have crashed trying to write it. A Uri created via Uri.fromFile(), for that file, is perfectly fine... in that app.
Where Uri.fromFile() becomes a problem is in passing the Uri to another app. However, your library is for cropping images, not sharing content with other apps. Your job, IMHO, is to give a cropped image back to the app. What the app does with it is up to that app, subject to whatever limitations there are in the Uri that you hand over.
The two options that you seem to be considering have different issues:
Uri Source
Advantages
Disadvantages
Uri.fromFile()
Cheap, easy
Can only be used within the app itself; cannot be passed to other apps
FileProvider
Uri can be passed to other apps
Requires a library and manifest configuration; cannot readily get to the underlying file
Since IMHO an image cropper is not an image sharing solution, Uri.fromFile() seems reasonable. If the app using your library wants to turn around and share the cropped image, they would set up FileProvider themselves and use FileProvider.getUriForFile(). The only catch is that either you need to document where the file will be written or give them an option to tell you what directory to use — that information will be needed to set up the FileProvider metadata.
Someday, if you elect to change the API, you might consider returning an ordinary File instead of a Uri. That way, there is no confusion about what it represents.
But, in the end, this is all your decision. If you want to use FileProvider, or you want to upload images to your own Web server and use https, that is all up to you. However, you should document what you are doing and what the Uri represents.
Can't find any direct reference to the problem online. I've created an Azure function to create thumbnails using the cognitive services tool (following the guide at https://www.hackster.io/achindra/azure-function-apps-running-custom-code-on-blob-insertion-d71aba and only modifying it to use the EASTUS location instead of projectoxford). All works find and dandy, but I have found that whilst all thumbnails come back marked application/octet-stream (all originals are image/jpeg), only those that were taken on any of: DSLR, Windows Phone, iOS device are usable and work both as images on a website or in photos app on the computer. However all photos taken with an Android phone (well, all the ones I have tested so far!) come back with a file format that is not supported. They are .jpg, and have content type of application/octet-stream as do the other thumbnails. Any bright ideas gratefully received.
The Microsoft Cognitive Vision APIs do not accept images larger than 4MB. It will return a InvalidImageSize error when you do.
The general advice is to downscale the image on the client before posting it to the API if your images are larger.
try to avoid the loss of image data during a running download from my server via a Fresco ImageRequest.
Everything runs perfect, but if the connection fails (interruption of network connectivity), the image is gone. But as I know, some Scans has been decoded (LogCat -> Intermediate image received!). But how to access them? Is there a way to save every single Scan in a seperate file? To access the latest version, if the phone goes offline?
Thx!
Fresco doesn't fully support this functionality. Please file an issue on GitHub.
I'm working on the Android version of an app I did for iOS. I have some files (could be PDF, DOC, PNG, etc) in cloud storage and I retrieve them using an ASPX handler (like http://www.myserver.com/GetFile?name=test.png).
The goal is to DISPLAY ONLY, not download the files.
In iOS I used a UIWebView and it would download and preview the file as long as the OS could handle that file type.
What is the best approach for Android? I've tried the following:
WebView and embedding in google docs (http://docs.google.com/gview?embedded=true&url=) - DOES NOT WORK FOR PNG
Launching a new Activity using myIntent.setDataAndType(myFileURI, myFileMIME); where myFileMIME = MimeTypeMap.getSingleton().getMimeTypeFromExtension(myFileTypeExtension). For PNGS I get "No activity for type image/png"
I think you can try DownloadManager for this.
The second option is a better way for Android, after fetching the file from cloud.
Use MimeType as "image/*", which usually works for all images and opens in default gallery.
So what I've ended up doing is classifying the MIME type as shown above. If the type is "image/*" then I display the image directly in a WebView.
If the type is "application/*" then I embed it in google docs using the 1st method, and display it in the WebView.
Still looking for a better solution.
I am trying to open an image/picture in the Gallery built-in app from inside my application as described in here.
My "picker" activity works fine as long as the image is stored in the device, but the gallery app also displays images from Picassa, which returns a null path.
Does anyone knows how to fix this, either by getting the path or tell the "picker" intent to ignore Picassa as a provider, and only show me what is on my device?
Thanks.
I had this same problem here
What I did was just check the returning Uri to see if the selected image was a picassa image. probably not the best option but it works since there is no way to tell the image picker what images to show