make WebRTC signalling unit tests pass on Android

RESOLVED DUPLICATE of bug 1137925

Status

()

defect
RESOLVED DUPLICATE of bug 1137925
7 years ago
4 years ago

People

(Reporter: dmose, Assigned: dmose)

Tracking

(Blocks 1 bug)

Trunk
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC][android-webrtc-])

Attachments

(1 attachment)

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.
There may also be other necessary fixes too.
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.
Whiteboard: [WebRTC][blocking-webrtc-]
Depends on: 821812
Depends on: 821855
Whiteboard: [WebRTC][blocking-webrtc-] → [WebRTC][blocking-webrtc-][android-webrtc+]
Are these tests running on central right now? Do we know if there's work left to do here?
Flags: needinfo?(gpascutto)
gbrown and ted worked on this. I know nothing about it.
Assignee: dmose → gbrown
Flags: needinfo?(gpascutto) → needinfo?(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).
Assignee: gbrown → dmose
Flags: needinfo?(gbrown)
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.
Flags: needinfo?(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
Depends on: 811409
Flags: needinfo?(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... :-)
Flags: needinfo?(ctalbert)
Whiteboard: [WebRTC][blocking-webrtc-][android-webrtc+] → [WebRTC][blocking-webrtc-][android-webrtc-]
Whiteboard: [WebRTC][blocking-webrtc-][android-webrtc-] → [WebRTC][android-webrtc-]
jsmith: I'm confused; why would we consider turning on the WebRTC android by default if the tests weren't ready?
(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.
As data point, the signaling unittests also do not build or run on Windows - Bug 862837
(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.
Flags: needinfo?(ctalbert)
(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.
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).
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1137925
You need to log in before you can comment on or make changes to this bug.