# Release notes (/en/realtime-media/rtm/reference/release-notes/flutter)

> For AI agents: see the complete documentation index at [llms.txt](/llms.txt).

The Agora Signaling SDK provides a streamlined and stable messaging mechanism for you to quickly implement real-time messaging for various use-cases. See [Product overview](/en/realtime-media/rtm) for more information.

This page contains release notes for each Signaling SDK platform.

      
  
      
  
      
  
      
  
      
  
      
  
      
    ### Known issues and limitations [#known-issues-and-limitations-5]

    <Tabs defaultValue="android" groupId="flutter-host-platform">
      <TabsList>
        <TabsTrigger value="android">
          Android
        </TabsTrigger>

        <TabsTrigger value="ios-macos">
          iOS and macOS
        </TabsTrigger>
      </TabsList>

      <TabsContent value="android">
        Starting from v2.2.0, the Signaling SDK and Video SDK (version 4.3.0 or later) both include the `libaosl.so` library. If you use both SDKs, take the following steps to avoid conflicts:

        * If you manually integrate the SDK through CDN, manually delete the older version of the `libaosl.so` library;
        * If you integrate the SDK using a dependency management tool, such as Maven or CocoaPods, ensure that the newer version of the `libaosl.so` library is included in your project.

        For more information, see [How do I handle issues when integrating the Signaling SDK and Video SDK simultaneously?](/en/api-reference/faq/integration/rtm2_rtc_integration_issue)

        * Signaling SDK v2.2.2 `libaosl.so` version: 1.0.11.
        * Signaling SDK v2.2.1 `libaosl.so` version: 1.0.11.
      </TabsContent>

      <TabsContent value="ios-macos">
        Starting from v2.2.0, the Signaling SDK and Video SDK (version 4.3.0 or later) both include the `aosl.xframework` library. If you use both SDKs, take the following steps to avoid conflicts:

        * If you manually integrate the SDK through CDN, manually delete the older version of the `aosl.xframework` library;
        * If you integrate the SDK using a dependency management tool, such as Maven or CocoaPods, ensure that the newer version of the `aosl.xframework` library is included in your project.

        For more information, see [How do I handle issues when integrating the Signaling SDK and Video SDK simultaneously?](/en/api-reference/faq/integration/rtm2_rtc_integration_issue)

        * Signaling SDK v2.2.2 `aosl.xframework` version: 1.0.11.
        * Signaling SDK v2.2.1 `aosl.xframework` version: 1.0.11.
        * Signaling SDK v2.2.0 `aosl.xframework` version: 1.0.0.17.
      </TabsContent>
    </Tabs>

    ### v2.2.5 [#v225]

    v2.2.5 was released on September 25, 2025.

    #### Compatibility changes [#compatibility-changes-18]

    * **Snapshot event trigger timing**

      The `Snapshot` event in Presence events can now be triggered again as long as a user is in the channel. After receiving it, update the complete information to avoid state synchronization issues caused by exceptions.

    * **Lock expiration time calculation**

      Lock expiration time is now calculated from when the server determines that the user is offline.

    #### New features [#new-features-27]

    * **SDK connection state change reason**
      Added the [`RtmLinkStateChangeReason`](/en/api-reference/api-ref/signaling) enumeration to the `LinkStateEvent`, reporting the reason for connection state changes.

    * **IoT device domain whitelist**
      Added the `ispPolicyEnabled` field to [`RtmConfig`](/en/api-reference/api-ref/signaling). When set to `true`, the SDK connects only to servers in the domain or IP whitelist registered with carriers, helping IoT devices bypass ISP restrictions.

    * **16 KB memory page size support (Android)**
      Starting with Android 15, the system supports 16 KB memory page sizes. This version adds SDK support for 16 KB pages to ensure stability and performance across devices using 4 KB or 16 KB page sizes, improving compatibility and preventing crashes. See [support 16 KB page sizes](https://developer.android.com/guide/practices/page-sizes?hl=en).

    #### Improvements [#improvements-53]

    * Added token renewal timeout error code

      To provide feedback on token renewal operation results, this version added error code `renewTokenTimeout` (-10026).

    * Optimized presence event notification

      When channel data could not be synchronized, the SDK triggers a `Snapshot` event again. After receiving this event, users can update their app's local cache.

    * Other improvements

      * Improved login service duration.
      * Increased Signaling service recovery and reconnection speed after backgrounding or hibernation.
      * Optimized SDK performance under weak network conditions.
      * Optimized access node selection to speed up service connections.
      * Improved basic message service performance during service exceptions to avoid message unavailability.

    #### Issues fixed [#issues-fixed-21]

    * Token expiration notifications was triggered multiple times.
    * Point-to-point messages were delivered to the peer, but the sender received a timeout response.
    * On iOS, exiting the app sometimes caused Signaling SDK crashes
    * In private deployment scenarios, frequent network switching caused connection state exceptions.
    * In callback functions, if business code had uncaught exceptions, it caused SDK crashes.
    * When subscribing to topics, a "not joined channel" error was returned.
    * Occasionally during reconnection, subscription services were not restored.
    * When querying some channel users, results included information from abnormally offline users.
    * Incorrect token types caused abnormal errors.
    * Users received multiple offline notifications for the same offline user.
    * After the same UID logged in from different endpoints, connection state exceptions occurred.
    * Frequent Presence state updates caused data exceptions.
    * When specified services were not enabled, joining channels did not return errors.
    * In some scenarios, abnormal property values caused crash issues.

    ### v2.2.1 [#v221-6]

    v2.2.1 was released on October 15, 2024.

    This is the first release of the Signaling SDK v2.x for Flutter, which brings innovation in functional coverage, performance improvement, and experience optimization.

    * Functional coverage: v2.x covers more business use-cases by introducing functional modules such as channels, messages, topics, presence, storage, and locks. This enables you to focus more on your own business innovation.
    * Performance improvement: v2.x implements a restructured technical architecture and enhances performance through optimized network connections. Our long-term real-time network access capabilities ensure high service quality characterized by low latency, high reliability, extensive concurrency, and robust extensibility.
    * Experience optimization: v2.x redesigns and simplifies the API interface. We have also expanded our documentation, including user guides and API references, with extensive sample code to provide you with comprehensive developer resources. These improvements significantly reduce the effort required to understand and integrate the SDK, ultimately enhancing development efficiency.

    #### New features [#new-features-28]

    v2.2.1 provides the following core functional modules:

    1. **Initial configuration**

       The initial configuration of the Signaling client involves pre-defining or configuring key parameters that influence its subsequent behaviors. Additionally, it offers functions such as login and logout. The core features of the Signaling client are as follows:

       * `Future&lt;(RtmStatus, RtmClient)&gt; RTM(...)`: Create an instance of the Signaling client and configure it in the following way:
         * `appId`: Set the App ID to enable communication between apps with the same ID while isolating apps with different IDs.
         * `userId`: Set the user ID to distinguish users or devices.
         * `areaCode`: Set the area code for the geofencing feature.
         * `protocolType`: Set the protocol type for message transmission.
         * `presenceTimeout`: Set the delay imposed by the Signaling server before sending a `REMOTE_TIMEOUT` event notification to other users once it determines that a client has timed out.
         * `heartbeatInterval`: Set the time interval at which the client sends heartbeat packets to the Signaling server.
         * `useStringUserId`: Set the data type of the user ID, which can be of type `String` or `Int`.
         * `logConfig`: Configure the log file size, log file path, and output level.
         * `proxyConfig`: Configure whether to enable proxy.
         * `encryptionConfig`: Configure whether to enable encryption.
       * Event handling: Implement event notification for the events such as `onMessageEvent`, `onPresenceEvent`, `onTopicEvent`, `onStorageEvent` , `onLockEvent`, `onLinkStateEvent`, and `onTokenPrivilegeWillExpire`.
       * `login`: Log into the Signaling service.
       * `logout`: Log out of the Signaling service.
       * `release`: Destroy the Signaling client.

    2. **Channel**

       In the Signaling real-time network, channels serve as a mechanism for managing data transmission. When a user subscribes to or joins a channel, they can receive messages and events transmitted within the channel with a latency of up to 100 milliseconds. Signaling enables clients to subscribe to hundreds or even thousands of channels. Most Signaling APIs perform operations such as sending, receiving, and encrypting data on a channel basis.

       Signaling includes three types of channels, message channel, user channel, and stream channel, each offering distinct core capabilities as follows:

       * Message channel:
         * `subscribe`: Subscribe to the specified message channel and receive messages and event notifications in the channel.
         * `unsubscribe`: Unsubscribe from the specified message channel and stop receiving messages and event notifications in the channel.
       * User channel: Users can directly send messages to a specified user without subscribing to a channel. To receive messages, users only need to listen to the `message` event.
       * Stream channel:
         * `createStreamChannel`: Create a stream channel instance and then call relevant APIs.
         * `join`: Join the stream channel and receive messages and event notifications in the channel.
         * `leave`: Leave the stream channel and stop receiving messages and event notifications in the channel.
         * `release`: Destroy the stream channel.

       By calling different methods, the SDK triggers different event notifications.

       * The `subscribe`, `unsubscribe`, `join`, and `leave` methods trigger the `onPresenceEvent` event notification. Other users in the channel receive the corresponding `Join` and `Leave` event notifications.
       * When calling `subscribe` and `join` to subscribe or join a channel, you can choose whether to configure` withMessage`, `withPresence`, `withMetadata`, `withLock`, and other parameters to enable or disable the monitoring of the corresponding event. To enable the monitoring, you also need to register the corresponding event listener to receive corresponding event notifications.

    3. **Message**

       The basis of Signaling is the ability to send messages. You can send messages to channels anytime, anywhere, and the messages are delivered within 100 milliseconds. Signaling supports message payloads of both `String` and `Binary` type.

       Call `publish` to send a message to the specified message channel or user channel. Calling `publish` triggers the `onMessageEvent` event notification. If you want to receive messages in the channel, set `withMessage` to `true` when calling `subscribe` and register the event handler for the `onMessageEvent` event.

    4. **Topic**

       In stream channels, topics serve as a data flow management mechanism. This feature allows you to subscribe to, distribute, and notify events related to data streams within stream channels. By leveraging topics effectively, you can significantly reduce business complexity and enhance development efficiency. The main functions of topics are as follows:

       * `joinTopic`: Register as the publisher of this topic to gain the ability to send messages.
       * `publishTopicMessage`: Send a message to the topic in the stream channel.
       * `leaveTopic`: Unregister as the message publisher of this topic.
       * `subscribeTopic`: Subscribe to one or more message publishers of the topic in this channel.
       * `unsubscribeTopic`: Unsubscribe from this topic or unsubscribe from one or more message publishers in this topic.
       * `getSubscribedUserList`: Get the list of subscribed publishers in a specific topic.

       Register (`joinTopic`) and unregister (`leaveTopic`) as a message publisher trigger the `onTopicEvent` event notification that is sent to other users in the channel.

    <CalloutContainer type="warning">
      <CalloutTitle>
        caution
      </CalloutTitle>

      <CalloutDescription>
        Topics exist only in stream channels, not in message channels or user channels.
      </CalloutDescription>
    </CalloutContainer>

    1. **Presence**

       Presence provides the ability to monitor the online status and temporary status changes of users. With presence, you can obtain real-time information as follows:

       * Real-time event notification when a user joins or leaves a specified channel.
       * Real-time event notification when the custom temporary user state changes.
       * Query which channels a specified user has joined or subscribed to.
       * Query which users have joined a specified channel and their temporary user state data.

       The following features can be used in all kinds of channels:

       * `getOnlineUsers`: Get real-time information about the number of online users, the list of online users, and their temporary status in a specified channel.
       * `getUserChannels`: Get real-time information about the list of channels which a specific user joins.
       * `setState`: Set the temporary status of a user in a specified channel.
       * `getState`: Get the temporary status of a user in a specified channel.
       * `removeState`: Remove the temporary status of a user in a specific channel.

       In addition, presence also provides event notification capabilities through the `onPresenceEvent`. Events such as users joining, leaving, going offline, setting user state, and removing user state are sent as notifications to other users in the channel in real time (Announce Mode) or at regular intervals (Interval Mode). Presence greatly simplifies the implementation of the synchronization logic related to user online and offline status and state changes. This feature helps make your business more stable, real-time, and reliable.

    2. **Storage**

       The storage feature provides a dynamic database mechanism that allows developers to dynamically set, store, update, and delete channel metadata and user metadata. It also listens to the events generated by changes of channel metadata or user metadata.

       * Channel metadata:

         * `setChannelMetadata`: Set the channel metadata or metadata item for a specified channel.
         * `getChannelMetadata`: Get the channel metadata and metadata item for a specified channel.
         * `removeChannelMetadata`: Remove the channel metadata or metadata item for a specified channel.
         * `updateChannelMetadata`: Update the existing channel metadata or metadata item for a specified channel.

         Setting, deleting, and updating channel metadata trigger the `onStorageEvent` event notification. This feature can greatly optimize your business logic and provide an excellent user experience. Currently, the event notification `onStorageEvent` carries the complete information of the current channel metadata. It will be optimized in future versions to provide incremental update capabilities.

         Channel metadata also introduces the ability to control locks. When calling APIs to set, delete, or update channel metadata, if the `lockName` parameter is set, lock verification is enabled. In this case, only the owners of the lock can call the corresponding methods successfully.

       * User metadata

         * `setUserMetadata`: Set the user metadata or a metadata item for a specified user.
         * `getUserMetadata`: Get the user metadata or a metadata item for a specified user.
         * `removeUserMetadata`: Remove the user metadata or a metadata item for a specified user.
         * `updateUserMetadata`: Update the existing user metadata or a metadata item for a specified user.
         * `subscribeUserMetadata`: Subscribe to event notifications for changes in user metadata or a metadata item for a specified user.
         * `unsubscribeUserMetadata`: Unsubscribe from event notifications for changes in user metadata or a metadata item for a specified user.

         Setting, deleting, and updating user metadata trigger the `onStorageEvent` event notification. Other users subscribed to this user metadata receive the event notifications. This feature can greatly optimize your business logic and provide an excellent user experience. Currently, the `onStorageEvent` event notification carries the complete information of the current user metadata. It will be optimized in future versions to provide incremental update capabilities.

       * Compare And Set (CAS) control

         Both channel metadata and user metadata introduce the CAS version control logic, which provides two independent version control fields that you can use according to your business use-case:

         * Enable version number verification for the entire set of channel metadata by setting the `majorRevision` property.
         * Enable version number verification for a single metadata item by setting the `revision` property in the `MetadataItem` class.

         When setting, deleting, or updating channel metadata or user metadata, you can control whether to enable revision verification by using the `revision` property. The logic is as follows:

         * If `majorRevision` or `revision` is set to `-1`, the CAS validation is not enabled for this call. If the metadata or metadata item already exists, it is overwritten by the latest value. If the metadata or metadata item does not exist, a new metadata or metadata item is created.
         * If `majorRevision` or `revision` is set as a positive `int` integer, the CAS validation is enabled for this call. If the metadata or metadata item already exists, the value is updated after successful version number validation. If the metadata or metadata item does not exist, the SDK returns an error code.

    3. **Lock**

       A critical resource can only be used by one process at a time. If different processes share a critical resource, they need to adopt a mutually exclusive approach to prevent interference. Signaling offers a comprehensive set of lock solutions and process control in distributed systems, enabling you to effectively manage competition among users accessing shared resources. Lock provides the following capabilities:

       * `setLock`: Set a lock for a specified channel.
       * `acquireLock`: Acquire a specified lock in a specified channel.
       * `releaseLock`: Release a specified lock in a specified channel.
       * `revokeLock`: Revoke the ownership of a specific user for a lock in a specified channel to release the lock.
       * `getLocks`: Get the details of all locks in a specified channel.
       * `removeLock`: Remove a specified lock in a specified channel.

       The lock setting, acquisition, release, revocation, and deletion operations trigger the corresponding `onLockEvent` event notification. You can make full use of this feature to optimize the implementation logic of your business.

    
  
      
  
      
  
