Espresso Test freezes when Use Host GPU is enabled - android

I have a series of Espresso tests that test a slide menu. The majority of the tests fail when Use Host GPU is turned on, but not when it is disabled. Even though I have disabled animations, I think I might be missing a setting somewhere because I can still see the window sliding open. I am testing Android 4.4.2 and using HAXM. Why does this test fail?
Here's one example of a test (they all have the same structure):
#SuppressWarnings("unchecked")
public void testClickOnItemDisplaysMyFragment() {
openDrawer(DRAWER);
onView(withId(DRAWER)).check(matches(isOpen()));
onView(allOf(withId(DRAWER_ITEM), withText(MY_ITEM))).perform(click());
onView(withId(DRAWER)).check(matches(isClosed()));
Fragment fragment = fragmentManager.findFragmentById(FRAGMENT_LAYOUT);
assertThat(fragment, is(notNullValue()));
assertThat(fragment, is(instanceOf(MyFragment.class)));
onView(withId(fragment.getId())).check(matches(isDisplayed()));
}
If I start my emulator without Use Host GPU checked, the tests pass fine. If Use Host GPU is enabled, the first test or so pass and then the rest fail with:
com.google.android.apps.common.testing.ui.espresso.IdlingResourceTimeoutException: Wait for [IdlingDrawerListener] to become idle timed out
at dalvik.system.VMStack.getThreadStackTrace(Native Method)
at java.lang.Thread.getStackTrace(Thread.java:579)
at com.google.android.apps.common.testing.ui.espresso.base.DefaultFailureHandler.getUserFriendlyError(DefaultFailureHandler.java:69)
at com.google.android.apps.common.testing.ui.espresso.base.DefaultFailureHandler.handle(DefaultFailureHandler.java:40)
at com.google.android.apps.common.testing.ui.espresso.ViewInteraction.runSynchronouslyOnUiThread(ViewInteraction.java:159)
at com.google.android.apps.common.testing.ui.espresso.ViewInteraction.check(ViewInteraction.java:133)
at com.example.MainActivityTest.testClickOnItemDisplaysMyFragment(MainActivityTest.java:152)
at java.lang.reflect.Method.invokeNative(Native Method)
at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:214)
at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:199)
at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:192)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:554)
at com.google.android.apps.common.testing.testrunner.GoogleInstrumentationTestRunner.onStart(GoogleInstrumentationTestRunner.java:167)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1701)
I have tried disabling animations in the emulator, as described here: https://code.google.com/p/android-test-kit/wiki/Espresso#Getting_Started , but I can still see the drawer sliding open and closed.

This is a known bug: https://code.google.com/p/android-test-kit/issues/detail?id=64

Related

NullPointerException: int android.widget.Editor$SelectionModifierCursorController.getMinTouchOffset()

