819854 - make WebRTC signalling unit tests pass on Android

Status: RESOLVED DUPLICATE of bug 1137925

(Core :: WebRTC: Signaling, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

ekr and I did a couple of quickie hacks to make the signalling tests get closer to passing.  We need to turn them into real solutions.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

There may also be other necessary fixes too.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: WIP patch 1: get signalling tests closer to passing

There are two hacks here that need to be turned into real fixes.  One is that non-rooted Android devices often (usually? always?) don't have access to /tmp, so we worked around.  I assume that the actual right place to put these files is somewhere in the profile directory, but more research is needed.

The PR_Sleep change is one that makes us less likely to hit a signalling race.  We need to figure out what the race actually is and fix that.

Comment 3

[Jason Smith [:jsmith]]

Are these tests running on central right now? Do we know if there's work left to do here?

Comment 4

[Gian-Carlo Pascutto [:gcp]]

gbrown and ted worked on this. I know nothing about it.

Comment 5

[Geoff Brown [:gbrown]]

Sorry, but I am not sure I can help either. I made some changes to the remotecppunittests test harness but never looked much at webrtc test content.

(In reply to Jason Smith [:jsmith] from comment #3)
> Are these tests running on central right now? Do we know if there's work
> left to do here?

Which tests exactly? As far as I know, the remotecppunittests are not run in continuous integration (tbpl).

Comment 6

[Jason Smith [:jsmith]]

Dan - Do you what the current status is for getting these tests enabled on FxAndroid? There seems to be confusion on what needs to be done here.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Sorry for the delay; I'm actually OOO this week, so I may not get back to this until next week again.

So gbrown is quite right, the remotecppunittests are not run by tbpl, and that's the underlying dependent bug that needs to be fixed for this bug to be fixable.  And, indeed, there may not be any work left to do here once that bug is fixed.  

I _thought_ that we (gbrown or me or maybe ted) had filed the "get

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Whoops!  I found the bug for making the C++ unit tests run in the automation on Android, it's 811409, which itself depends on 811404.

I spoke briefly to ted and ctalbert this a bit ago, and ctalbert thought he might be able to find some help to make this happen, and I promised him a needinfo?, so here it is... :-)

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

jsmith: I'm confused; why would we consider turning on the WebRTC android by default if the tests weren't ready?

Comment 10

[Jason Smith [:jsmith]]

(In reply to Dan Mosedale (:dmose) from comment #9)
> jsmith: I'm confused; why would we consider turning on the WebRTC android by
> default if the tests weren't ready?

The mochitests and crashtests are technically already running, so we do have coverage here on try. The signaling tests are the only thing not running. As much as I do want these running, I don't think this blocks preffing on WebRTC FxAndroid.

I think the critical pieces is ensuring the UI is implemented and working at a sanity level, some of the automated tests are running consistently in CI, and basic gUM and WebRTC flows are working. These requirements are met, so I don't think we need to block pref on here.

We need to do this eventually, however.

Comment 11

[Ethan Hugg [:ehugg]]

As data point, the signaling unittests also do not build or run on Windows - Bug 862837

Comment 12

[cmtalbert]

(In reply to Dan Mosedale (:dmose) from comment #8)
> Whoops!  I found the bug for making the C++ unit tests run in the automation
> on Android, it's 811409, which itself depends on 811404.
> 
> I spoke briefly to ted and ctalbert this a bit ago, and ctalbert thought he
> might be able to find some help to make this happen, and I promised him a
> needinfo?, so here it is... :-)

Yes, I have dminor looking into this.

Comment 13

[Eric Rescorla (:ekr)]

(In reply to Dan Mosedale (:dmose) from comment #9)
> jsmith: I'm confused; why would we consider turning on the WebRTC android by
> default if the tests weren't ready?

Note that a number of the C++ unit tests (signaling_unittest in particular) do
not run on tbpl for desktop. I do, however, run them in my local automation
for linux.

Comment 14

[Byron Campen [:bwc]]

The patches here are no longer applicable since all of that sipcc stuff is gone. The primary problem with running signaling_unittests on Android is described in bug 1137925 (there is likely the same problem in mediapipeline_unittests and mediaconduit_unittests).