IssueTracker

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3328184

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling 
 
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component. 
 
Fixes: b/266550551 
Fixes: b/204650733 
Fixes: b/255554340 
Fixes: b/229537244 
Test: OverscrollTest 
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering  overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere." 
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.8.0-alpha06
• androidx.compose.foundation:foundation-android:1.8.0-alpha06
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06

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..

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.exifinterface:exifinterface:1.4.0-alpha01