3

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.

Terry Jan Reedy
  • 18,414
  • 3
  • 40
  • 52
Gregg Rivinius
  • 775
  • 1
  • 8
  • 13
  • 2
    I have also found a thread on a [robotium group](http://groups.google.com/group/robotium-developers/browse_thread/thread/100e0fa5412d04f8/58ed13c2033bb4d1?lnk=gst&q=+animations+#58ed13c2033bb4d1) that refers to this same issue, but does not have a resolution. We currently changed the infinite repeat on the animations to just animate once, but as I mentioned in my original post this is more of a work around. – Gregg Rivinius Aug 17 '11 at 21:32
  • I guess my question really boils down to, is there a clean way to implement animations so they are not constantly filling the Main UI thread message looper? Such as lowering the framerate or moving anything to a secondary thread? If the Main UI appeared to be idle even for a short period then the waitForIdleSync() would be a non-issue. – Gregg Rivinius Aug 18 '11 at 18:45
  • when do you start these animations? – Ron Aug 22 '11 at 18:52
  • 1
    When the animations start doesn't make much of a difference... if they are started as part of start up then we have the issues with the getActivity's waitForIdleSync not being successful. Delaying the start of the animations until a much later point would only delay this issue until a later point in the life of the Robotium tests. Currently the first animation begins after the activity is bound to a background service and gets a status update from that service (It is after the onResume) which is early enough for the getAcitivity to fail and the "Launch timeout" logcat message to be generated. – Gregg Rivinius Aug 22 '11 at 20:20
  • possible duplicate of [Launch timeout has expired, giving up wake lock! Activity idle timeout for HistoryRecord. Is this something to worry about?](http://stackoverflow.com/questions/10031624/launch-timeout-has-expired-giving-up-wake-lock-activity-idle-timeout-for-histo) – Matthieu Nov 30 '12 at 00:46
  • Did you find any solution to this problem? It seems that I am having the same problem. My `getActivity()` inside my tests does not return because it waits for the activity to become idle. This never happens because I have a ViewPager inside my activity that does an infinite cycle through images. Also, I am seeing the same log output as you do (idle timeout). Would be great to hear that you solved this :-) Regards, David – david.schreiber Nov 12 '13 at 08:15
  • Possibly related to [20860832](http://stackoverflow.com/questions/20860832/why-does-getactivity-block-during-junit-test-when-custom-imageview-calls-start) and [20151699](http://stackoverflow.com/questions/20151699/android-infinitely-repeating-animation-vs-instrumentation-waitforidlesync). – Gary Sheppard Dec 31 '13 at 21:25

2 Answers2

0

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();
dac2009
  • 3,521
  • 1
  • 22
  • 22
  • This does not help... I am not having problems with doing too much in onCreate, I am not coming close to generating an ANR. My application starts quickly and is responsive. The problem is that the animation is (as I would somewhat expect) constantly repainting the screen and it is those drawing messages that are keeping the main UI thread to the point that it is never considered Idle. – Gregg Rivinius Aug 24 '11 at 15:17
0

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.

Dororo
  • 3,420
  • 2
  • 30
  • 46
  • How is this any different than the earlier answer by dac2009... I believe even if the animation is started in a different thread (which I have done), the actually screen repaint messages are handled in the main UI thread. Moving the animation to a background thread did not fix the problem. – Gregg Rivinius Aug 25 '11 at 17:58