Fix remote-submix not found for MIX_TYPE_RECORDERS LOOPBACK

[Context]
When a LOOPBACK dynamic audio policy mix PLAYER/RECORDER
is registered, first the REMOTE_SUBMIX device that will be
used by the app to capture/play respectively is activated.

Eg a mix RECORDER (used to inject audio to apps recording),
when registered will activate an OUT_REMOTE_SUBMIX.

Then the app can open a record/playback track on this
REMOTE_SUBMIX, which will trigger the other end of the pipe
to be activated.

Following this the playback/Record Tracks that match the
mix will be routed to the IN/OUT REMOTE_SUBMIX.

[Example for an app FUU]
 1) App FUU register Playback/record mix
    2) APM activates out/in remote submix
 3) App FUU opens track to out/in remote submix
    4) APM activates in/out remote submix
 5) tracks matching mix are redirected to the out/in remote submix

When an OUT_REMOTE_SUBMIX is activated, it tries to check if it matches
a mix, if it does, it saves the output in the mix (in mOutput).
This output is then used to find a matching mix output in
getOutputForAttr(). If a mix has no output is is considered inactive.

Note that IN_REMOTE_SUBMIX do not save their input in the mix, the
input is queried by APM each time in its mAvailableInputDevices.

[Issue]
The issue is that in step (2), when an OUT_REMOTE_SUBMIX is
activated (thus for a MIX_TYPE_RECORDERS), no mix is matched because the
mix is of type IN_REMOTE_SUBMIX as it will be used to route AudioTracks
in step (5).
Thus no mix output is found in getOutputForAttr and the step (3) fails.

This is a recent regression as previously the type was not checked when
looking up for a mix in step (1).

The Change-Id of the patch that caused the regression is:
I4dc7f23bef19a7d47afc2998102da07dde41fbca, its sha1 is:
679172768d

[Workaround]
For now, given the release timing, implement a minimal fix that restore
the previous behavior for the OUT_REMOTE_SUBMIX output save lookup.
Aka, make sure to query for a IN_REMOTE_SUBMIX mix in step (2).

Step (4) is fine as the mix type is the same as the REMOTE_SUBMIX type.

As IN_REMOTE_SUBMIX do not attempt to save their output in the mix, no
issue is present on this code path.

A proper fix needs to be implemented on master, preferably by having the
same device save behaviour on both mix type.

Bug: 134068143
Test: Wifi calling call screening
Test: atest AudioPlaybackCaptureTest AudioHostTest
Change-Id: I1547948ae412dbdeb2d85cc62bf18f7ac5f1efc0
Signed-off-by: Kevin Rocard <krocard@google.com>

services/audiopolicy/common/managerdefinitions/src/AudioPolicyMix.cpp

@@ -120,8 +120,9 @@ status_t AudioPolicyMixCollection::getAudioPolicyMix(audio_devices_t deviceType,
 
     ALOGV("getAudioPolicyMix() for dev=0x%x addr=%s", deviceType, address.string());
     for (ssize_t i = 0; i < size(); i++) {
-        if (itemAt(i)->mDeviceType == deviceType
-                && itemAt(i)->mDeviceAddress.compare(address) == 0) {
+        // Workaround: when an in audio policy is registered, it opens an output
+        // that tries to find the audio policy, thus the device must be ignored.
+        if (itemAt(i)->mDeviceAddress.compare(address) == 0) {
             policyMix = itemAt(i);
             ALOGV("getAudioPolicyMix: found mix %zu match (devType=0x%x addr=%s)",
                     i, deviceType, address.string());