SerialPortExample | yet complete example of an Android app | Android library

The MainActivity has a a handler that handles the messages from the from the USB Service

This is not a good plan.

My App has several Activities, and many of them have views that should change if certain data comes across the serial port.

This illustrates why the not-good plan is not good. The data come from the serial port is not tied exclusively to MainActivity... so why would MainActivity be handling the USB service messages?

(it is also fairly likely that you should not have multiple activities here and instead have one activity with multiple fragments, but I'll leave that aside for now)

what are alternatives to achieving what I need

I don't know what is on the other end of the serial port that is causing the messages to be sent. For the purposes of this answer, I will call it a "thingy".

Step #1: Create a ThingyRepository. This will be a class (with a singleton instance) that manages the USB serial connection and receive the messages. It will hold onto some representation of the current state based on past messages (ThingyState) and it will update that state as new messages come in.

Step #2: Have ThingyRepository expose some sort of "reactive API". That could be something modern, such as LiveData or RxJava. It could be something older, like a callback-based API. Either way, you want ThingyRepository to deliver updated ThingyState objects to interested parties ("observers") when the state changes. So, ThingyRepository converts USB serial messages into updated states, and it emits those states as needed.

Step #3: Have your UI observe ThingyRepository, receive the ThingyState objects, and update the UI based on those states. Ideally, you would use ViewModel to mediate those communications, to deal with Android's configuration changes (screen rotations, etc.). But, if you wanted to stay "old-school", the activity could register a callback with your ThingyRepository, where ThingyRepository can call the callback with a fresh ThingyState as the data changes based on the USB messages.

Now, you have decoupled the state changes from any single activity. Each activity can be responsible for figuring out what needs to change in its own UI based on the new state. And, you no longer need static views.