Normally, I'd expect a multi-touch sequence to start with an ACTION_DOWN and end either with an ACTION_UP or an ACTION_CANCEL.

ACTION_UP and ACTION_DOWN work as expected, i.e., the first and only the first pointer that goes down generates an ACTION_DOWN (other pointers generate an ACTION_POINTER_DOWN) and the last and only the last pointer that goes up generates an ACTION_UP (other pointers generate an ACTION_POINTER_UP).

However, the situation for ACTION_CANCEL seems a bit confusing. Most of places in code suggest that there is only one ACTION_CANCEL at the end of the sequence, e.g.:
 - lots of places in code that handle ACTION_CANCEL with ACTION_UP rather than with ACTION_POINTER_UP;
 - GestureProvider::ResetDetection() which seems to be the only place in GestureProvider that generates an ACTION_CANCEL;
 - GetActionFrom() in motion_event_web.cc.

But, there are places that suggest there is one ACTION_CANCEL per pointer, e.g.:
 - GestureProviderTest.GestureBeginAndEndOnCancel tests which generates one ACTION_CANCEL for each pointer in the test.

So, at the end I was not convinced either way.

One workaround that helps in some cases is to use the ACTION_DOWN that starts the next touch sequence as an indicator that the previous touch sequences in done. But, for this we should wait until the next touch sequence which might not always be suitable.

If I'm right in my assessment above and I've not missed anything, it seems that we need some deterministic way to know when a touch sequence is finished.