From Android 12 onwards, Foreground Service can not be launched from Background Service unless you have turned OFF Battery Optimization settings.
Hence, crash would be observed if any app uses SAP SDK inside Background Service.
For more details refer to this link

Possible Solutions:

1. The user turns off battery optimizations for your app.
2. You can help users find this option by sending them to your app's App info page in system settings.
   To do so, invoke an intent that contains the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent action.
   For more details refer to this link

As per Android 12 behavior changes, the activities, service and receiver need to declare the exported attribute explicitly if it uses intent filters.
Please make below changes in your application's manifest file.

1. Set the exported attribute to true for below broadcast receivers.

• "com.samsung.android.sdk.accessory.RegisterUponInstallReceiver"
• "com.samsung.android.sdk.accessory.ServiceConnectionIndicationBroadcastReceiver"
• "com.samsung.android.sdk.accessory.MessageReceiver"

Please refer below code snippet.

<receiver
            android:name="com.samsung.android.sdk.accessory.RegisterUponInstallReceiver"
            android:exported="true">
<intent-filter>
<action android:name="com.samsung.accessory.action.REGISTER_AGENT" />
</intent-filter>
</receiver>
<!-- Receiver must be declared when using SASocket -->
<receiver
            android:name="com.samsung.android.sdk.accessory.ServiceConnectionIndicationBroadcastReceiver"
            android:exported="true">
<intent-filter>
<action android:name="com.samsung.accessory.action.SERVICE_CONNECTION_REQUESTED" />
</intent-filter>
</receiver>
<!-- Receiver must be declared when using SAMessage -->
<receiver
            android:name="com.samsung.android.sdk.accessory.MessageReceiver"
            android:exported="true">
<intent-filter>
<action android:name="com.samsung.accessory.action.MESSAGE_RECEIVED" />
</intent-filter>
</receiver>

2. If your activity contains LAUNCHER category, please set the exported attribute to true.

<activity
            android:exported="true"
            android:name=".ConsumerActivity"
            android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

For more information, see Behavior changes: Apps targeting Android 12.

Android 11 changed the visibility of some apps installed on a device. You need to add the following to your AndroidManifest.xml file that makes the Samsung Accessory Service Framework visible to your app:

<queries> <package android:name="com.samsung.accessory"/> </queries>

For more information, see Package visibility in Android 11.

At first, check your ProGuard configuration. If not, add lines to exclude Accessory SDK. The application cannot work fine or communicate with peer application.

A Service is a collection of features tied to a specific application on a Samsung smart device or accessory device. For example, an alarm service can provide features for adding and deleting alarms, enabling and disabling alarms, and receiving alarm alert notifications.

An Accessory Service Profile defines the service roles, the message formats, and the message sequences for the service. For example, the alarm service mentioned above can define JSON messages to get a list of alarms set on a Samsung smart device so that alarm data can be synced.

A Service Provider is an application that runs on either a Samsung smart device or an accessory device that provides a service.

A Service Consumer is an application that runs on either a Samsung smart device or an accessory device that uses information provided by a service provider application.

For example, the alarm service mentioned above can consist of an alarm service provider application running on a Samsung smart device and an alarm service consumer application running on an accessory device. The alarm service consumer sends a JSON message to get the list of alarms set on a Samsung smart device and the alarm service provider responds with a JSON message that contains a list of alarms set on the Samsung smart device.

The Accessory SDK helps you to create applications that benefit from connections between Samsung smart devices and accessory devices. For example, you can sync alarms set on a smart device with a Samsung Galaxy series device. The Samsung Accessory Service Framework and the Accessory SDK provide an abstraction layer for different connectivity technologies and message transfer mechanisms. You can define messages (for instance, using JSON) and indicate your preferred connectivity method at the application level. The Samsung Accessory Service Framework and the Accessory SDK manage the connections and messaging between the smart device and the accessory device. This lets you focus on the use cases that you want to include in your application without thinking about messaging and connectivity.

No. The Accessory SDK provides an abstraction layer for all this information. You only need to know the terminologies defined by the package and the classes and methods exposed by Accessory.

Service providers and service consumers use a SASocket object to exchange messages. The send() and onReceive() methods are used to send and receive data. For more information on the SASocket class, see the Accessory API reference. The actual messages exchanged by a service provider and service consumer can be in JSON or Binary formats. For a detailed explanation of the supported JSON messages, see the relevant Service Profile descriptions.

You use the Accessory Services XML file to register your service provider or service consumer with the Samsung Accessory Service Framework to allow the framework to advertise services. For more information on the XML tags defined in accessoryservices.xml, see the “Using Accessory” section of Programming Guide.

Create an Accessory Services file (accessoryservices.xml) and store it in the /res/xml path of your application. Add the following lines in your Android manifest file (AndroidManifest.xml) for automatic registration:

<receiver android:name="com.samsung.android.sdk.accessory.RegisterUponInstallReceiver">
    <intent-filter>
        <action android:name="com.samsung.accessory.action.REGISTER_AGENT" />
    </intent-filter>
