Block type IDs must be the same across all threads, as they are used in the form of state IDs to transfer chunks between threads for sending over the network.
This can become problematic if one particular plugin fails to initialize its blocks (or if the setup happens in an unusual order), as the type IDs given will then be different.
The current recommendation is for plugins to copy the type ID from the main thread rather than using ::newId() within any other threads. However, this creates additional problems: plugins could then configure new blocks whose IDs conflict with those of existing custom blocks, as the system won't be aware of the fact that these dynamic type IDs were given by another thread. (In short, if a plugin creates a new block type within an AsyncTask, it might be given a type ID that's already in use).
Description
Block type IDs must be the same across all threads, as they are used in the form of state IDs to transfer chunks between threads for sending over the network.
This can become problematic if one particular plugin fails to initialize its blocks (or if the setup happens in an unusual order), as the type IDs given will then be different.
The current recommendation is for plugins to copy the type ID from the main thread rather than using ::newId() within any other threads. However, this creates additional problems: plugins could then configure new blocks whose IDs conflict with those of existing custom blocks, as the system won't be aware of the fact that these dynamic type IDs were given by another thread. (In short, if a plugin creates a new block type within an AsyncTask, it might be given a type ID that's already in use).
Alternative methods