TextView causes NPE in StaticLayout [36931937]

Obsolete

Bug

[AOSP] assigned

[AOSP] Version-2.3

Status Update

No update yet.

Description

zv...@gmail.com

created issue #1

Aug 11, 2011 02:45AM

This happens on screen rotate:

TextView.onAttachedToWindow() calls showError() when mShowErrorAfterAttach is set to true. showError() calls chooseSize(), which, in turn, instantiates a StaticLayout calling its first constructor. This constructor cannot handle <null> for its "source" argument and throws an NPE trying to retrieve its length.

The <null> "source" comes from the setError(null), which is the documented way of clearing the error, so this should never throw an NPE.

There is no good work around as it happens every time when the circumstances are right. The only fix I could come up with is check the Window Token == null and not call setError(), but this may have some undiserable effects.

Below is the stack trace as reported by a Nexus One running 2.3.4:

FATAL EXCEPTION: main
java.lang.NullPointerException
at android.text.StaticLayout.<init>(StaticLayout.java:45)
at android.widget.TextView.chooseSize(TextView.java:3472)
at android.widget.TextView.showError(TextView.java:3370)
at android.widget.TextView.onAttachedToWindow(TextView.java:3784)
at android.widget.AutoCompleteTextView.onAttachedToWindow(AutoCompleteTextView.java:1063)
at android.view.View.dispatchAttachedToWindow(View.java:6156)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:1127)
at android.view.ViewRoot.performTraversals(ViewRoot.java:765)
at android.view.ViewRoot.handleMessage(ViewRoot.java:1859)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:130)
at android.app.ActivityThread.main(ActivityThread.java:3683)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)

Comments

ro...@android.com <ro...@android.com> Aug 11, 2011 06:29PM

Assigned to gi...@android.com.

ta...@gmail.com <ta...@gmail.com> #2Sep 29, 2011 06:29AM

Argh....with this bug there is absolutely no way to determine if the user has changed changed the panning of the map....I need a way to determine this so that i can allow the user to reset the map to it's original view. Please fix this ASAP.

kf...@gmail.com <kf...@gmail.com> #3Jun 9, 2012 06:59AM

I have another example regarding the problematic accuracy of moveCamera/animateCamera.
When you use CameraUpdateFactory.newLatLngBounds(), moveCamera and animateCamera result in different values in map.getProjection().getVisibleRegion().latLngBounds.

LatLngBounds bounds = new LatLngBounds(new LatLng(40.70798493778415, -74.01434069136418), new LatLng(40.72072004852845, -73.99760391411343));
if (animate) {
map.animateCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0),
} else {
map.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0));
}

map.getProjection().getVisibleRegion().latLngBounds :
after animateCamera -
LatLngBounds{southwest=lat/lng: (40.70711197865251,-74.01539381593466), northeast=lat/lng: (40.72159253556309,-73.99655096232891)}
after moveCamera -
LatLngBounds{southwest=lat/lng: (40.70798500292429,-74.01539381593466), northeast=lat/lng: (40.72071968970514,-73.99655096232891)}

This is pretty important for my design as im calculating a search radius (Vincenty’s formula) by the bounds of the map. appreciate if you could confirm the accuracy of those 2 APIs.

deleted

Restricted

0 B

kf...@gmail.com <kf...@gmail.com> #4Sep 8, 2012 07:39AM

Another example :

http://stackoverflow.com/questions/17909767/googlemap-movecamera-or-animatecamera-according-to-latlngbounds-is-not-accurate/18103614#18103614

ya...@gmail.com <ya...@gmail.com> #5Jun 17, 2013 09:29AM

any news regarding this issue ?

ya...@gmail.com <ya...@gmail.com> #6Jun 17, 2013 05:44PM

I can share my thoughts about it.

LatLng is keeping doubles, when these are sent via IPC, they are flattened to floats, because there is no writeDouble:

http://developer.android.com/reference/android/os/Parcel.html#writeFloat%28float%29.
When going back, you lose precision and thus errors on 4-5th decimal place.

If I'm correct here, this can be hard (if possible) to fix without breaking compatibility.

[Deleted User] <[Deleted User]> #7Jun 6, 2014 06:37PM

If you're right then compatibility doesnt have to be broken in order to pass a more accurate LatLng value in many other parcelable types which are not float. This option can be added and not replace the current one.
I any case this issue is really annoying and i hope someone from google can take a look at it. Thanks.

sa...@google.com <sa...@google.com> #8May 19, 2020 03:03PM

Status: Won't Fix (Obsolete)

If I'm right then you are also right. ;)

Double values in LatLng could be sent using writeLong after converting them using Double.doubleToLongBits (

http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#doubleToLongBits%28double%29) and converted back to double in Google Play Services app.