It's a very strange Xiaomi device's OS exception. Even if I do have logs available from Fabric, the stack trace doesn't refer any of my code.
A crash details are below as reported in crashalytics(Fabric),
21K crashes
All crashes on Xiaomi devices
Crashes on Android OS version 6, 7 and 8
Crash Log:
# OS Version: 8.1.0
# Device: Redmi Note 5 pro
# RAM Free: 30.1%
# Disk Free: 74.2%
#0. Crashed: main
at android.widget.Editor.touchPositionIsInSelection(Editor.java:1084)
at android.widget.Editor.performLongClick(Editor.java:1205)
at android.widget.TextView.performLongClick(TextView.java:10908)
at android.view.View.performLongClick(View.java:6360)
at android.view.View$CheckForLongPress.run(View.java:24768)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:171)
at android.app.ActivityThread.main(ActivityThread.java:6606)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:518)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
--
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'int android.widget.Editor$SelectionModifierCursorController.getMinTouchOffset()' on a null object reference
at android.widget.Editor.touchPositionIsInSelection(Editor.java:1084)
at android.widget.Editor.performLongClick(Editor.java:1205)
at android.widget.TextView.performLongClick(TextView.java:10908)
at android.view.View.performLongClick(View.java:6360)
at android.view.View$CheckForLongPress.run(View.java:24768)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:171)
at android.app.ActivityThread.main(ActivityThread.java:6606)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:518)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
#0. Crashed: main
at android.widget.Editor.touchPositionIsInSelection(Editor.java:1084)
at android.widget.Editor.performLongClick(Editor.java:1205)
at android.widget.TextView.performLongClick(TextView.java:10908)
at android.view.View.performLongClick(View.java:6360)
at android.view.View$CheckForLongPress.run(View.java:24768)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:171)
at android.app.ActivityThread.main(ActivityThread.java:6606)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:518)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
Similar Reference:
https://issuetracker.google.com/issues/37127697
java.lang.NullPointerException with Nougat
Also asked on Xiaomi official forum http://en.miui.com/forum.php?mod=viewthread&tid=4595164
Please do provide any working solution as soon as possible. As users must not be happy with these crashes.
Thanks in advance.
1)  First of all, only if required, set one of these.
textView.setMovementMethod(LinkMovementMethod.getInstance());
or 
setAutoLinkMask(Linkify.ALL);
or
Linkify.addLinks(textView, Linkify.PHONE_NUMBERS | Linkify.EMAIL_ADDRESSES | Linkify.MAP_ADDRESSES);
2) Secondly, set a long click listener for TextView and it must return true.
textView.setOnLongClickListener(new View.OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
// do soemthing if needed
return true;
}
});
There is some internal crashing issue on Xiaomi devices. If you override setOnLongClickListener(reference) first and then follow the step one, it will use internal implementation and that will keep on crashing. So it is import to follow above steps in sequence.
I am open to other solutions, however by following this approach I don't see crash reports anymore.
Do you have a custom TextView in your app? Is it perhaps resizeable or has additional functionality?
Xiaomi's Android skin is likely interfering with that, and causing crashes. I suggest trying to long click all TextViews in your app.
It happen when user doing long click on all selected text.
Just define longClickListener:
edit_text.setOnLongClickListener {
doSomething()
true
}
and later you can remove it
edit_text.setOnLongClickListener(null)
For me this crash happened when TextView contained link and setAutoLinkMask(Linkify.ALL); was called for the view. In this case Android handles all clicks (including long clicks) by this view. On devices of other brands link was opened after long click, but on Xiaomi device crash happened. It seems, that they have a bit different logic of handling onTouchEvent inside the TextView. I've played a bit around and found, that setting android:textIsSelectable="false" for the TextView in layout file solves the problem.
I know, that it's not scalable solution, but for my case it was perfect, so I stopped investigating further. Maybe it will give a hint to someone else.

Set OnePlus 3t alert slider to all/vibrate/silent

