solo.getCurrentActivity() is different than actuall activity

[GoogleCodeExporter]

I have a main activity A that automatically starts activities B or C depending 
on the data in database and then returns the result to activity A's callback 
'onActivityResult'

When I run the robotium test, I do see the
activity B or C, but when I output the current activity name via

Log.d("MyTag", solo.getCurrentActivity().getLocalClassName() );

it would always show activity A.

Furthermore, when I try to solo.clickOnButton on a button that's on
activity B, I will get a NullPointerException (since robotium thinks
it's still on Activity A). But I definitely see the Activity B and the
button on the emulator screen and Robotium having opened it.

Is there a workaround for this?

Original issue reported on code.google.com by tomi.ura...@gmail.com on 24 Oct 2011 at 1:02

[GoogleCodeExporter]

Thanks for reporting  this. Would it be possible for you to send me your app 
and test project?

Original comment by renasr...@gmail.com on 25 Oct 2011 at 2:51

[GoogleCodeExporter]

created a new project which illustrates the issue at hand.

Original comment by tomi.ura...@gmail.com on 25 Oct 2011 at 4:49

Attachments:

• robo.zip

[GoogleCodeExporter]

Thanks.

Original comment by renasr...@gmail.com on 26 Oct 2011 at 6:14

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

1. Do you have an approximate ETA for when this will be fixed?
2. In the meantime is there a workaround that would enable me to full test the 
application?

Original comment by tomi.ura...@gmail.com on 26 Oct 2011 at 7:41

[GoogleCodeExporter]

Please use the constructor solo = new Solo(getInstrumentation) and then in the 
beginning of your test case call getActivity() and it will work.

Original comment by renasr...@gmail.com on 3 Nov 2011 at 6:58

• Changed state: Invalid

[GoogleCodeExporter]

thx. 

Original comment by tomi.ura...@gmail.com on 4 Nov 2011 at 5:51

[GoogleCodeExporter]

I noticed that the status of this is now invalid and the issue is now moved to 
closed. Is the workaround listed above:

"Please use the constructor solo = new Solo(getInstrumentation) and then in the 
beginning of your test case call getActivity() and it will work."

the only fix for this or will a better solution be rolled into a future release?
Thanks!

Original comment by david.a....@gmail.com on 6 Dec 2011 at 1:12

[GoogleCodeExporter]

that's the working workaround

Original comment by tomi.ura...@gmail.com on 6 Dec 2011 at 3:05

[GoogleCodeExporter]

I would not call it a work around. If there is one Activity which is started 
immediately by the start activity, before the solo object is created then it 
will not be ready to register the new activity. By using this constructor 
instead, getActivity() will be called after the solo object is fully created 
thus making it ready to register a new activity that is started immediately by 
the start activity. 

Original comment by renasr...@gmail.com on 6 Dec 2011 at 4:00

[GoogleCodeExporter]

agreed

Original comment by tomi.ura...@gmail.com on 6 Dec 2011 at 5:45

[GoogleCodeExporter]

I don't want to whine, or get hung up on semantics, but it does sound a bit 
like a workaround. When I call solo.getCurrentActivity() , as an end user I 
expect to retrieve the current activity that I am on independent of setup. I 
expect this because the constructors that Robotium provides for the Solo object 
don't provide the information listed within this issue.

That being said, instead of complaining I'll go ahead and take a gander at the 
source and see if I can help ;)

Thanks!
++dave;

Original comment by david.a....@gmail.com on 7 Dec 2011 at 8:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Has this been fixed?
I think I encountered the same problem.

Hoping for some input.
Michael

Original comment by M.Schwar...@gmail.com on 16 Dec 2014 at 9:17

[GoogleCodeExporter]

We have updated how this works in 5.2.1 and so far no one has reported it not 
working. What problem do you get?

Original comment by renasr...@gmail.com on 16 Dec 2014 at 4:35

[GoogleCodeExporter]

I'm using calabash-android <https://github.com/calabash/calabash-android/>, 
which is using robotium version 4.3.1.  It has this bug, where the launch 
activity starts a 2nd activity, and intermittently the test server is unable to 
recognize that the launch activity has since started a new activity.

