-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DRAFT] Apple Notification Center Service Implementation #1
base: develop
Are you sure you want to change the base?
Conversation
At this time, i have not test the current implementation against the watch. I'm waiting for the missing part that will allow me to connect it to my PC. Works was made based on the existing AlertNotificationService |
I saw that you mapped the notification categories from Apple to the ones from InfiniTime. Since Infinitime only checks for IncomingCall and ignores the rest by now, I think we can just add the categories from Apple. |
if we left the mapping in place, when other types of notification will be available, this will be handle automatically no? Is it to save some storage size that you want to remove this mapping? I'm not a expert in embedded dev. I mostly work with java and JS. |
I am also new to embedded C++ and mostly use Rust and Python. No, the mapping is fine. I was just wondering if we should add the missing categories from Apple to NotificationManager.h |
OK. i think, this could be in another PR. The priority is to implement the notification . this will be more easily for the reviewer if with stay with the bare minimal. |
Little things to note :
|
This seems a little weird to me, since the Apple docs say:
and
Am I missing something?
I will look into that. Maybe we can keep the standard notification service :) |
Ok my bad. I have invert the hierarchy of service and characteristics. I will revert the change. |
Dont worry, we are both new to this and learning, I guess 😄 |
Do you think ControlPoint characteristic need to be defined in our side ? Per Apple docs This seems to be the role of the watch to contact iphone by writing on the characteristic. This doesn't make sens to me to add callback for this characteristic |
I am not sure if we need some kind of definition our side to write to it. If not, we don't need it. |
Regarding the service, I think we need a flag on notifications to mark if they are normal or from Apple and some kind of intermediate that handles them with the correct service-backend. |
If you have an hint on how to configure Clion for this project, i will take it :) . |
No, I am sorry 😐 All I know is the |
The last commit makes everything compile with docker, but be aware of this unmerged PR. Also: There is an AlertNotificationClient and I guess that this is what we should copy for the control point characteristic. |
I compile with native Cmake so no problem for me. I will take a look at AlertNotificationClient |
This issue and apple indicate that ANCS needs secure bonding/pairing. That can be obtained by forcing encryption on the ANCS. If we get this to work, then we should hopefully be able to get simple dummy notifications on the watch. |
How do you flash it to the phone? Using OTA with compagnion app? I think the AlertNotificationClient is use when we want to send notification from the watch to the phone. If i'm rigth there is no need to handle it at this time |
I flash |
i think you can do it via OTA by installing infinilink compagnon app |
I tested yesterday to generate "Hello World" notifications on the watch whenever any incoming notification is detected. That did not work. |
of course you can :) I just push an update for the flag on characteristic to enable secure connection. For this I have found the PR that has make it work in the past. Maybe you can try with this. |
Yes. We need this check this and find a way to replace current alert implementation by ours when connected to apple device |
I tried to add the ANCS next to the ANS. Do they interfere somehow? |
we need to test. data received are not the same |
They have different UUIDs, so I do not suspect a problem. |
Yeah you are right. We will have hard time to test this is we need a secure connection that is not available for the Infinilink App. Maybe we need to make another PR to address this issue first ? |
Hi, its been some time. I am currently working on my thesis and do not habe much time. Here are my current thoughts: We separately need to implement the GenericAttribute Service (0x1801) and its ServiceChanged characteristic. I also never got to the point where the watch paired with my iPhone. |
Is anyone working on it? Can I finish this? |
No, not right now. Feel free 😊 |
|
||
int AppleNotificationCenterClient::OnDescriptorDiscoveryEventCallback(uint16_t connectionHandle, const ble_gatt_error* error, uint16_t characteristicValueHandle, const ble_gatt_dsc* descriptor) { | ||
if (error->status == 0) { | ||
if (characteristicValueHandle == notificationSourceHandle && ble_uuid_cmp(¬ificationSourceChar.u, &descriptor->uuid.u)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does the last comparison needed?
This callback is called only for notificationSourceChar's descriptors, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to recall this. This handles the notification subscription, right? Then we also want this for the dataSourceChar as well, but this code as it is just tries to detect an incoming message and then to show a dummy "Hello World" Notification. So this should stay in, because later on, there will be another case.
Seems like the watch does not advertise itself properly causing the service discovery to return unlikely error, I'll keep investigating next mont how to properly setup the watch so it will be discoverable by the IOS device |
@AsafFisher anything I can do to help? I’m a backend web dev mostly but I dabble. :-) My pebble stopped working and I don’t want to buy an Apple Watch. Notifications are the only thing stopping me from using PineTime full time. |
You could take a look at the GATT Service and its service changed characteristic. |
I understand that the BLE pairing is not encrypted, am I right? |
I don't know. Maybe you should ask this in the InfiniTime repo. |
👍 I’ve never worked with BLE but I don’t mind giving this a try, with the caveat that someone with more experience can feel free to beat me to a solution. :-) I’ll get the project running today and tomorrow in my free time and dig around some over the weekend. Y’all got a discord or IRC? |
Doesn't |
There is an Element group chat, me and some others are active there. |
There are services which have characteristics (that hold the values) which have descriptors that you mostly only need to subscribe to a characteristic. I far as I understand it, the Gatt service has a ServiceChanged characteristic that gives you a range of affected handles (kind of like a reference of the service on your device) for services that changed. You can compare this to the handle attributes of the ANCS class and invoke a reaction such as en-/disabling ANCS. |
Funny that you say that, I tried it yesterday (: |
Any updates? |
I’m still interested in helping out with this but I was knocked over by COVID the weekend after my comment. I’m playing catch-up at normal life things and still pretty tired. Sorry I didn’t say anything sooner! |
Hello everyone, are there any recent updates on things tried to push these topics any further? I'm willing to contribute some time on the pinetime FW front for integration of the ANCS as well as GATT handling. Also further links to specifications, especially SW architecture descriptions are highly appreciated. |
Nothing new, sadly. You can find most information here or in the issues and pull requests regarding iOS on the InfiniTime repo. Main problem: the services Apple devices expose can (and will) appear and disappear. InfiniTime can't handle this right now. But feel free, I think some of the code here is useful 😊 Would be nice if someone gets it running. |
So in general we would need some kind of internal state machine to keep track of, are we paired with an apple device and if so another state machine to keep track of services the paired device once provided as they might reoccur anytime... and which are availlable right now. Or am I following a misconception here that simply keeping track of what has been there is not enough to ensure proper handling as soon as the service reoccurs on the Apple Device side? Also I think actual changes should be done on the main repo, or would it make sense to rebase this fork to the current main repo state to ensure everything is working well together on the latest version availlable? |
Tbh, I think this fork here is dead. The behavior is normal BLE and the documentation says that there is a service where the changes regarding availability of other services are published. Apple are just using it all, instead of the others. Have you found the other discussions over at the original repo? I believe that I answered some questions there before. Edit: for example this one. |
I already downloaded the Accessory design guideline from Apple there they are exactly describing which services are used on iOS side and by which services from BLE they're made accessible. They also specify which version of the Bluetooth Core documentation were used as basis for their expectation regarding connection establishing... (Actually wondering if there is everything necessary implemented or used properly by the RTOS)Regarding this Fork, yeah it's quite outdated by now, even though some of the attempts from here might be helpful for review of potential solutions. So I'll move over to the regarding issue on the main repo, thanks so far.
|
I think this part can be changed in InfiniLink app |
No, ANCS is not provided by an app. It comes from iOS itself. |
This PR enable support of Apple Notification Center Service. The current state of this PR is as follow :