The mystery of the matching miss-matched App versions

Over the past few years there has been an occasional, but persistent, problem during the FTC Inspection process, whereby the Self-Inspect screens have indicated a version mismatch, but when checked, the Driver Station and Robot Controller apps DO display the same version (e.g. 8.0)

Thanks to some teams at the FTC World Championship providing us access to their code, the cause for this problem has finally been identified. It turns out that the mismatch was in fact real, but the individual RC App version display was incorrect.

This problem was caused by a third-party library which had a different compiled-in SDK version.
For example, the team’s project was built with 8.0 SDK code, but the team has also incorporated a math library that included 8.1.1 SDK code.

This caused two different versions to be present in the Robot Controller. But Android had silently “solved” this problem by “deciding” to use the latest 8.1.1 version. This was unexpected.

Once this double version problem was identified, we realized that specific inspection problem occurred because our inspection code was checking the corrects versions, but was displaying the “intended” RC version, not the one that Android was actually using.

Anyway, this problem will be corrected in the next release, and the Inspection screens will show the App version code that Android is actually running.

The upshot of this is that teams using third party libraries will need to verify that those libraries don’t include miss-matching SDK elements built into them, as these may cause inspection to fail or worse, unexpected code errors. The bottom line is that if inspection says there is a mismatch, there is one!

Ultimately, third-party libraries should be designed to use the SDK elements that are included as part of the team’s project, rather than having them compiled into the library. A better technical description of how this should be done will follow later.


I’m glad this mystery has finally been revealed.