Espresso tests hangs in infinite loop and never ends and no error....
Navigated from fragment to fragment without any animation.
Espresso not able to identify any views in the current fragment and hangs on...
found below logs whenever fragment launched and visible to user.
W/View: requestLayout() improperly called by my.app.packege.CustomTextView
and
D/OpenGLRenderer: DisplayEventReceiver 0xb89c2080 requestNextVsync
D/OpenGLRenderer: DisplayEventReceiver 0xb89c2080 latestVsyncEvent 20573087565730.... logging infinitely in the same screen opened.
if activity (contains the fragment) launched using Activity rule,
getting below exception.Tried almost all stackoverflow solutions for below exception, but not succeeded.
`java.lang.RuntimeException: Could not launch intent Intent { act=android.intent.action.MAIN flg=0x14000000 cmp=my.app.package.OnBoardingActivity } within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time? There could be an animation or something constantly repainting the screen. Or the activity is doing network calls on creation? See the threaddump logs. For your reference the last time the event queue was idle before your activity launch request was 1501794260664 and now the last time the queue went idle was: 1501794260664. If these numbers are the same your activity might be hogging the event queue.
Anybody faced issue like this? Let me know your suggestions.
Thanks
Please enable "Show surface updates" in developer option. Check the flow manually and see if screen flashes continuously at any point. Looks like there is a problem in CuatomView which is invalidating and requesting layout continuously. Please see if you can use IdlingResource, ConditionWatcher or normal thread sleep on main thread to get over this problem.
Related
Recently i've started covering my project with integration tests where mockito provides presenter instances to verify whether or not my views calling presenter methods properly during their events.
The issue was on the screen which has invisible ProgressBar and RecyclerView. Presenter of that screen have been loading data for that RecyclerView and controlling visibility of ProgressBar. When i replaced it with mock (used Mockito) it caused corresponding tests to totally stuck with error after a while:
Could not launch intent Intent { act=android.intent.action.MAIN flg=0x14000000
cmp=com.example.kinopoisk/com.example.mvp.view.activity.MainActivity } within 45 seconds.
Perhaps the main thread has not gone idle within a reasonable amount of time?
There could be an animation or something constantly repainting the screen.
Or the activity is doing network calls on creation? See the threaddump logs.
For your reference the last time the event queue was idle before your activity launch request
was 1476191336691 and now the last time the queue went idle was: 1476191336691.
If these numbers are the same your activity might be hogging the event queue
But activity was successfully running and was accessible for all user events like clicks etc.
How do you think, what cause a problem?
This is a question for community knowledge base only, i've found answer myself.
The explanation is in that line of error code: There could be an animation or something constantly repainting the screen.
When i had replaced presenter with mockito's one, it stopped controlling progress bar as well. The initial state of it was View.VISIBLE, so that was cause test to hadn't been able to connect.
The solution was just set initial state of ProgressBar to View.GONE, but found it was a bit of headache for me.
I ran into a very strange issue with postponing transition.
I postponed the return transition in onActivityReenter. But the problem here is that if I checked „Don’t keep activities“ in the settings of the phone, the app will most of the times just hang and show both activities over each other.
I found out that in that case onActivityReenter still gets called. But onPreDraw doesn’t, which should be called by the onPreDrawListener and resumes the postponed transition. So I postpone the transition forever.
What could have happened there?
The code can be found here.
I've been running into the same issue. It's only in specific cases, and even then not 100% of the time.
Requesting the layout again after adding the listener works for me.
myView.getViewTreeObserver().addOnPreDrawListener(<snip>);
myView.requestLayout(); //Force a layout pass
I'm pretty sure this is indicative of a bug somewhere in Android, but I haven't been able to create a reliable test case. Somehow, it's skipping part of the layout pass, so the listener doesn't ever get called. Calling requestLayout() forces the full layout pass to happen.
I have an activity that sends a BC and waits 5 seconds for the response using AlarmManager.
Once i get the broadcast i:
1. remove the FragmentDialog using mDialog.dismiss();
2. start a new activity using getActivity().startActivity(myIntent);
I'm inside a Fragment (using TabFragment from the support library and MyTabActivity which i created).
The thing is i constantly getting balck screen and ANR, if i remove the line startActivity()
I'm not getting the ANR, the fragment does gets dismissed, but my activity doesn't show, i get the black screen and if i press it, ANR.
What i thought about is that the fragment manager started out working on the activity and then i started a new one that fucks up android, since i'm basing myself on fragment i really don't know how to get out of this mess, thought of using handler in the activity to post my activity start in 300 millis, this is a very very ugly solution.
Any nice ideas ?
the problem seems to be that i unbding a service twice in onStop of the activity due to the fact that once i call unbind ServiceDisconnected is NOT called and changes the state of my activity to unbonded (state i follow).
since onStop is never eding the original activity gets the UIthrehad and make the whole app stuck...
So I have a strange problem, and I'm not entirely sure what all information I should provide, but I'll do my best -- just let me know if I need to add more info. I'm having an issue that when I finish my Activity and return to the previous Activity (or launch it with a new Intent -- the problem seems to be centered on finishing the Activity) the UI performance drops drastically for about six or seven seconds, then returns to normal.
From LogCat, this warning appears consistently:
07-11 22:09:42.594: W/ActivityManager(292): Launch timeout has expired, giving up wake lock!
07-11 22:09:42.601: W/ActivityManager(292): Activity idle timeout for ActivityRecord{42bf6e00 com.kcoppock.sudokubeta/com.kcoppock.sudoku.SudokuBoardActivity}
As soon as the activity times out, UI performance returns to normal. Until that point it is very sluggish. I have no code that I am aware of that could be blocking the main thread, and I've even gone so far as to comment out my entire onPause() method to see if it makes any difference, and it does not.
The Activity does not spawn any background threads, does not perform any network activity, the only disk access it has is some accessing of SharedPreferences. The previous questions I've been able to locate are about idle timeouts for HistoryRecord, not ActivityRecord.
Any ideas what would cause this? Or how I could go about determining what is blocking the UI thread, if that is what is happening?
EDIT : Okay, just tried commenting out everything except super.onCreate() and setContentView() -- the problem still persists. It doesn't occur with any other Activities but this one, but there's NOTHING TO this one. :/
Oh geez. One of those things that's pretty hard to diagnose outside of trial and error, but I've figured it out. For reference, should anyone else have this problem, it came down to a custom view in my layout. I had added a ViewTreeObserver.OnGlobalLayoutListener() to do some layout modifications after the layout pass, but within that listener I modified the layout and thus caused another layout, essentially creating an infinite loop (but somehow not causing an ANR). My solution was like so:
private class BoardLayoutListener implements OnGlobalLayoutListener {
#Override
public void onGlobalLayout() {
//...do stuff here
//REMOVE this listener so that you don't repeat this forever
ViewTreeObserver obs = SudokuBoard.this.getViewTreeObserver();
obs.removeGlobalOnLayoutListener(this);
}
}
This solution is quite ironic, considering my second highest rated answer on StackOverflow specifically deals with this. :P
sigh
I've had the same issue today but as it turned out to have a different cause and solution I decided to add the information here just in case it might help someone else.
In my case problem was caused because I had the following line inside my onActivityResult() method:
android.os.Debug.waitForDebugger();
I Just deleted the line and the problem was gone.
This line is usually used to synchronize the debugger with the OS threads but I just figured it shouldn't be used anywhere. Oddly the problem would not appear until I had my phone disconnected from the desktop.
Regards
I have been searching for an answer to this and while I can find others who have been seeing the same entries in the log cat none of the footprints seem to be similar to mine.
Basically I start an infinitely repeating animation as part of my activity start up. The screen is rendered properly, is responsive to all touch input but I get the following entries in my logcat:
08-17 16:03:25.910: WARN/ActivityManager(110): Launch timeout has expired, giving up wake lock!
08-17 16:03:25.972: WARN/ActivityManager(110): Activity idle timeout for HistoryRecord{4057ad58 com.companyname.dm/.ui.activities.home.HomeActivity}
I have read posts that state these entries are indeed just warnings to indicate the main thread looper has never become idle and not a problem if it is the intended mode of operation. However, besides that fact that it seems excessive that the small repeating animation (a scale/transform/alpha animation that repeats every 3 seconds) is filling the message queue, my main issue is that it is preventing the ability to create automated tests. We are trying to implement a test using robotium but the test will never start because of the idle timeout.
Not starting the animation will eliminate this problem, but is much more a workaround than a root cause solution. I am trying to understand if I am either not implementing my animations properly, if this is indeed just the expected behavior or if there is a way to ensure the connection the instrumentation/robotium will be established.
Any insight would be greatly appreciated! Thanks.
Try starting your animation in a new thread, if you do too much stuff in the onCreate method you will block the UI-thread in Android, and it could possibly lead to an ANR (Application not responding) if you take longer than 5 seconds before returning. By starting your animation in a new thread the onCreate will return and the system will be happy.
new Thread(new Runnable() {
public void run() {
//start animation.
}
}.start();
The code which is repainting to the screen need to be started in a different thread, else the main UI thread will never become idle, which is causing the problem.
You may have issues when interacting with the UI from another thread, for this you should look into AsyncTask which is actually what is used to compute/draw progress bars. The obscene number of warnings is most likely because the warnings are generated any time after X seconds, which is only limited by Android's checks.