Fix COPY string computation in exact case
Bug: 26175989
Bug: 33458621
Fix the determination of whether the currently displayed result is
already exact. The old logic failed to deal with the odd corner
case in which we force an initial scientific notation display because
we don't have room for digit separators.
When we recompute the exact result as part of a copy operation,
and the exact result is an integer, do not add a trailing decimal
point.
Change-Id: I3f673fc428cf6982eeaf6aa1037b9f522ea2d6f9
diff --git a/src/com/android/calculator2/UnifiedReal.java b/src/com/android/calculator2/UnifiedReal.java
index cb8a512..7f4bfc8 100644
--- a/src/com/android/calculator2/UnifiedReal.java
+++ b/src/com/android/calculator2/UnifiedReal.java
@@ -366,6 +366,7 @@
* Returns a truncated representation of the result.
* If exactlyTruncatable(), we round correctly towards zero. Otherwise the resulting digit
* string may occasionally be rounded up instead.
+ * Always includes a decimal point in the result.
* The result includes n digits to the right of the decimal point.
* @param n result precision, >= 0
*/