Building/Publishing precompiled AAR libs on new webrtc releases

[Willem Vooijs]

For non-Googlers building webrtc is not a fun practice, here's a recommendation to make implementing webrtc easier for Android devs.

The official prebuilt Android libraries at bintray are a great start, but are _not_ release versions, and seem to be built on arbitrary commit id's without a correlation to the official webrtc builds.

It would be so much easier if:

- The bintray libs are built from a release tag (eg M63) every time a release build completes succesfully.

- (Optional) The version numbers in bintray would match the version numbers used in the tags for clarity

- (Optional) The 'latest' and 'release' tags in bintray would reflect the release state of webrtc in chrome. (EG current: release 63, latest 64).

- Getting Started Tutorials are updated to reflect these changes and not link to outdated libjingle examples.

Using the above method, Android devs could all rely on the bintray prebuilt libs for production and save a lot of hassle imho.

[bl...@webrtc.org]

Thanks for the feedback. We decided on purpose to release the mobile libraries on a weekly basis to give mobile developers access to a more up-to-date version of WebRTC. What would be in your opinion the advantage for going down to a 6-week release cadence? 

There's an admittedly very brief getting start description in Native Code / Android & iOS on webrtc.org. What kind of additional information would you consider valuable for mobile developers?

[Willem Vooijs]

Hi Niklas,

I'm not necessarily advocating a slower release cadence, I see the advantage of having fairly recent libs available for developers.

First issue: Right now, documentation is gathered by reading the SDK code and the demo AppRTC. I can live with that for now, but it should be easier to correlate the prebuilt lib version to a version of the code in Git, which is hard to find out, especially for new users. This correlation is critical, since the SDK changes frequently (which in itself is great) and as a consequence the documentation.

Second issue: When wanting to take an Android app to production, we need to be able to rely on a lib that is tested and works in the real world (for example running in latest Chrome). I don't think it is fair to ask Android devs to build their own WebRTC libs for this, since it is a real PITA for multiple reasons. I couldn't even build a specific branch for example, only master.

Can't we think of a solution where we have _both_ the WebRTC official releases and the latest weekly builds available as prebuilt libraries? Then devs can choose to run on latest if they really need to, but I think running the latest released version is sufficient and so much easier for most of us.

If this issue is fixed, writing how-to documentation in the future also becomes a lot easier since you only support pre-built release libs in this documentation.

Cheers,

Willem 

[Niklas Blum]

Hi Willem, 

comments inline.

On Monday, January 22, 2018 at 5:51:55 PM UTC+1, Willem Vooijs wrote:

Hi Niklas,

I'm not necessarily advocating a slower release cadence, I see the advantage of having fairly recent libs available for developers.

First issue: Right now, documentation is gathered by reading the SDK code and the demo AppRTC. I can live with that for now, but it should be easier to correlate the prebuilt lib version to a version of the code in Git, which is hard to find out, especially for new users. This correlation is critical, since the SDK changes frequently (which in itself is great) and as a consequence the documentation.

[blum] Yes, we are aware that there is, let's say, room for improvement when it comes to documentation ;-) Re. mapping of versions, we provide some guidance in the native section on webrtc.org. E.g., for Android the pre-build version of the library is 1.0.<Cr-Commit-Position>. The hash of the commit can be found in the .pom-file. 

 

Second issue: When wanting to take an Android app to production, we need to be able to rely on a lib that is tested and works in the real world (for example running in latest Chrome). I don't think it is fair to ask Android devs to build their own WebRTC libs for this, since it is a real PITA for multiple reasons. I couldn't even build a specific branch for example, only master.

 

[blum] All code gets tested the same way in our continuous build infrastructure. The closer you are with your app to ToT, the more likely you have a lib that provides fixes for already discovered bugs. A specific Chrome release is not a guarantee for a more stable lib version. There are also multiple Chrome M-releases across canary, dev, beta, and stable. Building on a specific WebRTC commit does not guarantee that you run the exact same code in Chrome and a native app. The development train basically moves always forward and we happen to do a cut when Chrome branches. Generally, I think that if you want to bring a WebRTC app to production, it’s of critical importance to gather your own stats to identify the performance of WebRTC in your environment over time. There are various solutions available either as open source or professional services. This allows you to identify issues early in your test and release cycle and report them.