This article introduces a demo project about Apple Notification Center Service (ANCS). The demo project is able to receive ANCS notifications like phone calls, calendar events, etc.
The information below can be found on the Apple specification linked below, but for the convenience we summarize it here.
The purpose of the Apple Notification Center Service (ANCS) is to give Bluetooth accessories (that connect to iOS devices through a Bluetooth Low Energy link) a simple and convenient way to access many kinds of notifications that are generated on iOS devices.
The Apple Notification Center Service is referred to as the ANCS.
The publisher of the ANCS service (the iOS device) is referred to as Notification Provider (NP).
Any client of the ANCS service (an accessory) is referred to as a Notification Consumer (NC).
A notification displayed on an iOS device in the iOS Notification Center is referred to as iOS notification.
A notification sent by a GATT characteristic as an asynchronous message is referred to as a GATT notification.
In its basic form, the ANCS exposes three characteristics:
Notification Source: UUID: 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)
Control Point: UUID: 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writable with response)
Data Source: UUID: 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)
All these characteristics require authorization for access.
Support for the Notification Source characteristic is mandatory, whereas support for the Control Point characteristic and Data Source characteristic is optional.
Note: In this demo project we use the Notification Source characteristic only .
A GATT notification delivered through the Notification Source characteristic contains the following information:
EventID: This field informs the accessory whether the given iOS notification was added, modified, or removed. The enumerated values for this field are defined in EventID Values.
EventFlags: A bitmask whose set bits inform an NC of specificities with the iOS notification. For example, if an iOS notification is considered “important”, the NC may want to display a more aggressive user interface (UI) to make sure the user is properly alerted. The enumerated bits for this field are defined in EventFlags.
CategoryID: A numerical value providing a category in which the iOS notification can be classified. The NP will make a best effort to provide an accurate category for each iOS notification. The enumerated values for this field are defined in CategoryID Values.
CategoryCount: The current number of active iOS notifications in the given category. For example, if two unread emails are sitting in a user’s email inbox, and a new email is pushed to the user’s iOS device, the value of CategoryCount is 3.
NotificationUID: A 32-bit numerical value that is the unique identifier (UID) for the iOS notification. This value can be used as a handle in commands sent to the Control Point characteristic to interact with the iOS notification.
For more information about ANCS, please check specification linked below.
The demo project is able to receive ANCS notifications like phone calls, calendar events, etc. and prints them out to the VCOM. The software flow goes as follows:
At first the software initialize the peripherals, the Bluetooth stack and logging to the virtual COM port.
After the gecko_evt_system_boot_id event arrived it sets up the security manager in order to able to bond with iOS device. Then it starts advertising.
Once gecko_evt_gatt_mtu_exchanged_id event received the device connected and the connection parameters negotiated. Then the device starts to search for the ANCS service in the remote GATT with the gecko_cmd_gatt_discover_primary_services_by_uuidAPI.
If it finds the ANCS service, it will start searching for the notification source characteristic in the remote GATT with the gecko_cmd_gatt_discover_characteristics_by_uuid API.
If the notification source characteristic is found in the remote GATT, the device tries to subscribe to characteristic notification with the gecko_cmd_gatt_set_characteristic_notification API. If the iOS device and the BGM module are not bonded, it is not possible. First the pairing and bonding process have to be completed. Once the bonding is completed, we have to enable the characteristic notification again. This time it will work.
Receiving a gecko_evt_gatt_characteristic_value_id event with the att_opcode == gatt_handle_value_notification means the we got a GATT notification from the remote device. In this case, we determine the notification type based on the notification UID and print it out with the ancCharValueReceivedCallback function.
The activity diagram below shows the described flow.
Get an iOS device and switch on the Bluetooth in it. Enable application notifications.
Create a new SoC-Empty project for your device (tested with EFR32BG13) in Simplicity Studio.
Copy the attached files into the project:
Change the "Device Name" characteristic value to "ANCS Example" to better recognize the device in Bluetooth browsers.
Change DEBUG_LEVEL to 1 in app.h.
Build and flash the project to your device.
Start a terminal like TeraTerm and open the virtual COM port of the J-Link CDC device.
Connect to the BG13 "ANCS Example" with a Bluetooth browser app like the Blue Gecko and accept the pairing request.
Now you should get ANCS notifications like below when you get email, for example.