I'd be interested in seeing this too, if you can get a good reproduction
case, as I've come across the same (but hard to pinpoint) problem.
Right now I have an app that hangs like this in one particular test.
But it only started doing this when I merged in some totally-unrelated
code into the app (which is very very odd). The test case goes like this:
1. Launch an activity (A) as normal via RobotiumTestCase<A>
2. Activity A, in onCreate and before setContentView, fires a new
startActivity call (B) and then finishes itself
3. Because I can't use "getCurrentActivity()" (or a regular
ActivityMonitor), I use Solo to search for some text on Activity B to
confirm it was really launched. This succeeds
4. Neither Activity A nor B are torn-down during JUnit tearDown (which
includes the usual Robotium finalize stuff). Calling Solo.getBack
before the end of the test doesn't help
5. The next Robotium test case for this Activity starts and then hangs:
logcat says Activity A has started for the new test, but no UI
change is seen; the result of the previous test case remains hung there
This was on a standard 1.6 emulator.
Regards,
Chris
On 18/10/2010 10:42, Dirk J�ckel wrote:
> Hi!
>
> I will compile a small project to reproduce the effect, and get back
> to you later.
>
> Regards,
> Dirk
>
>
> On Oct 18, 4:47 am, Renas Reda<renasr...@gmail.com> wrote:
>> Hi,
>>
>> The problem is that it will not have time to register the new activity
>> as the activity change happens instantly (before the activity monitor
>> in Robotium has a chance to register a new activity). The
>> getCurrentActivity() will not return the correct activity however
>> everything else should be working as expected. You say that the
>> instrumentation hangs as activity B is not finished? Could you please
>> elaborate on that.
>>
>> /Renas
>>
I tried to make a simple project to reproduce the error, but it it did
not hang.
Maybe I can reduce my "big" project to a point where it still hangs
while testing, but has not to much code.
Dirk