</receiver>

Using the information in your Accessory Services file, the Accessory SDK automatically registers your application with the Samsung Accessory Service Framework when your application is installed.

Add the lines below to your proguard-project.txt to exclude Accessory SDK for the ProGuard.

    - keepclassmembers class com.samsung.** { *;}
    - keep class com.samsung.** { *; }
    - dontwarn com.samsung.**
    - keepattributes InnerClasses
    - keepclassmembers class [Application’s SASocket or SAAgent extended class].** { *; }
    - keep class [Application’s SASocket or SAAgent extended class]** { *; }

See the “Obfuscating the Application Using ProGuard” section of the Programming Guide for more details.

Yes. If the application is using the Accessory File Transfer Service, it must also include the Accessory library in its libraries. But from 2.3.0, the Accessory and Accessory File Transfer libraries are combined into one. So, you don’t need to care about it.

No. Applications can use the Accessory File Transfer Service whether they have a service connection with their peer or not.

Check whether the broadcast receiver for incoming file transfer is declared on the receiver side. The broadcast receiver must be declared in the AndroidManifest.xml file:

<receiver android:name="com.samsung.android.sdk.accessoryfiletransfer.SAFileTransferIncomingRequestReceiver">
<intent-filter> <action android:name="com.samsung.accessory.ftconnection" /> </intent-filter> </receiver>

Yes. The Accessory File Transfer Service runs on a separate thread, as do the update callbacks. Hence, UI processing has no effect on the file transfer functionality. However, it’s better to avoid heavy UI tasks on the callbacks.

Yes. You can list the properties of all the service providers in your Accessory Services file. Also, you can create a single service consumer application for multiple service providers. But, within that application, you need to have separate Service Implementation classes derived from SAAgent for each service provider. For example, if you have a call and SMS service providers in one application, your service consumer application needs to have two separated implementation classes (like Call_Consumer and Sms_Consumer, both derived from the SAAgent class) and handle the application logic accordingly

Usually yes. But for convenience, Accessory SDK initializes internally when the first call to any Accessory method is made. When your application’s implementation extends the SAAgent class, the Accessory SDK is initialized in SAAgent.onCreate(). This means that you do not need to initialize the Accessory SDK as long as your application’s SAAgent subclass does not override SAAgent.onCreate().

The Accessory SDK provides a number of error codes that are propagated to your application for connectivity failures and other error conditions. For a detailed explanation of the error codes, see “Field Detail” for the SAAgent and SASocket classes in the Accessory API reference. You can handle the error codes in your applications to recover from errors. For example, you can display an error popup to the user or try to reestablish a connection after a defined amount of time expires.

Yes. You can do this with the SAAgent.findPeerAgents() method. When you call SAAgent.findPeerAgents(), the Accessory SDK looks for services that match your service profile ID and are peers with your application (for example, if your application is a service consumer, the Accessory SDK returns matching service providers), and indicates the search result in the SAAgent.onFindPeerAgentResponse(SAPeerAgent, int) method. If the result parameter in this method is SAAgent.PEER_AGENT_FOUND, it means that the specific service is supported in the peer device

Your service provider application is registered with the Samsung Accessory Service Framework when your application is installed. When a service consumer peer application begins service discovery and requests a service connection, the Accessory SDK sends your service provider the request using the SAAgent.onServiceConnectionRequested(SAPeerAgent) method. You can accept or reject the service connection request using the SAAgent.acceptServiceConnectionRequest(SAPeerAgent) or SAAgent.rejectServiceConnectionRequest(SAPeerAgent) method. Once the service connection is established, your service provider is up and running. You can start exchanging messages between the service consumer and service provider.

No. A service connection can also be initiated by the service provider. The connection establishment logic is the same as in the sample code; service discovery is followed by the establishment of a service connection.

Check the Accessory Services description file (accessoryservices.xml) of the service consumer and service provider:

• The id field of the tag must be the same for both like id=”/sample/hello”.
• The id field of the tag must be the same for both like <serviceChannel id=”101”.

Check also the detailed error codes that are propagated in the SAAgent.onFindPeerAgentResponse(SAPeerAgent, int) and SAAgent.onServiceConnectionResponse(SASocket, int) methods. For more information on the error codes and on handling error conditions in your application, see the Accessory API reference.

Service, Accessory Service Profile, Service Provider and Service Consumer.

The Samsung Accessory Protocol uses the concept of a Service to simplify implementations. Applications define a service profile for communication between peers to support specific use cases. The Accessory SDK and the Samsung Accessory Service Framework provide an abstraction layer to manage connectivity and service profile messaging between applications. You do not need to rewrite basic use case code of a service profile for specific connectivity methods.

The Accessory File Transfer Service has its own queuing mechanism. It queues all file transfer requests, even from multiple applications, and services them sequentially. Applications are not allowed to maintain their own queues for file transfers.

No. The Accessory File Transfer Service uses its own thread for all file transfers. The file transfer updates are also handled asynchronously. This implementation allows simple and direct API calls to handle the user file transfer.