Nearby Devices permission on Android 12 and Above

mrapitis commented 1 year ago

Bug Summary

This issue is related to #1794. The app connection and registration fails when multiple apps are installed and a single app does not have permission for nearby devices on Android 12 and above. The scenario in the reproduction steps can be replicated by using a combination of iHeartRadio from the production Play Store. and HelloSDL built from the latest master branch in the java suite.

Reproduction Steps

Install iHeartRadio from the production Play Store on an Android 12 or above device.
Build and install HelloSDL on the same device from the master branch of the java suite github repository.
Provide Nearby device permission to the HelloSDL app in the app settings or in the app itself when prompted.
Connect the device over bluetooth to a Sync TDK.
Take note that no apps are registered on the HMI.
On the Android device, go to the App Permissions for iHeartRadio and provide permission for Nearby devices to iHeartRadio.
Disconnect and reconnect bluetooth on the Android device to cycle the bluetooth connection.
Take note that both iHeartRadio and HelloSDL are registered on the HMI.
Go back into the iHeartRadio settings and remove permission for Nearby devices.
Take note that both HelloSDL and iHeartRadio are removed from the HMI

Expected Behavior: Nearby device permission settings for one app do not impact the settings for another app. In the case above, the Nearby device permission from iHearthRadio should not impact the registration of HelloSDL

Observed Behavior: The Nearby devices app permission settings for a single app does impact other apps (in the case above HelloSDL cannot register due to iHeartRadio missing permission for Nearby devices).

Which projects have you seen this bug on?

Android

Android Version(s)

12

Android Device(s)

~~Essential~~ Nokia 8.3

sdl_java_suite Version

5.6.0

Testing Environment(s)

Ford Sync TDK

Relevant log output

No response

joeygrover commented 1 year ago

What build flavor of HelloSdl was used?
The Essential phone is discontinued and I do not believe ever received an official Android 12 update which is therefore likely using a custom ROM and is not supported by SDL. Can you confirm the issue on a different Android device that has an officially supported Android 12 OS?

mrapitis commented 1 year ago

What build flavor of HelloSdl was used?

multi_high_bandwidth debug and release. If needed I can retest with another build variant.

Can you confirm the issue on a different Android device that has an officially supported Android 12 OS?

The same results with an official Nokia 8.3 on Android 12.

joeygrover commented 1 year ago

multi_high_bandwidth is going to require a high bandwidth transport (USB/AOA, Wifi). Are you using a TDK that supports the TCP transport? I would test with multi_sec_off to eliminate some of the variables.
Do you know the version of the library the iHeartRadio app has?

mrapitis commented 1 year ago

I would test with multi_sec_off to eliminate some of the variables.

The issue continues to persist after switching to the multi_sec_off build variant.

Do you know the version of the library the iHeartRadio app has?

The issue is also reproducible with two instances of HelloSDL Android (instead of iHeartRadio). I can update the ticket to reflect this info if needed.

joeygrover commented 1 year ago

This is definitely a case we protected for as much as we could and included in our testing before release so it should not be showing as described.

joeygrover commented 1 year ago

Before you allow the permissions on the second app, have you tried reconnecting bluetooth or pressing the "find new apps" button? There is code that helps prevent the notification from appearing on cases where the BT device isn't SDL enabled and sometimes that requires the user to reconnect or perform an SDP query a second time (eg pressing the "find new apps" button) if it is the first that app is hosting the router service.

mrapitis commented 1 year ago

Before you allow the permissions on the second app, have you tried reconnecting bluetooth or pressing the "find new apps" button?

A bluetooth toggle or find apps query does not resolve the issue. From testing thus far, if the service that hosts the connection does not have the Nearby device permission granted neither of the apps will connect. If the service that hosts the connection has nearby devices granted, both apps connect (even if the non-host has Nearby devices permission disabled).

joeygrover commented 1 year ago

Right, which is why there is code to try and prevent that from happening:

// If all apps have a RS newer than the Android 12 update, 
// chosen app does not have BT Connect permissions, and more than 1 sdl app is installed
if (!isPreAndroid12RSOnDevice(sdlAppInfoList) 
            && !AndroidTools.isPermissionGranted(BLUETOOTH_CONNECT, context, routerServicePackage) 
            && sdlAppInfoList.size() > 1) {
    for (SdlAppInfo appInfo : sdlAppInfoList) {
        if (AndroidTools.isPermissionGranted(BLUETOOTH_CONNECT, context, appInfo.getRouterServiceComponentName().getPackageName())) {
            //If this app in the list has BT Connect permissions, we want to use that apps RS
            routerServicePackage = appInfo.getRouterServiceComponentName().getPackageName();
            break;
        }
    }
}

