Since updating to iOS 14.1 my iPhone has randomly showed a BLE device with RSSI of positive 19. A positive RSSI isn't possible, and I've never seen it before until iOS 14.1. I know 127 is a hardcoded values for "none" in the BLE reference. Does anyone know what 19 is or why my iPhone is reporting positive RSSI values?
Here is a list of random reading:
-74
-74
-73
-73
-71
19
-79
-80
-79
-80
-76
-76
-75
-74
So my BLE device regularly reports about -70 to -80, but then randomly 19.
=====
From looking through iOS sysdiagnose logs I see that bluetoothd logs a message of a new "rssi level is 19" before reporting to my app the RSSI:
Nov 4 17:36:24 bluetoothd[506] <Notice>: Applying RSSI offset of 0 to 27, new rssi level is 19
Nov 4 17:36:24 bluetoothd[506] <Notice>: Applying RSSI offset of 0 to -74, new rssi level is -74
Nov 4 17:36:24 bluetoothd[506] <Notice>: Matched UUID 6712B74E-8D81-465E-8E07-09C1923C11C6 for device "<private>"
Nov 4 17:36:24 bluetoothd[506] <Notice>: Matched UUID 6712B74E-8D81-465E-8E07-09C1923C11C6 for device "<private>"
Nov 4 17:36:24 MyApp(MyAppLibrary)[4380] <Notice>: [HomeViewController:801] Discovered 6712B74E-8D81-465E-8E07-09C1923C11C6 19
Nov 4 17:36:24 MyApp(MyAppLibrary)[4380] <Notice>: [HomeViewController:801] Discovered 6712B74E-8D81-465E-8E07-09C1923C11C6 -74
Related
Setup:
I'm running BlueZ 5.48 on an embedded Linux platform, with the Python example-gatt-server as a peripheral. I enable advertising with hciconfig hci0 leadv 0.
I am trying to connect using nRF Connect from an iPhone (iOS v12.1.4).
The devices are both on my desk, measuring about -40dBm RSSI, so signal levels should be good.
Issue(s):
I'm aware of several issues, and will list them in priority order (highest first).
a) In nRF Connect on the iPhone, I can see the device and connect, but after 30-60 seconds something causes a disconnect. It never asks me for permission to pair or enter a PIN.
b) In Linux, I see Bluetooth: SMP security requested but not available printed repeatedly as long as the iPhone is connected.
c) On the iPhone, I cannot see my peripheral device in the regular Bluetooth Devices list...ever. (This is a lesser issue...although I'd like to try pairing this way if possible.)
What I've tried:
1) I removed the TestService with secure / encrypted characteristics from the example-gatt-server Python code, so all that remain are Heartrate and Battery services. The iPhone nRF Connect app still disconnects after 30-60 seconds.
2) To determine the cause of disconnect, I looked at the journal for bluetooth.service in Linux:
Mar 15 18:44:57 sn0010 bluetoothd[775]: src/gatt-database.c:send_notification_to_device() GATT server sending notification
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/adapter.c:dev_disconnected() Device MAC_ADDR_HERE disconnected, reason 1
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/adapter.c:adapter_remove_connection()
Mar 15 18:44:58 sn0010 bluetoothd[775]: plugins/policy.c:disconnect_cb() reason 1
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr MAC_ADDR_HERE type 1 status 0xe
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/device.c:device_bonding_failed() status 14
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/adapter.c:resume_discovery()
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/device.c:att_disconnected_cb()
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/device.c:att_disconnected_cb() Connection timed out (110)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/service.c:change_state() 0x20d080: device MAC_ADDR_HERE profile batt-profile state changed: connected -> disconnecting (0)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/service.c:change_state() 0x20d080: device MAC_ADDR_HERE profile batt-profile state changed: disconnecting -> disconnected (0)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/service.c:change_state() 0x20d638: device MAC_ADDR_HERE profile deviceinfo state changed: connected -> disconnecting (0)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/service.c:change_state() 0x20d638: device MAC_ADDR_HERE profile deviceinfo state changed: disconnecting -> disconnected (0)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/service.c:change_state() 0x20ca00: device MAC_ADDR_HERE profile gap-profile state changed: connected -> disconnecting (0)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/service.c:change_state() 0x20ca00: device MAC_ADDR_HERE profile gap-profile state changed: disconnecting -> disconnected (0)
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/gatt-client.c:btd_gatt_client_disconnected() Device disconnected. Cleaning up.
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/device.c:att_disconnected_cb() Automatic connection disabled
Mar 15 18:44:58 sn0010 bluetoothd[775]: attrib/gattrib.c:g_attrib_unref() 0x21e968: g_attrib_unref=0
Mar 15 18:44:58 sn0010 bluetoothd[775]: src/gatt-database.c:att_disconnected()
This seems to say a timeout occurred (reason 1).
3) I altered the default conn_min_interval=24, conn_max_interval=40, supervision_timeout=42 values in Linux sysfs to match the Apple compatibility guidelines. (Values were changed to 12, 24, and 200 explicitly.) Rebooting and restarting Bluetooth with this didn't make any difference.
4) I tried issuing btmgmt bredr off and btmgmt bondable off before hciconfig hci0 leadv 0, but no change.
5) I ran nRF Sniffer but it didn't seem to capture disconnect events. I can tell my peripheral is advertising by filtering on its BD addr as shown below:
6) I disabled the example-gatt-server altogether. nRF Connect is still able to connect, but disconnects after 30-60 seconds again. This seems to isolate the issue within the iOS app, the BlueZ stack, or lower Linux driver layers/configuration.
7) Connecting using nRF Connect for Android works fine and maintains a steady connection as long as I wish.
Question
Does anyone have advice for what to try next?
EDIT 1:
Per comment, I have run btmon on the Linux host while the iPhone is connected. I enabled notify for Heartrate characteristic on the iPhone. The log shows a disconnect due to timeout.
< ACL Data TX: Handle 128 flags 0x00 dlen 7 #4792 [hci0] 105.414362
ATT: Read Request (0x0a) len 2
Handle: 0x0016
> ACL Data RX: Handle 128 flags 0x02 dlen 9 #4793 [hci0] 105.466957
ATT: Error Response (0x01) len 4
Read Request (0x0a)
Handle: 0x0016
Error: Insufficient Authentication (0x05)
> HCI Event: Number of Completed Packets (0x13) plen 5 #4794 [hci0] 105.467019
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 7 #4795 [hci0] 105.474721
ATT: Read Request (0x0a) len 2
Handle: 0x0016
< ACL Data TX: Handle 128 flags 0x00 dlen 11 #4796 [hci0] 105.564168
ATT: Handle Value Notification (0x1b) len 6
Handle: 0x000c
Data: 0e7d6400
< ACL Data TX: Handle 128 flags 0x00 dlen 9 #4797 [hci0] 106.558967
ATT: Handle Value Notification (0x1b) len 4
Handle: 0x000c
Data: 0665
> HCI Event: Number of Completed Packets (0x13) plen 5 #4798 [hci0] 106.877481
Num handles: 1
Handle: 128
Count: 3
> HCI Event: Disconnect Complete (0x05) plen 4 #4799 [hci0] 106.877698
Status: Success (0x00)
Handle: 128
Reason: Connection Timeout (0x08)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 106.877764
LE Address: 71:68:0B:72:0F:E9 (Resolvable)
Reason: Connection timeout (0x01)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 106.877764
LE Address: 71:68:0B:72:0F:E9 (Resolvable)
Reason: Connection timeout (0x01)
I believe my issue is solved by using values in accordance with the Apple design guidelines. I edited and rebuilt the kernel so default Bluetooth params are as follows:
$ cat /sys/kernel/debug/bluetooth/hci0/conn_min_interval
12
$ cat /sys/kernel/debug/bluetooth/hci0/conn_max_interval
12
$ cat /sys/kernel/debug/bluetooth/hci0/supervision_timeout
500
This appears to maintain a BLE connection between Linux and the iPhone for as long as I wish.
Note: In attempting to edit these parameters via sysfs before, I believe the settings were lost upon reboot...or otherwise did not get applied like I thought. I had also used slightly different values (conn_max_interval = 24 vs 12 now).
I notice your btmon logs have:
Error: Insufficient Authentication (0x05)
As per Bluez: pairing issue with iOS. Presumably this is still the case after you fix with the new params?
(BTW iOS only shows BREDR enabled devices that are discoverable or previously paired in the OS Devices list)
I've been somewhat concerned at the number of R14 errors I'm getting on Heroku recently.
I don't know if this has anything to do with using Unicorn. Or having recently installed New Relic or Logentries. I really can't work it out.
I have "installed" Oink and have just received the following analysis but have no read idea how to fully understand what it's trying to tell me.
---- MEMORY THRESHOLD ----
THRESHOLD: 0 MB
-- SUMMARY --
Worst Requests:
1. Nov 13 02:53:51, 70836 KB, messages#getmessagecount
2. Nov 13 02:03:04, 65836 KB, messages#getmessagecount
3. Nov 13 02:21:46, 60236 KB, messages#getmessagecount
4. Nov 13 01:32:47, 6328 KB, messages#deletemessage
5. Nov 13 01:33:43, 6328 KB, locations#sendprofiles
6. Nov 13 01:32:56, 6328 KB, messages#deletemessage
7. Nov 13 01:32:58, 6328 KB, messages#deletemessage
8. Nov 13 01:32:49, 6328 KB, messages#deletemessage
9. Nov 13 01:47:46, 5300 KB, messages#getmessagecount
10. Nov 13 03:09:56, 5300 KB, messages#getmessagecount
Worst Actions:
9, messages#deletemessage
7, messages#getmessagecount
1, locations#sendprofiles
1, photos#photodatarequest
1, messages#getmessages
Aggregated Totals:
Action Max Mean Min Total Number of requests
messages#getmessagecount 70836 29814 464 208700 7
messages#deletemessage 6328 3016 180 27144 9
locations#sendprofiles 6328 6328 6328 6328 1
photos#photodatarequest 460 460 460 460 1
messages#getmessages 300 300 300 300 1
I'm concerned, as a layman, that my message#getmessagecount is eating a LOT of memory. Is that what the above means?
If so ... the routine is simply:
def getmessagecount
#messagecount = Message.where(recipient: current_user, messageSysMessCode: 0, messageAdminMessage: false).count
end
And I have no idea how this could be "leaking" memory.
The graph of memory usage on Heroku over the last day looks like:
I'm using Ruby 2.1.4 and Rails 4.1.7 if that's any help. I'm using two Web dynos and one Worker.
Oh ... and my delete message routine is:
def deletemessage
#message = Message.where(recipient_id: current_user.id, id: params[:messageID]).first
if (#message)
#message.delete
#code = "OK"
else
#code = "Couldn't delete message"
end
end
This is killing my performance (if that's the right thing to say) every 3 hours or so. I have no idea why this is ramping up every 10 minutes (which I hopefully infer from reading the graph). 10 minutes might be significant as I have an iPhone app which is polling the getmessagecount routine every 10 mins with a single test app. I can only wonder what will happen if 10 copies of the app (or 1,000's) start hitting the server?
Any help would be very deeply appreciated.
I am facing a strange issue in MobileVLCKit for iOS.I am playing RTSP links in my app. I have set the flag to play audio and video in background to true in my app. So when the app goes in background the video playing in my VLC player keeps playing without any problem.
But on iPhone 4 (with iOS 7.0.4) when I lock the screen of my iPhone when the video is playing, the app crashes without showing any logs. Strange thing is that if I send the app in background by pressing home button then the app doesn't crash. The issue is only on iPhone 4 and not on iPhone 5.
Have somebody come across such issue before?
Bellow is device crash log:
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: 019323.846533 wlan.A[400] AppleBCMWLANNetManager::updateLinkQualityMetrics(): Report LQM to User Land 100, fAverageRSSI -69
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: ALS: AppleARMBacklight::setBacklightEnableGated 0 (set level to 0x1c8)
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: AppleMultitouchN1SPI: updating power statistics
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: ALS: AppleARMBacklight::handleMessageGated - framebufferState -> 0
May 27 03:18:41 My-iPhone-VI backboardd[28] <Notice>: Posting 'com.apple.iokit.hid.displayStatus' notifyState=0
May 27 03:18:41 My-iPhone-VI SpringBoard[34] <Warning>: [MPUNowPlayingController] Not registered for now playing notifications. Ignoring call to -unregisterForNotifications.
May 27 03:18:41 My-iPhone-VI backboardd[28] <Notice>: MultitouchHID: detection mode: 0->255
May 27 03:18:41 My-iPhone-VI MyApp[817] <Warning>: log: applicationWillResignActive
May 27 03:18:41 My-iPhone-VI MyApp[817] <Warning>: log: applicationDidEnterBackground
May 27 03:18:42 My-iPhone-VI profiled[818] <Notice>: (Note ) profiled: Service starting...
May 27 03:18:42 My-iPhone-VI ReportCrash[819] <Notice>: ReportCrash acting against PID 817
May 27 03:18:43 My-iPhone-VI ReportCrash[819] <Notice>: Formulating crash report for process MyApp[817]
May 27 03:18:43 My-iPhone-VI com.apple.launchd[1] (UIKitApplication:com.My.MyApp[0x19d8][817]) <Warning>: (UIKitApplication:com.My.MyApp[0x19d8]) Job appears to have crashed: Segmentation fault: 11
May 27 03:18:43 My-iPhone-VI backboardd[28] <Warning>: Application 'UIKitApplication:com.My.MyApp[0x19d8]' exited abnormally with signal 11: Segmentation fault: 11
May 27 03:18:43 My-iPhone-VI mediaserverd[46] <Warning>: Encountered an XPC error while communicating with backboardd: <error: 0x3cd9f744> { count = 1, contents =
"XPCErrorDescription" => <string: 0x3cd9f9dc> { length = 22, contents = "Connection interrupted" }
}
May 27 03:18:43 My-iPhone-VI ReportCrash[819] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/MyApp_2014-05-27-031842_My-iPhone-VI.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
May 27 03:18:53 My-iPhone-VI profiled[818] <Notice>: (Note ) profiled: Service stopping.
Below is the stack trace taken in method didEnterBackground:
Stack trace : (
0 MyApp 0x0010a191 -[MyAppAppDelegate applicationDidEnterBackground:] + 76
1 UIKit 0x2fc85543 <redacted> + 590
2 UIKit 0x2fc06ae1 <redacted> + 764
3 UIKit 0x2fc06721 <redacted> + 72
4 UIKit 0x2fc6bb3d <redacted> + 664
5 GraphicsServices 0x320a270d <redacted> + 608
6 GraphicsServices 0x320a22f7 <redacted> + 34
7 CoreFoundation 0x2d4599df <redacted> + 34
8 CoreFoundation 0x2d45997b <redacted> + 346
9 CoreFoundation 0x2d45814f <redacted> + 1398
10 CoreFoundation 0x2d3c2c27 CFRunLoopRunSpecific + 522
11 CoreFoundation 0x2d3c2a0b CFRunLoopRunInMode + 106
12 GraphicsServices 0x320a1283 GSEventRunModal + 138
13 UIKit 0x2fc66049 UIApplicationMain + 1136
14 MyApp 0x001078e9 main + 116
15 libdyld.dylib 0x37d26ab7 <redacted> + 2
)
You need to disable video decoding prior to entering the background state. Otherwise, MobileVLCKit will try to draw OpenGL contents in the background which will be prevented by the OS by terminating the app.
You can disable video decoding by setting the current video track on your media player instance to -1. Once your app is moved to the foreground again, switch it back to the currently decoded video track (so you should cache it if your stream includes more than one video track).
When disabling video decoding, audio decoding is not affected and will continue just fine. This approach also got the benefit of saving CPU load and battery.. ;)
This is how VLC for iOS works, too. :)
i think You need to disable video decoding prior to entering the background state,this will work for sure this is major thing Apple says that a fix for the home screen crashes is coming also you can read here more How to take a screenshot on iphone without using lock button
I am writing an IOS app. It involves a lot of data downloading which involves images and text in JSON format. I am using NSOperation Queue to make the download process sequential. The entire app works fine in iPhone4 and iPhone4s but in iPhone 5 the app crashes while inserting data in to the database. I have an API call which returns about 350 items back. WHile inserting these records to database the app crashes.
I am not getting any crash logs while debugging. The app simply quits. But from device logs within the Organizer it shows Memory warning. MyApp is the name of my application.
Dec 3 17:14:21 Gavs-iPhone MyApp[6673] <Warning>: Inserted Reward
Dec 3 17:14:21 Gavs-iPhone MobileMail[6648] <Warning>: Received memory warning.
Dec 3 17:14:22 Gavs-iPhone MyApp[6673] <Warning>: Inserted Reward
Dec 3 17:14:22 Gavs-iPhone UserEventAgent[14] <Notice>: jetsam: kernel termination snapshot being created
Within device Console I can see this
Processes
Name <UUID> rpages recent_max fds [reason] (state)
keybagd <03955fb37478382481fc34df706700a1> 233 233 100 [vm-pageshortage] (daemon) (idle)
wirelessproxd <b5a0169c073b3fa7a2e63079774626bc> 97 97 100 [vm-pageshortage] (daemon) (idle)
MobileMail <759a544834f73ebfb26a73e4c16a71d6> 987 987 100 [vm-pageshortage] (resume) (continuous)
tccd <96df95e7143c3cdba0e4ce226d849f14> 148 148 100 [vm-pageshortage] (daemon)
MyApp <aa954e20bdf13ecf9fa250862caf480e> 6296 7314 100 [vm-pageshortage] (frontmost) (resume)
What confuses me is this happens only on iPhone5. All devices runs on IOS 7.0.4 .
Is iPhone 5 allocating lesser memory compared to previous models? To add NSZoombies is not enabled.
Whats going wrong here?
Thanks
I am trying to write a code which will handle turning on/off screen on iOS (You can take a look at this question where similar problem is discussed). I included OSX tag for this question, because OSX has the same system wide notification facility. And the problem described below is inherit to the notifications facility (vs to iOS or OSX).
There is well known method of registering for system wide notification com.apple.springboard.hasBlankedScreen to receive notifications when the screen is turned off or on.
Just for references (here are the API which are used for registering for system wide notifications):
notify_post, notify_check_ notify_get_state and friends
CFNotificationCenterPostNotification, CFNotificationCenterAddObserver and friends (which uses notify_post and etc internally)
However, there are two interrelated problems with this approach:
Notifications for both screen turning off and on come with the same name (com.apple.springboard.hasBlankedScreen)
Observer doesn't receive a state as part of the notification.
So, as result we need to implement some solution which will differ screen turning on and off (since the same notification callback will be called and none of parameters will have a state).
Generally speaking, the core problem that the state is decoupled from notification callback. I don't see how to handle this gracefully.
I come up with two straightforward approaches (each of them are flawed). And looking for ideas of another approaches or improvements over this approach.
Counting solution
We can implement a counter which counts how many notification we already received and based on this information we will know whether it's notification for turning screen on or off (based on oddity of our counter).
However, it has two downsides:
1) In the case, if the system (for unknown in design time reason) will send additional notifications with the same name, our logic will be screwed, because it will break oddity check.
2) Also, we need to set initial state correctly. So somewhere in the code we will have something like that:
counter = getInitialState();
registerForNotification();
In this case we have one race condition. If system will send notification and change the state after we did getInitialState(), but before registerForNotification() we will end up with wrong counter value.
If we will do following code:
registerForNotification();
counter = getInitialState();
In this case we have another race condition. If system will send notification and change the state after we did registerForNotification(), but before getInitialState(), we will get a counter, will enter notification callback and will increase a counter (which will make it wrong).
Determining state when notification received solution
In this case, we don't store any counter, but rather use API notify_get_state in notification callback to get current state.
This has it's own problem:
1) Notification delivered to the application asynchronously. So, as result if you turn off and on screen really fast, you can receive both notifications when the screen was already on. So, notify_check will get a current state (vs the state at the moment when notification was send).
As result, when the application will use notify_get_state in notification callback it will determine that there was two notification "screen was turned on", instead of one notification "screen was turned off" and another "screen was turned on".
P.S. Generally speaking, all described problems aren't specific to screen on/off case. They are actual for any system wide notifications which has distinctive states and send with the same notification name.
Update 1
I didn't test exactly scenario with turning screen on/off very fast and getting the same results from notify_get_state().
However, I have kind-of similar scenario when I received two notifications com.apple.springboard.lockstate (subscribed through CFNotificationCenterAddObserver) and I used another API to get a current device locked status and received the same values for both notifications.
So it's only my assumption that notify_get_state would return same values too. However, I think it's educated guess. The input parameter for notify_get_state will be the same for two calls (it doesn't change). And I don't think that system stores FIFO queue of states which should be returned by notify_get_state.
So, I built a very simple experiment. I ran this on a jailbroken iOS 6.1 iPhone 5, outside the debugger.
Code
I built a consumer app, with the following code:
#define EVENT "com.mycompany.bs"
- (void)registerForNotifications {
int result = notify_register_dispatch(EVENT,
¬ifyToken,
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0l),
^(int info) {
uint64_t state;
notify_get_state(notifyToken, &state);
NSLog(#"notify_register_dispatch() : %d", (int)state);
});
if (result != NOTIFY_STATUS_OK) {
NSLog(#"register failure = %d", result);
}
CFNotificationCenterAddObserver(CFNotificationCenterGetDarwinNotifyCenter(), //center
NULL, // observer
notifyCallback, // callback
CFSTR(EVENT), // event name
NULL, // object
CFNotificationSuspensionBehaviorDeliverImmediately);
}
static void notifyCallback(CFNotificationCenterRef center, void *observer, CFStringRef name, const void *object, CFDictionaryRef userInfo) {
uint64_t state;
notify_get_state(notifyToken, &state);
NSLog(#"notifyCallback(): %d", (int)state);
}
So, as you see, it uses two different methods to register for the same custom event. I startup this app, let it register for the event, then put it into the background (home button press).
Then, the producer app, which lets me generate the event with a button press:
double delayInSeconds = 0.001;
dispatch_queue_t q = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0l);
dispatch_async(q, ^(void) {
notify_set_state(notifyToken, 2);
notify_post(EVENT);
});
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));
dispatch_after(popTime, q, ^(void){
notify_set_state(notifyToken, 3);
notify_post(EVENT);
});
Results
I then ran the producer app, manually generating a pair of events about every two seconds. As you can see, the producer quickly posts the event with a state of 2, and then immediately posts another event with a state of 3. So, the consumer should print out 2 then 3, for both callback methods, if this is working perfectly. It does not (as you feared):
Feb 13 21:46:12 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:12 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:12 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:12 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:18 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:18 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:18 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:18 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:22 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:22 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:22 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:22 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:26 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 2
Feb 13 21:46:26 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:26 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:26 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:30 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:30 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:30 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:30 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:33 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:33 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:33 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:33 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
Feb 13 21:46:36 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 2
Feb 13 21:46:36 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:36 iPhone5 MyApp[1971] <Warning>: notify_register_dispatch() : 3
Feb 13 21:46:36 iPhone5 MyApp[1971] <Warning>: notifyCallback(): 3
I tried changing one consumer registration method to use CFNotificationSuspensionBehaviorCoalesce (instead of delivering immediately). Results:
Feb 13 21:48:17 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:17 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:17 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:17 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:20 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:20 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:20 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:20 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:24 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:24 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 2
Feb 13 21:48:24 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:24 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:29 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:29 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:29 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:29 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:32 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:32 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 2
Feb 13 21:48:32 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:32 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:35 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:35 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 2
Feb 13 21:48:35 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:35 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:38 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:38 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 2
Feb 13 21:48:38 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:38 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
Feb 13 21:48:39 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 2
Feb 13 21:48:39 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:39 iPhone5 MyApp[1990] <Warning>: notify_register_dispatch() : 3
Feb 13 21:48:39 iPhone5 MyApp[1990] <Warning>: notifyCallback(): 3
I then tried changing the queue priority of the notify_register_dispatch() consumer to high, instead of background priority. Results:
Feb 13 21:49:51 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:49:51 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:49:51 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:49:51 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:49:53 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:49:53 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 2
Feb 13 21:49:53 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:49:53 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:49:55 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:49:55 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 2
Feb 13 21:49:55 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:49:55 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:49:59 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:49:59 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 2
Feb 13 21:49:59 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:49:59 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:50:01 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:50:01 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:01 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:01 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:50:04 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 2
Feb 13 21:50:04 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:50:04 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:04 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:50:06 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:50:06 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 2
Feb 13 21:50:06 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:06 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:50:09 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:50:09 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 2
Feb 13 21:50:09 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:09 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Feb 13 21:50:10 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 2
Feb 13 21:50:10 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:10 iPhone5 MyApp[2006] <Warning>: notify_register_dispatch() : 3
Feb 13 21:50:10 iPhone5 MyApp[2006] <Warning>: notifyCallback(): 3
Conclusions (?)
There is a problem as you suspected, and it's not just with the SBGetScreenLockStatus call. Sometimes, the consumer never saw the state set to 2.
If I increased the producer time delay to 5 msec, I never saw the problem. So, this may only be an issue for events really close in time. Screen lock / unlock probably isn't a big deal. Obviously, slower phones (iPhone < 5) will respond differently.
The static notifyCallback() method seemed to get called back first, unless the GCD callback block was put on the high priority queue. Even then, usually the static callback function was called first. Many times, the first method called back got the correct state (2), while the second one did not. So, if you have to live with the problem, you might choose the callback mechanism that seemed to perform best (or at least, prototype this yourself, inside your app).
I can't say that the suspensionBehavior parameter made much difference. That said, depending on how iOS is posting the events, they may be using a call like CFNotificationCenterPostNotification that may ignore the consumers' behavior request.
If you look at this Apple document, you'll see two things.
First, notify_set_state was not part of the very original API
Second, the very first paragraph in that document says
Darwin Notification API Reference
These routines allow processes to exchange stateless notification
events.
So, maybe we're just trying to do something that's not consistent with the original design :(
If you also look at Apple's NotificationPoster example, you see that they don't use notify_get_state and notify_set_state to convey state. They pass it with the notification as a user info dictionary. Obviously, if you're observing Apple's iOS events, you have no control over how the events are posted. But, in apps where you get to create the producer and consumer, I'd stay away from notify_set_state.