Due to the UCI time control management error of Chess for Android which has recently been identified thanks to Pedro, the author of DanaSah, i've got a little bit worried about the accuracy of Rapidroid for which i take heavy care from the beginning.
I finally concluded that there may be a slight error distributed on all UCI engines related to how many times they played against XB engines which support incremental clock, like ExChess, Crafty, Resp and some others.
This is simply related to the default setting of 900+2 of the experiment. The above mentioned bug of CfA implies that xb engines correctly use 2 seconds incremens while their UCI rivals use only 2 milliseconds. Although the unused difference is sent back with the following move to the engine via time command, overall time usage behaviour of UCI engines becomes less agressive than expected, leading to a slight accumulation.
In some extreme cases, i guess there may be up to 3 ELO loss for some UCI engines and up to 10 ELO gain for xb engines which play with incremental clock.
The unfair ELO gain doesn't apply to xb engines which play with time per move setting only.
In the big picture, there's nothing to worry about given that the overall statistical error margins are much wider, around +/- 30 ELO.
But i remain sceptical. As a corrective action, i already switched to 900+0 without increment in ongoing gauntlets of Cinnamon, Rhetoric and Sayuri. Until Aart Bik fixes CfA, i will keep 0 increment.
Regarding the XB engines, there are quite a lot to start playing incremental (Fischer) clock. I'm about to finish compatibility tests and approximately 90% of them can switch to the default time control of Rapidroid, which means most of the rounds can be played at once without splitting into two separate tournaments. Speed matters!
Another good news is that the last fix by Aart will probably add 15 more engines to the ranking.
And the bad news is the same, once again: Thousands of games must be replayed to reflect all the changes...