search

smartdevicelink / sdl_ios

Get your app connected to the 🚙, make your users feel like a 🌟
www.smartdevicelink.com
BSD 3-Clause "New" or "Revised" License
169 stars 105 forks source link

iOS15 beta suspends background SDL app while connecting with iAP transport #2029

Closed shiniwat closed 3 years ago

shiniwat commented 3 years ago

Bug Report

iOS 15 beta 7 seems to change the behavior running through iAP, and background SDL app does no response some case in background.

Reproduction Steps
  1. Start SmartDeviceLink-Example-Swift app, connect with HU via iAP.
  2. Press "Show Alert" button and conform it works well.
  3. Move SmartDeviceLink-Example-Swift app to background
  4. Press "Show Alert" button several times.
Expected Behavior

Show Alert button works normally even if app is in background.

Observed Behavior

After 10 seconds or so, "Show Alert" button stops working. If I bring the SDL app to foreground, all queued events start working (e.g. if you pressed the alert button three times, alert shows three times).

OS & Version Information
Test Case, Sample Code, and / or Example App

n/a

Side note

As the side note, iOS 15 beta 6 seems to change the app in background even if the app connecting with iAP. The exactly the same "SDL Test App" works well on iOS 14.7.1 running with the same HU.

shiniwat commented 3 years ago

Note that observed behavior is recorded in movie at: https://drive.google.com/file/d/1luwRoFamJZoRJcB2m2sR8E9DVn6MIyfe/view?usp=sharing

shiniwat commented 3 years ago

Another data input: If you keep the app untouched some time (say 60 seconds) while the app in background, then pressing "Show Alert" button on HU makes all queued events back to work. Looks like iOS 15's runningboardd (RunningBoard) keeps tracking how often the app consumes iAP transport, and force suspending the app in some condition. This is the new behavior on iOS 15 beta, which never happened on iOS 14.

shiniwat commented 3 years ago

Got yet another info in my testing. While SDLTestApp appears to be suspended (i.e. no response to pressing button), iOS console shows the following logs:

default 15:48:07.285351+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Set jetsam priority to 3 [0] flag[1]
default 15:48:07.285521+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Suspending task.
default 15:48:07.285892+0900    runningboardd   Calculated state for application<com.smartdevicelink.SDLTestApp>: running-suspended (role: None)
default 15:48:07.286736+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Shutdown sockets (SVC)
default 15:48:07.287074+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Set darwin role to: None

It looks like RunningBoard (runningboardd) enforces SDLTestApp's state to be suspended.

Then, if I pressed "Show Alert" button after some interval (about 30 seconds in my testing), iOS console shows the following log, and queued events (i.e. multiple Alerts) suddenly started working:

default 15:57:41.506654+0900    runningboardd   Acquiring assertion targeting [application<com.smartdevicelink.SDLTestApp>:1310] from originator [daemon<com.apple.accessoryd>:127] with description <RBSAssertionDescriptor| "accessoryd.com.smartdevicelink.SDLTestApp.1310.assertion]" ID:34-127-8672 target:1310 attributes:[
    <RBSDomainAttribute| domain:"com.apple.accessoryd" name:"OneTime" sourceEnvironment:"(null)">
    ]>
default 15:57:41.506890+0900    runningboardd   Assertion 34-127-8672 (target:[application<com.smartdevicelink.SDLTestApp>:1310]) will be created as active
default 15:57:41.508191+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Set jetsam priority to 4 [0] flag[1]
default 15:57:41.508301+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Resuming task.
default 15:57:41.508619+0900    runningboardd   Calculated state for application<com.smartdevicelink.SDLTestApp>: running-active (role: Background)
default 15:57:41.508696+0900    runningboardd   [application<com.smartdevicelink.SDLTestApp>:1310] Set darwin role to: Background
shiniwat commented 3 years ago

