Working with Kim and Android ContentResolver

[ravenfeld]

I found that on some phones I didn't have to use the path directly but use contentResolver to work with the files.
It works well for read, there is AndroidInputStreamByteReader.
But for the updateExifMetadataLossless I have outOfMemory problems. I'm trying to update the same file and maybe that's the problem.
Has anyone tried to do this?
Thank you

[StefanOltmann]

Hi,

Thanks for reaching out.

How large is the file you're trying to update? Can you share an example?

To update the file, its bytes must fit twice into the heap memory. The logic in updateExifMetadataLossless(), derived from Apache Commons Imaging, involves creating a list of JFIFPiece objects in heap memory that store all the bytes. Some of these bytes are modified before being reassembled into new byte arrays, which are then written out.

At one point, both the original and modified bytes exist in heap memory. If your JPG is around 20 MB, this can be problematic, especially on Android devices.

Ideally, I’d like to rewrite this logic to manipulate a stream directly - avoiding large byte arrays in heap memory - while also enabling simultaneous updates to EXIF, IPTC, and XMP metadata.

However, my initial focus was on understanding the file formats and converting Apache Commons Imaging 1:1 to Kotlin was a safe way to use tried & tested logic in production.

Now, it’s a matter of finding the time amid other priorities. The recent library changes were all related to new features in Ashampoo Photo Organizer.

I hope this helps clarify things.

Best regards,

Stefan

[ravenfeld]

So the addTag method doesn't work on Android 10 or I have to use contentResolver and not the ByteArrayByteWriter and KotlinIoSourceByteReader as before.

I only make one file.

I think my problem is that I'm giving 2 feeds that are on the same file at the same time but I don't know enough to know.

Because getByteWriter and getByteReader I give them the same URI

[StefanOltmann]

Indeed, I did not test KotlinIoSourceByteReader on Android so far. It's possible that kotlinx-io doesn't work on Android 10. What exception do you get here?

The whole reason AndroidInputStreamByteReader exists extra is because InputStream.readNBytes(count) does not exist on older Android API and the data is read into a buffer.

I recommend using JvmInputStreamByteReader or kotlinx-io on supported Android versions and fall back to AndroidInputStreamByteReader for older versions. I'm pretty sure that this is not memory efficient, but I don't have a better idea.

I'm not sure if using the same URL is the problem here.

First you read from that URL and stream into a ByteArrayByteWriter, then you close the file input stream, then you open a new output stream. That should be fine.

The only issue is that it's a lot of copies of full blown file bytes in memory. I'm sorry that I don't have a better API for that.

I do something similar on Android (with the code I posted above), but I did not have out-of-memory issues with it so far. However, it's safe to say that it's not efficient.

On JVM desktop I stream into a separate file and perform a kotlinx-io atomicMove operation afterwards. That reduces memory pressure.

[ravenfeld]

My problem is linked to the fact that my images are on the public external and I don't really know why but I can only read them with contentResolver on an Android 10 phone.
I'm going to try your technique with the bytes to see if it works.

[ravenfeld]

So I managed to make it work, here's my PR for my code.

https://gitlab.com/ravenfeld/baba/-/merge_requests/82

What interests you is KimExt.kt and FileSystemServiceImpl.kt

For Android 9 and then for all of them, I had to use ByteArrayByteWriter() because I couldn't use update or updateExifMetadataLossless. The phones were spitting without a message.

In FileSystemServiceImpl, you can find my Reader and Writer that I use for Android

In any case, thank you very much for your lib, which allows me to manipulate exifs very easily.

[StefanOltmann]

Thank you for your feedback and for sharing your solution! 🚀

I'm glad to hear that you resolved the issue and like my library! 😊

[ravenfeld]

I'm going to try to motivate myself to offer you a PR so that others can get the reader and writer for Android.

I'd also like to understand why I have to use ByteArrayByteWriter(), which doesn't seem logical to me.