I tried the fix mentioned in #c6:

• solo = new SoloEnhanced(getInstrumentation(), activity);
• solo = new SoloEnhanced(getInstrumentation());

but it is still only showing the launch activity, even though a 2nd activity 
has been started and is showing on the screen.  The code that calabash uses for 
obtaining the current activity is:

Activity currentActivity = InstrumentationBackend.solo.getCurrentActivity();
Result result = new Result(true, currentActivity.getClass().getSimpleName());

I can try integrating robotium 5.2.1, but if it's not a simple update of the 
jar, then I am not going to have the time to do this work.

Is there any other suggestion that would work in 4.3.1?

Original comment by jhans...@meetme.com on 12 Mar 2015 at 6:15

[GoogleCodeExporter]

I was able to update calabash to use robotium 5.3.1 with some package renaming 
and a couple method signature changes, and that appears to have resolved the 
issue.

Original comment by jhans...@meetme.com on 12 Mar 2015 at 7:04

[GoogleCodeExporter]

Good to hear that its working well for you!

Original comment by renasr...@gmail.com on 12 Mar 2015 at 8:38

[GoogleCodeExporter]

I may have spoken too soon...  I wasn't able to get it to happen on a device.  
But once I started testing on the emulator again, it's back -- happened 4 out 
of 8 times in my emulator test.

I'm new to Ruby, so I may just be doing something dumb.. I'm gonna try a manual 
version bump to make sure that I'm actually using the gem that I built.

If this still doesn't work, I'm going to have to get rid of the Robotium-driven 
activity check, and use `adb shell dumpsys` to get the focused activity 
instead.  50% failure rate is unacceptable.  :/

Original comment by jhans...@meetme.com on 12 Mar 2015 at 9:32

[GoogleCodeExporter]

I've confirmed that I'm using the new version of the calabash test server apk, 
which includes robotium 5.3.1, and I am still seeing the issue.  The calabash 
test starts with something along the lines of:

    wait_for_not_activity("LaunchActivity")

That is a method I created which waits for the calabash "get_activity_name" 
result to be anything else other than LaunchActivity (that is the activity 
specified as the default activity in my AndroidManifest, and the one that 
calabash launches to begin the tests).  The "get_activity_name" action does as 
described above:  InstrumentationBackend.solo.getCurrentActivity(), returning 
the class's simple name.

But it is still not detecting that the current activity is changed.

Original comment by jhans...@meetme.com on 12 Mar 2015 at 9:55

[GoogleCodeExporter]

Would it be possible for you to share the APK you use to reproduce this issue?

Original comment by renasr...@gmail.com on 12 Mar 2015 at 9:57

[GoogleCodeExporter]

Not by attaching here, but I can send it to you privately -- but your email is 
truncated to "renasr..." here.

If I have time I'll see if I can put together a sample project that does the 
same thing.  I have a feeling it isn't specific to my app.

Original comment by jhans...@meetme.com on 12 Mar 2015 at 11:32

[GoogleCodeExporter]

That would be great. You can send it to support@robotium.com.

Original comment by renasr...@gmail.com on 12 Mar 2015 at 11:36

[GoogleCodeExporter]

@renasr... I was able to reproduce the bug (running within Calabash) using this 
project: https://github.com/MeetMe/robotium-179

After building the apk:

    $ cd app
    $ bundle install
    ... if you don't have bundle, install it with:  gem install bundler
    ... or just install calabash manually:  gem install calabash-android -v 0.5.8

Resign the APK:

    $ calabash-android resign build/output/apk/app-debug.apk

Then try running the calabash test:

    $ calabash-android run build/output/apk/app-debug.apk -v

On a *device*, this was working more often for me.  But on an emulator, it 
fails most of the time.  The key is the built-in calabash step:

    Then I wait for the "SecondActivity" screen to appear

LaunchActivity starts SecondActivity from onResume().  But calabash (which uses 
Robotium to keep track of which activity is active) never sees SecondActivity 
launch, so it still thinks that LaunchActivity is the focused activity.  That 
causes the calabash step to fail, because it times out waiting for 
SecondActivity.

Original comment by jhans...@meetme.com on 12 Mar 2015 at 11:53