Let me correct one thing. As we double-checked with our QA, and the QA initially found the issue on iOS 15 Beta 5, and he confirmed that issue exists on Beta 6 as well. Also note that we are not certain if the issue exists on Beta 3 and Beta 4 as we no longer have those devices (i.e. already updated), but we are certain that the issue does not exist on Beta 2 (we still hold that device).

joeljfischer commented 3 years ago

Thank you for your testing. Have you tested on Beta 8?

shiniwat commented 3 years ago

Yes, I did. The issue still exists on Beta 8 (the behavior unchanged from Beta 7).

medlmichael commented 3 years ago

I'm seeing the issue as well.

shiniwat commented 3 years ago

Additional note: when I opened the issue, the observed symptom is based on iAP BT. I happened to notice the behavior somewhat differs if the SDL app runs through iAP USB.

The original text in Observed behavior section says: After 10 seconds or so, "Show Alert" button stops working.

This behavior is observed when I ran the APP thru iAP BT. However when the SmartDeviceLink-Example-Swift app runs thru iAP USB, the behavior would be: Right after the app goes to background, "Show Alert" button stops working.

I am not certain if the difference comes from iAP implementation on HU, but I am under the impression the behavior might be different if the SDL app runs with different HU/IVI system.

shiniwat commented 3 years ago

Today, iOS 15.0 (19A344) has been released. I have confirmed that this issue seems to be fixed on official iOS 15.0 release!

After upgrading from iOS15 beta 8 to 15.0 (19A344), pressing "Show Alert" button works just fine regardless of SDLTestApp is foreground or not.

Here's the excerpt from console log:


- then accessoryd detects some data in EASession

default 15:32:59.541505+0900 accessoryd Posting application state change { ACCPlatformApplicationStateDisplayIDKey = "com.smartdevicelink.SDLTestApp"; ACCPlatformApplicationStateKey = 2; ACCPlatformApplicationStateProcessIDKey = 376; }

- then runningboardd seems to be reactivating the app state

default 15:33:22.143091+0900 accessoryd Finished Create EA Session { ACCExternalAccessoryClientBundleIDKey = "com.smartdevicelink.SDLTestApp"; ACCExternalAccessoryPrimaryUUID = "32975D10-F05D-4C10-B217-AE8B3805FD2F"; ACCExternalAccessoryProtocolEndpointUUID = "32975D10-F05D-4C10-B217-AE8B3805FD2F"; ACCExternalAccessoryProtocolIndex = 2; ACCExternalAccessoryProtocolName = "com.smartdevicelink.multisession"; ACCExternalAccessoryProtocolType = 0; ACCExternalAccessorySessionID = 13; ACCExternalAccessorySessionUUID = "FB69DC61-A53E-4527-B0D5-E06CB39FA5DA"; ACCExternalAccessorySessionUsesSocketInterfaceKey = 1; IAPAppAccessoryCapabilitiesKey = 32816; IAPAppConnectionIDKey = 39412119; } default 15:33:23.597775+0900 runningboardd Assertions for process will expire soon: [application:376] default 15:33:23.599736+0900 runningboardd Acquiring assertion targeting [application:376] from originator [daemon:34] with description <RBSAssertionDescriptor| "Will expire assertions soon" ID:34-34-1005 target:376 attributes:[ <RBSCPUAccessGrant| role:NonUserInteractive>, <RBSDurationAttribute| invalidationDuration:4.48 warningDuration:0.00 startPolicy:Delayed-Fixed endPolicy:Invalidate> ]> default 15:33:23.599916+0900 runningboardd Assertion 34-34-1005 (target:[application:376]) will be created as active as no start-time-defining assertions exist default 15:33:23.604192+0900 runningboardd Calculated state for application: running-active (role: NonUserInteractive)


Obviously, the behavior of RunningBoard on iOS 15.0 seems to be changed after accessoryd detects some data in EAsession.
I think we might as well resolving this issue as fixed externally (by Apple).
joeljfischer commented 3 years ago

Thank you for all of your testing! I'm glad to see that you're no longer seeing this bug.