ApsaraVideo Live:SDK download and integration

Bluetooth runtime permissions

The AndroidManifest.xml file in the ARTC SDK includes declarations for several permissions but does not contain the logic for requesting them at runtime. The BLUETOOTH_CONNECT permission, in particular, is a runtime permission introduced in Android 12. After you import the ARTC SDK, the following permissions are automatically merged into your app's manifest. Handle permission requests based on your app's specific use case.

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />

If your application does not require a specific permission, you can explicitly remove its declaration in your main project's AndroidManifest.xml file:

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" tools:node="remove"/>

Follow this guidance for Bluetooth permissions:

<!-- Declare the legacy Bluetooth permission -->
<uses-permission android:name="android.permission.BLUETOOTH" />
<!-- Override and remove the permission for API 31+ -->
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" tools:node="remove" />

<!-- Declare the legacy Bluetooth permission and set android:maxSdkVersion to 30 for backward compatibility -->
<uses-permission android:name="android.permission.BLUETOOTH"/>
<!-- Declare the Bluetooth permission for API 31+ -->
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT"/>
<!-- Other Bluetooth permissions -->

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    String[] permissions = {
        android.Manifest.permission.BLUETOOTH_CONNECT
    };
    ActivityCompat.requestPermissions(activity, permissions, REQUEST_BLUETOOTH);
}

<!-- Override and remove Bluetooth permission declarations from the ARTC SDK -->
<uses-permission android:name="android.permission.BLUETOOTH" tools:node="remove" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" tools:node="remove" />

Other runtime permissions

On Android 6.0 (API level 23) and later, you must request a dangerous permission at runtime. In addition to declaring the permission in the AndroidManifest.xml file, you must also request it in your code at runtime.

The following permissions require a runtime request:

• Manifest.permission.CAMERA

• Manifest.permission.WRITE_EXTERNAL_STORAGE

• Manifest.permission.RECORD_AUDIO

• Manifest.permission.READ_EXTERNAL_STORAGE

• Manifest.permission.READ_PHONE_STATE

On Android 12 (API level 31) and later, you must also request the following permission at runtime:

• Manifest.permission.BLUETOOTH_CONNECT

The following table describes relevant permissions.

Does the ARTC SDK introduce extra permissions?

After you import the ARTC SDK, the following Android permissions are automatically declared (The specific list may vary depending on the SDK version. For the definitive list, refer to the content of AndroidManifest.xml in the integrated .aar file):

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />

These permissions are primarily used for features such as network state detection, Wi-Fi information access, Bluetooth connectivity, and audio routing.

Handling permission conflicts

Although the ARTC SDK includes internal logic to handle Android version compatibility (such as the runtime permission requirement for BLUETOOTH_CONNECT on Android 12+), issues can still arise in certain scenarios:

• Build or runtime issues: Your app may experience manifest merge failures during the build process or unexpected behavior at runtime.

• Google Play review risks: If your app declares a permission for a feature it does not use (such as Bluetooth), it may violate the principle of least privilege and risk rejection from the Play Store.

To resolve these issues, use the following measures:

1. Evaluate permission requirements
   First, evaluate if your app truly needs all the permissions declared by the SDK. If a feature, such as Bluetooth, is not used, you can remove the corresponding permission declaration. For example, if your app runs only on devices with Android API 30 or lower, you can remove the declaration for the BLUETOOTH_CONNECT permission because your targetSdk version is 30 or lower.
   
   

2. Resolve conflicts by using Manifest merge directives
   If multiple modules declare different attributes for the same permission, such as an inconsistent maxSdkVersion, you can use the tools namespace in the main AndroidManifest.xml file to resolve the conflict:
   
   

   <manifest xmlns:android="http://schemas.android.com/apk/res/android"
       xmlns:tools="http://schemas.android.com/tools">
       
       <!-- Example: Remove a permission declared by the SDK but not needed by the app -->
       <uses-permission 
           android:name="android.permission.BLUETOOTH_CONNECT"
           tools:node="remove" />
           
       <!-- Example: Override a permission attribute -->
       <uses-permission
           android:name="android.permission.BLUETOOTH"
           android:maxSdkVersion="30"
           tools:replace="android:maxSdkVersion" />
   </manifest>