Can you please describe exactly what method call you're making on ExifInterface? I would expect this to work for exifInterface.setAttribute(TAG_EXPOSURE_TIME, "1/1600") but not exifInterface.setAttribute(TAG_EXPOSURE_TIME, "0.000625").

Thanks, I think part of the cause of the problem you're seeing is that exifInterface.getAttribute(TAG_EXPOSURE_TIME) is returning "6.25E-4" while setAttribute(TAG_EXPOSURE_TIME, value) is ideally expecting "1/1600".

Turns out there is code to handle the case of passing a decimal string to setAttribute, by converting it to a Rational representation of { int numerator, int denominator }, but it (arbitrarily) only handles up to 5 decimal places:

Rational(double value) {
  this(/* numerator= */ (long) (value * 10000), /* denominator */ 10000);
}

It looks like this code has been present for a long time, seems it was present in the original in framework implementation of ExifInterface added in 2016.

So I think there's an obvious improvement we can make here:

• Fix the double -> Rational conversion to support more precision. Ideally we would first try a denominator of 1 / value (since this would give an exact result in the case of this bug, and probably most other cases since shutter speeds that are less than 1 are usually 1/something), something like:

  
  Rational createRationalFromDouble(double value) {
    double inverse = 1 / value;
    if (isMathematicalInteger(value)) {
      return new Rational(1, (long) inverse);
    }
    // Not sure what we can do here
  }
  

  For the else case, maybe we could do something clever with continued fractions: https://en.wikipedia.org/wiki/Continued_fraction

It feels like we should also align the format that getAttribute returns with the format setAttribute expects, in order to explicitly support the copying use-case you've described. That would mean changing getAttribute to return "1/1600" in this case. Unfortunately that is a breaking change for any existing code that is doing Double.parseDouble(exifInterface.getAttribute(TAG_EXPOSURE_TIME)), so not feasible. If we were to introduce this it would need to be a separate method.

it would be useful to have an API with which one could copy all EXIF data directly from one file to another

This request is tracked by https://issuetracker.google.com/169916206.

There's another curiosity here: Some 'unsigned rational' tags are returned from getAttribute(String) in the form "x/y", e.g. TAG_FOCAL_LENGTH. I dug a bit into this, and I think the 'automatically convert to floating point' behaviour was originally introduced in the framework version of ExifInterface (which existed before the AndroidX one was forked from it) as part of this commit in 2016. It looks like the concern then (as now) was maintaining compatibility with apps expecting the decimal format. There's a bit more context in this internal-only code review comment.

Given the constraint of maintaining this lossy format going forward:

ExifInterface already has 'different type' getAttributeXXX(...) 'overloads' like getAttributeInt(...). Given these already exist, we could consider adding add a @Nullable String getAttributeRational(String) that returns the "x/y" format for tags with TYPE = (Unsigned) rational. People would have to know to use it instead of getAttribute(String), but it at least gives 'lossless' access to the actual tag data read from the file - even for rational tags that are converted to lossy decimal/floating-point representations for backwards-compatibility..