Can you confirm the two applications used were the only SDL enabled apps on the device? This is important because if there is an app that is on the device that doesn't have the newer library with these changes then the old logic for RS starting will be used (newest RS is started regardless of permission status), this is an unchangeable legacy issue.

mrapitis commented 1 year ago

Can you confirm the two applications used were the only SDL enabled apps on the device?

To eliminate variables all other SDL enabled apps have been uninstalled. Only the two instances of HelloSDL remain... tested repeatedly, but the issue still exists.

JulianKast commented 1 year ago

I have tested with two instances of HelloSDL and do not see the issue you describe.

1. Install HelloSDL on an Android 12 or above device, do not give BT permission.
2. Build and install a slightly modified version of HelloSDL on the same device from the master branch of the java suite github repository. (Modified = Update app name, ID and change app package)
3. Provide Nearby device permission to the modified HelloSDL app in the app settings or in the app itself when prompted.
4. Connect the device over bluetooth to a Sync TDK.
Both apps are appearing on TDK. The router service is hosted by app that has BT permission.

Also to clarify FordPass and Webex are SDL apps that could have an older implementation of SDL

JulianKast commented 1 year ago

Can you run your test again using the two apk's in the zip file provided: apk zip.zip

mrapitis commented 1 year ago

@JulianKast so far the samples you attached look to have an improvement in connectivity. Did the apps include library or app side changes?

JulianKast commented 1 year ago

Both apps are HelloSdl using unmodified versions of SDL on build variant multi_sec_off_debug. For one app, I changed the app package, app name, Sdl app name, and SDL app ID.

For our app partners, we have noticed two common issues that can be resolved by:

Making sure SdlService is exported in their AndroidManifest

android:exported="true"

Adding changes to how they start a service for Android S. Starting with Android S SdlService needs to be started from a foreground context. A link to an example is here: https://github.com/smartdevicelink/sdl_java_suite/blob/c5b805411cc285c0ade2933a22c4134c922a1b13/android/hello_sdl_android/src/main/java/com/sdl/hellosdlandroid/SdlReceiver.java#L25-L It is also covered in the migration guide here: https://smartdevicelink.com/en/guides/android/migrating-to-newer-sdl-java-suite-versions/updating-to-v54/#starting-services-from-the-foreground

mrapitis commented 1 year ago

The two instances of HelloSDL that were provided register consistently when they are the only SDL enabled apps installed on the device, however after installing another SDL enabled app like Pandora or iHeartRadio from the production Play store none of the SDL apps register (including the HelloSDL instances). If the newest service is being used for the connection, I believe the HelloSDL apps should have registered in this scenario?

joeygrover commented 1 year ago

I am unable to reproduce any library specific issues with apps that have 5.4+ version of the library and correct implementations of SDL.

Two HelloSdl apps with one having a different package, SDL App ID & name works as expected.
Installed iHeartRadio with two HelloSDL apps. If either HelloSDL apps were the only app to have permissions they would register with the IVI while the iHeartRadio app would not. If the iHeartRadio app had Nearby Device permission and hosted the router service, all apps would register. (Likely an issue that Julian called out previously with the newer Android service requirements).
Installing an app with an older version of library <5.4: The newest router service would be expected to start, however, if the app with the older library didn't have the correct permissions it would not start and therefore no transport connection was made.
Install app with an incorrect SDL implementation with a version of the library < 5.4. Results can vary. However in this instance the app did not implement the router service requirements at all and therefore breaks the ecosystem.

Situation 3 and 4 are problems. If the app with the pre-Android 12 compatible SDL library (<5.4) is installed on the device but they target Android 12 and do not have the Nearby Device permission granted, they will never receive the BT connected intent and therefore never start a router service. This prevents the redundancy permission check from happening inside the RS that will start the next RS if it doesn't have the correct permissions.

I can say this was not a case that seems to be protected for in the library. Since targeting Android 12 was not a requirement from Google until recently, there was no way for us to know if an app was targeting Android 12 or newer. If they targeted less than Android 12 then they would not need the Nearby Device permission to receive the BT connected intent. It is plausible that we add yet another step in this complicated process that checks specifically for this scenario (older libraries installed but Nearby Devices permission not granted with the assumption that all apps must now target Android 12+) and in that case use the same logic for when only newer SDL libraries are installed.

However, even if we add this, the problem only solves itself over time as apps update their libraries and users grant those apps the correct BT permissions. This assumes that apps also have correct implementations of SDL.

smartdevicelink / sdl_java_suite