I have a OnePlus 3t running on OOS Open Beta 15, Android 7.1.1. I want its alert slider to put my phone into all sounds/vibration only/silent mode respectively. After trying every possible combination of third party apps and Tasker profiles, I started looking into creating my own Magisk Module to change the slider's behavior.
I found out that all the alert slider logic is inside the package com.oneplus.threekey. Using
adb shell 'pm list packages' > C:\packages.txt
I go a list of all my installed packages and the only packages containing the word "oneplus" are the following ones:
package:com.oneplus
package:com.oneplus.aod
package:com.oneplus.applocker
package:com.oneplus.calculator
package:com.oneplus.camera
package:com.oneplus.camera.service
package:com.oneplus.config
package:com.oneplus.deskclock
package:com.oneplus.dirac.simplemanager
package:com.oneplus.gallery
package:com.oneplus.iconpack.dives
package:com.oneplus.iconpack.o2default
package:com.oneplus.iconpack.rifon
package:com.oneplus.ifaaservice
package:com.oneplus.opbackup
package:com.oneplus.opbugreport
package:com.oneplus.opbugreportlite
package:com.oneplus.oplocationservice
package:com.oneplus.screenshot
package:com.oneplus.sdcardservice
package:com.oneplus.security
package:com.oneplus.setupwizard
package:com.oneplus.simcontacts
package:com.oneplus.skin
package:com.oneplus.sms.smscplugger
package:com.oneplus.soundrecorder
package:com.oneplus.wallpaper
package:com.oneplus.wifiapsettings
After no getting anywhere this way, I decided to look further into my logcat output. Filtering it using "threekey" this is the output everytime I change the alert slider's position:
10-03 00:00:53.223 1407-1872/? D/ThreeKeyHw: OEM UEVENT: {SUBSYSTEM=switch, SEQNUM=11574, ACTION=change, SWITCH_STATE=3, SWITCH_NAME=tri-state-key, DEVPATH=/devices/virtual/switch/tri-state-key}
10-03 00:00:53.227 1407-1407/? D/ThreeKeyAudioPolicy: set mode ring, mVibrateFlag=false, mMuteMediaFlag=true
10-03 00:00:53.231 1407-1407/? D/ZenModeHelper: setConfigLocked reason=ThreeKeyAudioPolicy
java.lang.Throwable
at com.android.server.notification.ZenModeHelper.setConfigLocked(ZenModeHelper.java:706)
at com.android.server.notification.ZenModeHelper.setManualZenMode(ZenModeHelper.java:543)
at com.android.server.notification.ZenModeHelper.setManualZenMode(ZenModeHelper.java:503)
at com.android.server.notification.NotificationManagerService$5.setZenMode(NotificationManagerService.java:2193)
at android.app.NotificationManager.setZenMode(NotificationManager.java:422)
at com.oneplus.threekey.ThreeKeyAudioPolicy.setRing(ThreeKeyAudioPolicy.java:177)
at com.oneplus.threekey.ThreeKeyAudioPolicy.setDown(ThreeKeyAudioPolicy.java:87)
at com.oneplus.threekey.ThreeKey.setDown(ThreeKey.java:46)
at com.oneplus.threekey.ThreeKeyBase.setSwitchState(ThreeKeyBase.java:54)
at com.oneplus.threekey.ThreeKeyBase$ThreeKeyBroadcastReceiver.onReceive(ThreeKeyBase.java:80)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:1163)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at com.android.server.SystemServer.run(SystemServer.java:367)
at com.android.server.SystemServer.main(SystemServer.java:237)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
10-03 00:00:53.298 2002-2087/? I/vol.VolumeDialogControl: s updateZenModeW zen:0 threeKeySatus:3 mVibrateWhenMute:0
10-03 00:00:53.300 1407-1407/? D/ThreeKeyAudioPolicy: settings change selfChange=false uri=content://settings/global/zen_mode
10-03 00:00:53.301 1407-1407/? D/ThreeKeyAudioPolicy: zen mode was changed, zen mode=ZEN_MODE_OFF, three key status=3
10-03 00:00:53.302 2002-2087/? I/vol.VolumeDialogControl: s updateZenModeW zen:0 threeKeySatus:3 mVibrateWhenMute:0
10-03 00:00:53.306 2002-2002/? D/VolumeUI: mZenModeObserver:zenMode=3, threeKeyStatus=3, mLastThreeKeyStatus=2
10-03 00:00:53.314 2002-2002/? D/VolumeUI: mZenModeObserver:zenMode=3, threeKeyStatus=3, mLastThreeKeyStatus=3
Here I noticed in the Throwable part that the threekey class/service (I don't really know what that is tbh) calls setZenMode, which seems to be responsible for the notification sounds. But as it turns out the setZenMode method is not documented at Android Developers and can't be called after obtaining an instance of the NotificationManager class.
At this point I am beginning to run out of ideas what to try next or where else to look. Any help to get the slider to work like it used to would be great!

Jumping markers on Android Maps API v2

I'm seeing markers jump around on the map on Android Maps API v2 even when nothing is happening in the app.
Here's a video of the behavior:
https://youtu.be/cOUGD0T5Ojs
What I expect
Markers should remain stationary at their originally added lat/long.
What steps will reproduce the problem?
Build, install, and run the v2.0.6 tag of OneBusAway:
a. git clone https://github.com/OneBusAway/onebusaway-android.git
b. git checkout v2.0.6
c. gradlew installObaGoogleDebug
d. adb shell am start -n com.joulespersecond.seattlebusbot/org.onebusaway.android.ui.HomeActivity
Browse to any supported city (e.g., Seattle or Tampa), and watch the green bus stop markers jump around on the map
I should add that I can't always reproduce this. It seems like everything works fine for a time, but then when the markers start jumping around they don't stop.
Marker Implementation Details
The code that loads the icons used for the 9 marker types (8 directions + no direction) is here:
https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/google/java/org/onebusaway/android/map/googlemapsv2/StopOverlay.java#L175
I'm using this drawable:
https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/main/res/drawable/map_stop_icon.xml
...which is a number of shapes - this creates the main green circle with the white outline and the drop shadoes. Then, I'm drawing the direction arrow on top of this drawable for each of the 8 directions - code for drawing directions is here:
https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/google/java/org/onebusaway/android/map/googlemapsv2/StopOverlay.java#L208
In the code to load the icons, I'm caching the BitmapDescriptor returned from BitmapDescriptorFactory.fromBitmap() for each of the 9 icon types on first load, so this isn't done each time a marker is put on the map.
I also saw the app crash to "Unfortunately, OneBusAway has stopped." and saw this exception in Logcat after letting the app sit on the map screen for a few minutes:
08-10 16:40:02.422 15843-15929/com.joulespersecond.seattlebusbot E/AndroidRuntime﹕ FATAL EXCEPTION: GLThread 8614
Process: com.joulespersecond.seattlebusbot, PID: 15843
java.lang.IllegalArgumentException: Comparison method violates its general contract!
at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:831)
at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:449)
at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:372)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:178)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:142)
at java.util.Arrays.sort(Arrays.java:1957)
at java.util.Collections.sort(Collections.java:1864)
at com.google.maps.api.android.lib6.gmm6.n.bl.a(Unknown Source)
at com.google.maps.api.android.lib6.gmm6.n.l.a(Unknown Source)
at com.google.maps.api.android.lib6.gmm6.n.l.b(Unknown Source)
at com.google.maps.api.android.lib6.gmm6.n.cv.f(Unknown Source)
at com.google.maps.api.android.lib6.gmm6.n.cv.run(Unknown Source)
I've seen this on an LG G4 and Nexus 6. More details on LG device is below.
LG G4 LS991 with Android 5.1 (LS991ZV4)
Google Play Services client library version = compile 'com.google.android.gms:play-services-maps:7.5.0' and compile 'com.google.android.gms:play-services-maps:7.8.0'
Google Play Services version on the device - Google Play Services 7.8.99 (2134222-440)
Android SDK Version: compileSdkVersion 21 buildToolsVersion "21.1.2"
This issue hasn't always existed, which makes me believe it was introduced during an update to Android Google Play Services/Maps at some point.
I've opened an issue for this on gmaps-api-issues as well, but no response as of this post:
https://code.google.com/p/gmaps-api-issues/issues/detail?id=8455
Has anyone else seen this? Any ideas for fixes?
EDIT
I should add that I can't always reproduce this. It seems like everything works fine for a time, but then when the markers start jumping around they don't stop.
EDIT 2
I've created a smaller demo project here on Github that uses the same marker implementation:
https://github.com/barbeau/maps-demo
However, I haven't yet seen the same problem there.
EDIT 3
I've changed to caching Bitmaps instead of BitmapDescriptors in https://github.com/OneBusAway/onebusaway-android/commit/01b35e9a07313a627843819d66b3f6a9bb7e848f.
We'll see if this fixes the problem. It's intermittent, so the only way I'll know is if I don't see the problem again for some period of time.
EDIT 4
I'm still seeing the problem, so looks like switching from caching BitmapDescriptors to Bitmaps, and changing to using ContextCompat.getDrawable(), didn't have any effect.
EDIT 5
Not sure if this is related, but I'm also seeing the following output in Logcat when this happens:
09-01 10:46:00.339 9278-9278/? E/libEGL﹕ validate_display:255 error 3008 (EGL_BAD_DISPLAY)
09-01 10:46:00.339 9278-9278/? E/libEGL﹕ validate_display:255 error 3008 (EGL_BAD_DISPLAY)
and
9-01 10:46:00.069 9278-9278/? W/ResourcesManager﹕ Asset path '/system/framework/com.google.android.maps.jar' does not exist or contains no resources.
and
09-01 10:46:16.019 1137-4311/? W/ActivityManager﹕ Scheduling restart of crashed service com.google.android.gms/.usagereporting.service.UsageReportingService in 1000ms
09-01 10:46:16.019 1137-4311/? W/ActivityManager﹕ Scheduling restart of crashed service com.google.android.gms/.icing.service.IndexService in 11000ms
and
09-01 10:48:38.609 5402-26676/? E/SQLiteDatabase﹕ Error inserting context_name=8 end_time=1441118918490 context_family=7 module_id=com.google.android.contextmanager.module.PowerConnectionModule version=1 sync_state_mod_time_millis=1441118918532 start_time=1441118643058 sync_state=0 context_id=9680c4f4-789a-4d86-acbf-43d2098e89b8 time_type=3 proto_blob=[B#28265a3
android.database.sqlite.SQLiteConstraintException: UNIQUE constraint failed: context.context_id (code 2067)
at android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId(Native Method)
at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId(SQLiteConnection.java:790)
at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId(SQLiteSession.java:926)
at android.database.sqlite.SQLiteStatement.executeInsert(SQLiteStatement.java:86)
at android.database.sqlite.SQLiteDatabase.insertWithOnConflict(SQLiteDatabase.java:1581)
at android.database.sqlite.SQLiteDatabase.insert(SQLiteDatabase.java:1451)
at com.google.android.contextmanager.q.ak.a(SourceFile:405)
at com.google.android.contextmanager.q.ak.b(SourceFile:380)
at com.google.android.contextmanager.q.ak.a(SourceFile:346)
at com.google.android.contextmanager.q.ak.b(SourceFile:373)
at com.google.android.contextmanager.g.a.j.a(SourceFile:58)
at com.google.android.contextmanager.g.a.a.run(SourceFile:52)
at com.google.android.contextmanager.g.i.handleMessage(SourceFile:214)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)
EDIT 6
I haven't seen this issue lately, and I noticed that Google Play services on the LG G4 device was bumped to 8.1.15 (2250156-240). So, maybe it was fixed with an update of Google Play services? I'll report back again later.
EDIT 7
I've seen this again in 8.1.15 (2250156-240) and 8.1.18 (2272748-240), although it doesn't seem nearly as bad as it used to be (i.e., fewer markers jump around, and the jumping is less noticeable). It seems to be triggered mainly when resuming the app when its been in the background for a while. If I kill the app and then start it fresh, the problem disappears.
EDIT 8
I found a way to consistently reproduce this - see:
https://code.google.com/p/gmaps-api-issues/issues/detail?id=8455#c2
From above issue:
Build, install, and run the v2.0.6 tag of OneBusAway:
a. git clone https://github.com/OneBusAway/onebusaway-android.git
b. git checkout v2.0.6
c. gradlew installObaGoogleDebug
d. adb shell am start -n com.joulespersecond.seattlebusbot/org.onebusaway.android.ui.HomeActivity
Hold the device in a portrait orientation
If you're not physically located in Seattle or Tampa (or any of the supported regions), you'll need to go to "Settings->Your region" and manually set the region. After doing this, scroll the map to the region (or select "Take me there" when prompted).
Tap on a bus stop on the map
Tap on the 3 dots "more" button next to arrival time (or tap on arrival in list in sliding panel)
Tap on option "Show route on map"
After the route loads on the map, change the device orientation to landscape.
Watch the markers jump around after the map reloads
Full video capture on LG G4 that shows new steps to produce and issue:
https://youtu.be/oiBoMTPDVrU
I think this is definitely related to multiple instances of the SupportMapFragment existing simultaneously. In v2.0.6 I wasn't handling fragments correctly when the Activity was destroyed and recreated with a savedInstanceState (i.e., when the Activity was killed after being in background for a while, or on orientation change).
In v2.0.6, my code looked something like this:
public class HomeActivity ...{
BaseMapFragment mMapFragment;
...
private void showMap() {
FragmentManager fm = getSupportFragmentManager();
if (mMapFragment == null) {
mMapFragment = BaseMapFragment.newInstance();
fm.beginTransaction()
.add(R.id.main_fragment_container, mMapFragment)
.commit();
}
}
...
}
So, I was leaking an instance of BaseMapFragment (which extends SupportMapFragment) in those cases - an instance already existed in the FragmentManager, but I didn't have a local reference to it. I actually noticed this issue when Action Bar menu items were being duplicated for another fragment I was handling similarly.
I changed the code to look something like this, which first checks to see if the FragmentManager has an existing BaseMapFragment:
public class HomeActivity ...{
BaseMapFragment mMapFragment;
...
private void showMap() {
FragmentManager fm = getSupportFragmentManager();
// First check to see if an instance of BaseMapFragment already exists
mMapFragment = (BaseMapFragment) fm.findFragmentByTag(BaseMapFragment.TAG);
if (mMapFragment == null) {
mMapFragment = BaseMapFragment.newInstance();
fm.beginTransaction()
.add(R.id.main_fragment_container, mMapFragment, BaseMapFragment.TAG)
.commit();
}
}
...
}
The UI flow has changed in the master branch (I'm no longer opening a new Activity to view the route), so I can't directly test there if the problem is still reproducible after this code change.
However, I created this branch, which is branched from master but changed to have the same UI flow as v2.0.6, and includes the above fix for the fragment leak:
https://github.com/CUTR-at-USF/onebusaway-android/tree/jumpingMarkersTest
From some quick testing with this branch, it seems that handling the fragments correctly on orientation change (i.e., not leaking the fragment) may have fixed the jumping markers issue - at least using the steps above it no longer reproduces on a LG G4 with Android 5.1.

StackOverflowError because of too deep view-hierarchy in Android

we get in the Play Store some crash reports of this kind:
java.lang.StackOverflowError
at android.graphics.Paint.getTextRunAdvances(Paint.java:1753)
at android.graphics.Paint.getTextRunAdvances(Paint.java:1726)
at android.text.TextLine.handleText(TextLine.java:758)
at android.text.TextLine.handleRun(TextLine.java:981)
at android.text.TextLine.measureRun(TextLine.java:425)
at android.text.TextLine.measure(TextLine.java:299)
at android.text.TextLine.metrics(TextLine.java:273)
.
.
.
.
at android.view.View.draw(View.java:11069)
at android.widget.FrameLayout.draw(FrameLayout.java:450)
at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2203)
at android.view.View.getDisplayList(View.java:10505)
at android.view.HardwareRenderer$GlRenderer.draw(HardwareRenderer.java:876)
at android.view.ViewRootImpl.draw(ViewRootImpl.java:1916)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1640)
at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2454)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4477)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:788)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:555)
at dalvik.system.NativeStart.main(Native Method)
We had such an exception on one of our test devices and it came out, that it was because of the maximum depth of the view hierarchy.
I know that the recommendation for the max depth is <10.
However, this value is quite ambitious if you have a reasonably complex app.
We use AppCompat v21 and a ViewPager on the Main-Acitivity with Fragments.
For this reason i think we have alot of "meaningless" views, which simply encapsulates one child.
Or What is the purpose of the following layouts:
-NoSaveStateFrameLayout
-NativeActionModeAwareLayout
-FitWindowsFrameLayout
Overall, we arrive a total depth of 23 including the PhoneWindowDecorView.
Our Viewtree looks like this:
Picture from Hierarchy View
The first Views from the RootView:
Picture from Hierarchy View
Nevertheless, our app works even on very old and poor Android 2.3 devices.
Why does the problem still occur in the real world.

