Both the number of colors and color value of -1 are correct. Each vertex is composed of an x and y coordinate. If you have 276 vertices, the command.vertices array will have a length of 552 elements. Colors are composed of a single 32-bit integer, encoding the red, green, blue and alpha channels, each in a byte. For every vertex, there is one color, so for 276 vertices, there will be 276 colors. A color value of -1 is 0xffffffff in hex, meaning red = 255, green = 255, blue = 255, and alpha = 255.
What seems to trip up Canvas.drawVertices() on Android < 10 is that the command.vertices and command.colors arrays may be bigger than what command.vertices.size and command.colors.size say. The reason for this is that we try not to allocate new memory if possible, but instead reuse existing arrays, if they can fit the required number of elements.
It seems the underlying implemention of Canvas.drawVertices() on Android < 10 actually queries the arrays length instead of using the number of vertices we pass to it. That will indeed result in crashes.
The solution for Android < 10 is not to not pass the colors array, but to temporarily allocate an array that has the exact number of elements as there are vertices, and copy over the colors from command.colors.items. This is super suboptimal, as we'll allocate a new array for each command ever frame!
Not passing colors is not a good idea, as that means that attachment colors will not work.
I'll modify the spine-android runtime to add this suboptimal fix for Android < 10. You can follow the issue here:
EsotericSoftware/spine-runtimes2638
