IssueTracker

Exif data is stored in a JPEG APP1 segment which has max size of 2^16 = 65536 bytes.

Some devices (e.g. Samsung A32) create images with quite large embedded thumbnails that take up nearly all these bytes [1]. When we then try and save additional exif data we currently produce a corrupt jpeg file (version 1.3.6). The short-term fix for that bug avoids the corruption by throwing an exception from saveAttributes instead.

When experimenting with exiftool to recreate the same problem, it adds a second APP1 segment. We could investigate adding similar behaviour to ExifInterface. Before we do this we need to understand how well supported this file structure is across the ecosystem. It would also require significant rearchitecting of ExifInterface because the logic it uses to lay out the structure of the the APP1 segment is quite complicated, and not 'aware' of splitting into multiple segments.

[1] The Samsung A32 in particular seems to always create a 64,000 byte thumbnail, no matter what the content of the image is, whereas all other devices I tested (several other Samsungs & Pixel 5) produce different size thumbnails for different images (which makes sense, since jpeg compression is heavily content-dependent).