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.
Related
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.
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'm writing a unit tests for activity with animation. Animation is simple rotation of spinner drawable with infinite duration(splash screen).
When i start unit tests, every test seems to wait until animation is finished, so they stucks infinte, When i set duration to 1 it all passes, cause animation ends quickly.
How can I override that, so tests don't wait for animation ending?
I assume that you intend to test behavior other than the animation.
You will probably benefit the most from moving the animation off the path of the code you want to test. This means moving the other code--code that doesn't depend on the animation--out of the Activity. If not out of the Activity, then, at least out of the Activity lifecycle methods (onCreate(), ...). You can then check this behavior without running the behavior at all. Even better would be to run the behavior without starting the Activity at all (don't call onCreate()).
The problem you encountered is a special case of what happens when you put your code directly into a framework extension point: your code then becomes intermingled with the framework and you get stuck running something that you don't care about in order to run the part that you do care about. So don't do that. Put your code in classes that don't depend on the framework, then use the framework extension point (the Activity in this case) to connect Android to your code. The Activity knows that your code exists; your code remains blissfully ignorant of Android. Now things like your animation can't get in the way.
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.
My app may launch a sub-activity for a specific purpose. When that activity finishes, I get the results in onActivityResult. These results are then processed in the subsequent onResume. This consists of a setContentView and also starting an AsyncTask that puts up a ProgressDialog.
This all works well when initiated the normal way, which is via a user request (i.e., menu selection) after the app is up and running. However, under some conditions I need to do this right as the app is starting up, so I initiate this sequence right from my onCreate. What then happens is that I get fatal ResourceNotFound errors within any o/s call that implicitly calls the layout inflater. I got around this with setContentView by pre-inflating the view in my onCreate method, but the AsyncTask's onPreExecute still fails on ProgressDialog.show() as it "fails to find" Android's own progress_dialog.xml!
Anyone know what's happening here?
I suspect it's something to do with the timing, where this is occurring before the main activity has even had a chance to display its screen. These calls are all being made on the main UI thread, but maybe something hasn't completed within the o/s under these conditions.
As a closeout, the problem turned out to be totally unrelated to what I described in my post. Turns out it was due to blindly using some code that had been posted in some online forum showing how to get and use AssetManager. Trouble is, at the end of the block of code he had put "assMan.close()". Well, this closes the asset manager for the entire activity and resources can no longer be accessed!
It took a while to find it since it was not something that I did via my own understanding.