BroadcastQueue now uses scheduleReceiverList
Bug: 253906553
Convert the broadcast queues to the new scheduleReceiverList API in
IApplicationThread. The changes are as follows:
1. The ReceiverBatch class is created to handle the arguments to
scheduleReceiverList. The class has additional functionality in
preparation for allowing batches of more than one receiver. The
ReceiverBatch class is essentially bookkeeping: it maintains lists
of information for a client.
The ReceiverBatch class has a single() method that does everything
necessary to dispatch a single manifest or registered receiver.
In normal operation, the ReceiverBatch class uses object pools and
does not do any allocation after it has been instantiated. There
is a test mode that always allocates new objects. See the notes
on BroadcastQueueTest.
2. BroadcastQueueImpl and BroadcastQueueModernImpl each contain an
instance of ReceiverBatch, size 1, and use that instance to invoke
scheduleReceiverList.
3. BroadcastQueueTest is modified to test against the new thread
API. There are changes in the support methods in the class. The
intent is that the actual test code looks like a textual rewrite
rather than a logical rewrite.
4. BroadcastConstants includes a MAX_BROADCAST_BATCH_SIZE, which is
set to 1. This is not required for this CL but is a stake in the
ground to minimize future merge conflicts. This constant will be
increased when the modern queue supports more than one receiver in
a batch.
5. BroadcastRecord has two new per-receiver attributes: the transmit
group and the transmit order. These are initialized in the
ReceiverBatch.recordBatch() method (which is not called in this
commit). Again, this is a stake in the ground to minimize future
merge conflicts.
There is no behavioral change in this commit.
Test: atest
* FrameworksMockingServicesTests:BroadcastQueueTest
Change-Id: I543092cdd68a979fb466a2156c251c6c4f024b61
6 files changed