New "add image to note" feature in Android, not working for me.

[mptpro]

This is a follow-up to ZenNotes/zennotes#690 (comment)

Thanks for the quick addition to this feature. However, it's not working for me. What happens is that when I use the button to add an image (or PDF), the code shows-up in the note, and the image file is added to /assets, but the image is corrupted or just doens't show. The image file does get transferred to my Docker instance of ZN but even when I open the image directly from the Assets folder it doesn't display.

thanks

[adibhanna]

Found it, and thanks for the detail: "the image file is added to /assets, but the image is corrupted" was the clue that mattered, because it ruled out the file going missing and pointed straight at the bytes.

The upload built its multipart request by hand and labelled the file part Content-Transfer-Encoding: base64. That header is an email (MIME) construct: RFC 7578 removed it from multipart/form-data, and the Go server's parser ignores it. So the server took the base64 text and wrote it to disk as the file's contents. That is why it had the right name and landed in the right folder, was about a third larger than the original, and would not open anywhere, including straight from the Assets folder, and why it synced to your Docker instance in that broken state.

The bytes have to be base64 to cross from the web layer into the native layer at all, so the fix is not to stop using base64 but to use Capacitor's supported formData upload, where the native code decodes the base64 and writes the real bytes into the request. The app already did exactly this for its other upload path.

I checked it against a real ZenNotes server rather than assuming. Same PNG, both request shapes:

upload	stored on disk	starts with	matches the original
old	638,352 bytes	iVBORw0K (base64 text)	no
new	478,762 bytes	\x89PNG	yes, identical checksum

Fix is in #41, and the same fix goes to the iOS app since it shares this code.

Two things worth knowing:

• Attachments you have already added are still corrupt on disk; they need adding again after you update. Deleting the broken ones from assets/ is safe.
• The same PR fixes a second, unrelated bug in that button for people not using a server: on a local vault it was writing attachments to the vault root instead of assets/.

Closing this as fixed. Please reopen if you still see a bad file after the next build, ideally with the file size next to the original's, since that ratio tells us immediately whether it is this bug again.

[mptpro]

Thanks for all your effor @adibhanna , unfortunately it is still not working for me.

• android v1.1.12

When i adding a completely new image I have them same issue.

On my phone the image "burger" has a size of 2.8 MB

. . .

When opening the image within android Zennotes / Assets, I get this:

And this is what it looks like in the note: (the last entry'):

After syncing to my Linux desktop, the file size of "burger" is different (3.6mb vs size on phone: 2.8 mb)

And this is what i see when i open the image in linux Zennotes: