On iOS 18.x when try to create EASession we get nil, but on iOS 17.x everything works.
We have app which use USB cable for connecting external accessories. Scenario is when we have fresh instal, connecting with accessory work fine, EASession is created, streams are opened. When we unplug USB, we close streams, remove any reference to session and accessory, remove accessory delegate. When plug it again, creating EASession is returning nil. Only after restarting iPhone, we can create new EASession with appropriate protocol and accessory. Every next attempt without reseting iPhone is failing.
Logs from accessory is following:
00:05:51.811000 : onUSBDeviceFound(pDevice=0xffc818)) iPhone USB device already in the device list w/id=1 -> update status now[21;1H
00:05:51.830000 : setConnectionStatus(status=connected) [devId=1] state updated -> forward[21;1H
Capabilities indicate HostMode possibility => role switch is triggered
00:05:52.848000 : updateDIPODeviceConnections() iPhoneUSB w/caps=5 (=CarPlay or HostMode), deviceTag=2 in Device mode -> request role switch[21;1H
Role switch seems to be successful
00:05:54.914000 : setSwitching('stable') changed[21;1H
00:05:54.915000 : updateDIPODeviceConnections() iPhoneUSB w/caps=2, id=1, deviceTag=2 and native transport -> request app launch and call connectUSB[21;1H
00:05:54.967000 : ConnectiAP2(05ac:12a8, s/n='00008101000160921E90801E', writeFD='/dev/ffs/ep3', readFD='/dev/ffs/ep4', hostMode){3}[21;1H
Native transport should become available but does not (the following line is not present for failed case. Taken from successful case)
00:05:24.983000 : OnDBusPropChanged_NativeTransport(): deviceId=2, started=1, iAP2iOSAppIdentifier=1, sinkEndpoint=3, sourceEndpoint=4, TransactionID=1
EAP Start event not received (trace line from success try)
00:05:25.057000 : EAPSessionStart(ctx=0x74e0b800){2} called[21;1H
Is there any braking change on iOS 18 considering EASession? Also what is strange is that it works on fresh instal/restart iPhone, but not working on second attempt?
On iOS 18.x when try to create EASession we get nil, but on iOS 17.x everything works.
Please file a bug report and then post the bug number back here. As part of that bug, please go throw the testing process:
-
Restart the device so that you're starting with a "clean" testing device.
-
Unlock the device, then leave it alone for a few minutes. The goal here is let the device fully complete any startup activity before you start testing.
-
Note the exact time (as accurately as possible) and plug your accessory in to the device. Wait for ~1 min.
-
Note the exact time (as accurately as possible), then launch your app and proceed with your normal testing process to verify the accessory is working. During this testing, try to move slowly and deliberately through your interface and your interaction with the accessory. When you've finished your testing process, note the exact time (as accurately as possible).
-
Wait for a few minutes.
-
Repeat the process from step #3, replicating the failure. It's not clear from your description which of these (or both) are failing, so please do the same test cycle and test both:
-
Opening your app again and trying to reconnect.
-
Force quitting your app and relaunching it.
-
Once all testing is finished, wait 2-3 minutes, then trigger and collect a sysdiagnose.
-
Upload that sysdiagnose to your bug.
FYI, the reason I've asked for time stamps and the "slow" testing process is that it can make the console data much easier to interpret. On the time stamp side, the difference between a "working case" and a "failing case" aren't always obvious and the log volume is high enough that it's easy to end up wasting a lot of time looking at log data that isn't actually relevant. Similarly, the "slow" testing process helps "spread" the process over a wider time span, which makes it easier to track exactly what system activity is tied to the corresponding app/accessory activity. A lot of the system activity is asynchronous, which means "full speed" often causes the logging tied of one event/interaction to closely follow or overlap with other activity, making the chain of events harder to follow. Slowing the testing process down helps prevent that. The delay at the end of testing is just the more extreme example of that- the sysdiagnose process itself generates large amounts of log noise, so immediately triggering the sysdiagnose ends up piling up a bunch of log noise at exactly the wrong place.
Is there any braking change on iOS 18 considering EASession?
This is the first report of seen about this.
Also what is strange is that it works on fresh instal/restart iPhone, but not working on second attempt?
I need to see the sysdiagnose data to say anything specific, but what typically causes this kind of failure pattern is that a failure at the end of the working cases left the supporting system daemon in a broken state, which then causes the second attempt to fail. A few things that would be interesting to test around that issue:
-
Assuming you have access to multiple examples (copies? instances?) of the same accessory, see if using on of the other accessories work. This can help differentiate between a failure that's tied to the system tracking an individual device and a broader failure.
-
Try connecting to the same accessory with a different app. You can either use a simple test project, or change the bundle ID of your actually application.
-
Test with other unrelated accessories and apps to see if the issue is effecting the entire "stack" or just your app. Putting that test another way, does the succes of your accessory/app break create an immediate failure in the other accessory/app.
-Kevin
