7926fe4632
Persistent apps are guaranteed to be running, are never frozen, and could get out of sync if broadcasts are deferred. Accordingly, never defer those broadcasts. Additionally, there was a case where both the persistent and instrumented flags could be incorrect: 1. App starts and hits attachApplicationLocked without ever being a broadcast target. 2. BroadcastQueueModernImpl.onApplicationAttachedLocked runs, but there is no queue for the app because nothing has enqueued a broadcast (which calls getOrCreateProcessQueue). Importantly, queue.setProcess(app) is not called. 3. Eventually, something enqueues a broadcast for the app. This calls getOrCreateProcessQueue as part of enqueueBroadcastLocked. 4. getOrCreateProcessQueue creates the queue and manually assigns app without calling setProcess. 5. mProcessInstrumented and mProcessPersistent are never assigned. The fix is to call setProcess(ProcessRecord) from getOrCreateProcessQueue when a ProcessRecord is available when a queue is created for an app. Test: atest FrameworksMockingServicesTests:BroadcastRecordTest Test: atest FrameworksMockingServicesTests:BroadcastQueueTest Test: atest FrameworksMockingServicesTests:BroadcastQueueModernImplTest Test: atest CtsWifiTestCases:android.net.wifi.cts.ConcurrencyTest#testRequestNetworkInfo Bug: 258718309 Change-Id: I3059cc602b8bc75d72fe3c15dd6674f91a37a0cd