NullPointerException at SuggestionSpan

I am getting a NullPointerException at SuggestionSpan. (Stack trace included below). As the stack trace does not include any of my code, I have absolutely no idea where to start debugging.
The error can be reproduced whenever I press space (or select a word) while using an EditText. I tried multiple keyboards including the stock Android one but the same error appears.
FATAL EXCEPTION: main
java.lang.NullPointerException
at android.text.style.SuggestionSpan.<init>(SuggestionSpan.java:128)
at android.text.style.SuggestionSpan.<init>(SuggestionSpan.java:101)
at android.widget.SpellChecker.createMisspelledSuggestionSpan(SpellChecker.java:392)
at android.widget.SpellChecker.onGetSuggestions(SpellChecker.java:300)
at android.view.textservice.SpellCheckerSession.handleOnGetSuggestionsMultiple(SpellCheckerSession.java:198)
at android.view.textservice.SpellCheckerSession.access$000(SpellCheckerSession.java:86)
at android.view.textservice.SpellCheckerSession$1.handleMessage(SpellCheckerSession.java:112)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4424)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)
EDIT: I can only reproduce the error on my Nexus S with 4.0.3, but not on emulators with other OS versions. Weird.
EDIT 2: Strange thing happened! I just dragged an EditText into another activity and the same thing happens. No code is attached to it nor any XML changes made to it.
After days of investigation, it turns out that getResources().getConfiguration().locale is null. I am not sure if it is a problem specific to some versions of Android / some devices (mine is Nexus S running 4.0.3).
But I worked around this issue by checking in the constructor of the Activity (since the context given to the SuggestionSpan is my Activity) whether the locale is null, and then set it to the default one if it is.
// to prevent a weird bug where locale is null
Configuration config = getResources().getConfiguration();
if (config.locale == null)
config.locale = Locale.getDefault();
That's what I did. I am quite sure it's not the best way though. Anyone have any more ideas?

Categories

Resources