WebRTC release notes for Android/IOS

[Olivier Anguenot]

Hello,

I'm currently developing an Android and IOS applications that integrate WebRTC and these applications are "in production" and so used by lot of people.

But each time there is a new version of the Android and IOS stacks, instead of being happy, this makes me fear because, I think I should migrate to have the latest improvements as well as the latest fixes (as for any third party libraries) but due to the lack of information, this task (migration) is complicated.

Today, there is the MXX release note that describes in details the changes for the browser but what is the link between a Mxx version and the IOS and Android build ? 

Additionnaly, where are the release notes dedicated to the Android and IOS builds ? 

I really need to have these information in order to prepare any migrations to a new version and avoid any regressions.

But perhaps I missed some links !

Could other mobile developers share how they do ? 

Thanks in advance for sharing your inputs, 

Regards,

Olivier

[Alexandre GOUAILLARD]

hi olivier,

The mobile releases are not aligned with chrome.

Note that according to google, all commits are equally good (or bad), and the mXX numbers are just provided as a convenience to sync code, and not as a notion of increased quality or scrutiny.

That means that, if you're dealing with the mobile version, you are free to:

- use google packaged ones which are not sync with the mXX tags

- build your version in sync with mXX tags

- build your version against any arbitrary commit.

When finding a bug on mobile, you will likely be asked to tests against HEAD anyway, and to use appRTCMobile.

When testing for interoperability (for example using appr.tc in the browser and the appRTCMobile app) you might want to sync. 

Hope this helps.

Dr. Alex.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8366f7bf-a6a4-4d60-b07b-346442a080f8%40googlegroups.com.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Olivier Anguenot]

Hi Alex,

Thanks for your quick answer.

At this time, we don't suffer from interoperability issues (at my knowledge :-) ), we made the job to move to Unified Plan and we are in a transition loop where some calls can be made using Unified plan and others using Plan-B. 

One a my concrete issue is that on IOS sometime ICE state stays blocked in "Checking" state without never switching to "Connected" or "Failed". So we tried to implement a "retry" mechanism (renegotiation) every 5s if that cases.

But when moved to the latest IOS WebRTC version, we discovered (by looking in the WebRTC the source code) that there are different listeners PC state, ICE state. 

My difficulties is to have information on what to do to adapt my current code in order to know if I have to move my logical code (retry...) to the new PC state. So, sometime, I have to go to the Firefox documentation to understand the API...

And now after 6 months without any information, a new Android WebRTC version is available... Will I have to do the same ?

So the lack of information is a paint point for me as my application is no more in development. I have real users that are not happy because calls can't be established in some cases and I really need to be sure to "master" the WebRTC stack in a development point of view to bring the best integration. Any other third party libraries I used bring clear release notes and documentation API with all changes or information the developers have to know for all supported plateforms.

For web developers, release notes are very good and detailed. But for IOS and Android developers... I expect the same level of information.

But perhaps as I mentioned, there is documentation somewhere...

Olivier

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8366f7bf-a6a4-4d60-b07b-346442a080f8%40googlegroups.com.

[Alexandre GOUAILLARD]

My difficulties is to have information on what to do to adapt my current code in order to know if I have to move my logical code (retry...) to the new PC state. So, sometime, I have to go to the Firefox documentation to understand the API...

And now after 6 months without any information, a new Android WebRTC version is available... Will I have to do the same ?

likely yes. There is no standard governing the android and obj-c API, only on-the-wire specifications, so the API is likely to change user you rom one release to the next.

So the lack of information is a paint point for me as my application is no more in development. I have real users that are not happy because calls can't be established in some cases and I really need to be sure to "master" the WebRTC stack in a development point of view to bring the best integration. Any other third party libraries I used bring clear release notes and documentation API with all changes or information the developers have to know for all supported plateforms.

AFAIK, the official location for pre-compiled packages is:

https://bintray.com/google/webrtc/google-webrtc

Since you already posted this, your second best move is to open a ticket.

https://bugs.chromium.org/p/webrtc/issues/list

No guarantee though.

For web developers, release notes are very good and detailed. But for IOS and Android developers... I expect the same level of information.

But perhaps as I mentioned, there is documentation somewhere...

 

In our own packages (which we sell btw), we provide migration guides and extra examples to show code changes to help transitioning the code.

https://www.cosmosoftware.io/products/libwebrtc-packages

[Philipp Hancke]

Am Do., 19. Dez. 2019 um 16:20 Uhr schrieb Olivier Anguenot <oang...@gmail.com>:

Hello,

I'm currently developing an Android and IOS applications that integrate WebRTC and these applications are "in production" and so used by lot of people.

But each time there is a new version of the Android and IOS stacks, instead of being happy, this makes me fear because, I think I should migrate to have the latest improvements as well as the latest fixes (as for any third party libraries) but due to the lack of information, this task (migration) is complicated.

Today, there is the MXX release note that describes in details the changes for the browser but what is the link between a Mxx version and the IOS and Android build ?

Well, they don't include everything that happens in Chrome either. In particular regressions or unexpected changes in behaviour.

Additionnaly, where are the release notes dedicated to the Android and IOS builds ? 

I really need to have these information in order to prepare any migrations to a new version and avoid any regressions.

But perhaps I missed some links !

Could other mobile developers share how they do ?

What i've seen in a couple of places is the following:

- wait for a chrome release to happen, wait a couple of weeks and watch the bugtracker for issues

- look at the git changelog between the versions, read *every* commit message at least so you know what has changed at a high level. This is enough effort to do it not on every new chrome version but you don't want the changes to get too big either.

- make a build, QA it according to some checklist you have for it

- distribute it to internal users via testflight or similar, ask people to test

- submit new version to the store, then do a gradual rollout to 10%-ish

- make sure performance metrics (bitrate, connectivity, ...) of the new version have not regressed. Make sure your support has the tools to correlate user reports with the new version.

- increase rollout percentage, monitoring metrics

- if things go bad, revert, file a bug and ideally a workaround

Not being forced to roll a new version including regressions is an advantage you have on mobile compared to web.

On the other hand getting a new version published to the store is more difficult than rolling back a js file so...

And yes, this is extremly time-consuming.

 

Thanks in advance for sharing your inputs, 

Regards,

Olivier

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.