Sdl_evolution: [Rejected] SDL 0095 - AOA multiplexing for Android Proxy

[theresalech]

Hello SDL community,

The review of the revised proposal "SDL 0095 - AOA multiplexing for Android Proxy" (renamed) begins now and runs through May 22, 2018. Previous reviews of "AOA multiplexing similar to Android BT/SPP multiplexing" occurred April 11 through April 17, 2018, March 7 through March 20, 2018 and January 31 through February 6, 2018. The original review of "AOA multiplexing similar to Android BT/SPP multiplexing" occurred September 13 through September 27, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0095-AOA-multiplexing.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/286

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
[email protected]

[joeygrover]

While I agree with the spirit of this proposal as AOA experience needs improvement, I believe it falls short with a few key areas of concern:

Introduction of a second router service

The router service has always been setup to be a single service. The addition of a second service that runs in parallel is a large change. The statement These modification is not big impact to existing code. is incorrect and misleading. Proxies would have to be updated to know which router service they are trying to connect to based on their preferred transport or if they should switch to a different router service they are already connected. Thus, old proxies would not be able to understand this logic and simply connect to one or the other regardless of their intentions. This would be a breaking change in terms of behavior.

Secondly, the proposal states apps can choose BT or AOA, however, this would imply that the phone would then have two foreground router services and thus two persistent notifications which is irresponsible and not a great user experience.

I would suggest not creating a new router service and simply relying on the existing router service. If you look into the service you will see there is actually binding hooks for AltTransports. This is not functional in production yet, but works in debugging mode. This allows other transports to bind to the router service to act as the read/write channels. The feature needs to be flushed out more, but is operational for POC and should be discussed in this proposal. Or simply adding the AOA transport in the single router service; again the proposal should at least discuss this alternative.

Finally, how would trusted router security work? Would we have to know include which router service we trusted? Do we just trust all router services from that app if we trust one?

Accessory Filter Changes

<usb-accessory manufacturer="SDL" model="Core" version="1.1"/>: As discussed in the proposal, updating this would mean older apps that only have version 1.0 declared in their manifest would not be able to connect to these updated headunits. This would be a breaking change. Apps would be forced to include this new version in their accessory filter to connect to newer headunits. This is a big downside.

Binder Transactions Limits

Android's Binder transaction buffer currently has a limit of 1Mb, for all binder transactions. As the Android documentation states,

The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process. Consequently this exception can be thrown when there are many transactions in progress even when most of the individual transactions are of moderate size.

This is already a concern for apps only using bluetooth, but with the introduction of AOA for the purpose of video streaming it will be very easy to reach this limit and thus create performance issues. The current router and transport broker already have systems in place to handle the TransactionTooLargeExpceptions, but it is brute force system as there is no way to know the current amount of free space left in the buffer.

Conclusion

My recommendation would be to reject or at least return for revisions (though a lot of revisions would be needed) based on lack of implementation details that will be key to this feature's success as well as not including any information relating to binder transaction limitations as this would have to be proved to not be a factor, or include how it will be worked around.

[shiniwat]

Hello, I'm working on the implementation work for this proposal, and have some comments in response to Joey's comments.

Introduction of a second router service

As far as I looked into code, AltTransport is debug-only and works only if MultiplexBluetoothTransport is disconnected. It is hard to know if it is planned to enhance for production in the future or it is just for debugging purpose and has no plan for further enhancement. While Joey suggests the router service should be always setup to be a single service, I think it depends on implementation and we should think about pros and cons.
One of the reasons I think it is better to separate the AOA router service from existing router service would be the difference of life cycle of the service. The life cycle of the existing (Bluetooth) router service is coupled with Bluetooth connection, which seems to make sense to me. In the same manner, I think it makes a lot sense to design the life cycle of AOA router service to be coupled with USB connection; i.e. it starts when UsbAccessory has been attached, and stops when UsbAccessory has been detached. Of course, we can design the life cycle of the router service to be apart from the hardware connection, but managing two totally different hardware connections in single service may increase the complexity. Well, it highly depends on the implementation, though.

Accessory Filter Changes

I actually don't think we have to change the accessory filter for AOA router service. As Joey suggested, it is OK to stuck with version=1.0 for backward compatibility.

Binder Transactions Limits

According to Android documentation, as Joey stated, transaction buffer is shared by all transaction for the process. In other words, if I understand it correctly, it has separate buffer if the service is hosted in different process from SdlRouterService. But I agree that we have to be careful for this limit, and to be error prone if we reach the limit.

[tsuzuki-uie]

@joeygrover
Thanks comment.

This is supplement for "Accessory Filter Changes".
The choice can be handled by OEM.
If OEM think that backward compatibility of "old APP running is important" then, OEM can choose "1.0".
If OEM think that focus to new App then, OEM can choose "1.1".
Important thing is "new Apps can be run both HU". Only limitation to use "1.0" is "if old App is chosen by user, then new Apps cannot be connected". It can be avoided by OEM with operating white list.

Well, I agree that this proposal is not perfect solution of unified transport for contents vendors.
We should consider fully abstract transport which includes BT/USB/WiFi in the future.
However, WiFi support may require time to discuss in SDLC. On other hands, multi USB is required asap. This is background of this proposal.

[BrettyWhite]

I am worried about trying to pass through options now for the sake of having them now and not considering the total impact to the project as a whole in the future. This proposal already states a problem if there is an _old_ AOA and a _new_ AOA app on the same device. If more transports in the future are added, or the need to make an abstract transport arises - the complexity of backwards compatibility, total project complexity, and developer experience may be hindered. While i'm not proposing another solution in this comment, I believe it needs more discussion and consideration of how future cases would be handled.

[theresalech]

The Steering Committee determined more time was needed to review and discuss this proposal, so voted to defer (keep in review) until next week's meeting, 2017-09-26. The Xevo team will work to provide more example code and how they see this feature working.

[shiniwat]

Here're more details about this proposal.

Work-in-progress code:

sdl_android AOA multiplex source (feature/aoa_router_service branch): https://github.com/shiniwat/sdl_android-1/tree/feature/aoa_router_service
AOA Router Service addition for Hello SDL app (feature/aoa_router_service): https://github.com/shiniwat/hello_sdl_android/tree/feature/aoa_router_service

Steps required for existing SDL app to utilize AOA Router Service

1. Extend SdlAoaRouterService class and add node into AndroidManifest.xml.
2. Similar to using USB transport, user app must pay attention to com.smartdevicelink.USB_ACCESSORY_ATTACHED broadcast message.
3. When com.smartdevicelink.USB_ACCESSORY_ATTACHED message is received, user app will query SdlAoaRouterService by SdlReceiver.queryForConnectedService API.
4. After AOA service is queried (the API automatically starts service if none exists), user app also needs to pay attention to newly added broadcast intent (its action is “sdl.router.openaccessory”), which will be fired when UsbManager opens the accessory
5. When the broadcast intent (“sdl.router.openaccessory”) is received, user app should start proxy by SdlProxyALM api with MultiplexTransportConfig as TransportConfig.
6. In order to distinguish from Bluetooth Multiplexing, user app must specify MULTIPLEX_AOA to MultiplexTransportConfig.TransportType when instantiating SdlProxyALM.

For details, please refer to this commit: https://github.com/shiniwat/hello_sdl_android/commit/b1c517159c0036470914acd87cb67a66d303e641

Current design

Separating from Bluetooth Multiplexing Router Service

In order to keep existing router service (for Bluetooth Multiplexing) intact, AOA router service uses yet another router service, called SdlAoaRouterService. User app must specify defineLocalSdlAoaRouterClass (which must be different class from defineLocalSdlRouterClass) for AOA Router service class. The service must be in separate process, and its process name should be “com.smartdevicelink.aoarouter”.

Share the same design as existing Bluetooth multiplexing

The basic design is the same as existing Bluetooth multiplexing architecture, and uses the same TransportBroker for both SdlRouterService (for Bluetooth) and SdlAoaRouterService (for AOA). The messages between service and broker are identical. Broker pays attention to TransportType to identify if the recipient is the Bluetooth router service or AOA router service.

AOA Router service lifecycle is the same as USB connection

Unlike SdlRouterService (for Bluetooth multiplexing), SdlAoaRouterService is designed to be launched after USB is attached, and will be stopped immediately after USB cable is detached.

Note (restriction) for SDL app for using AOA Router Service

Every app that utilize AOA Router service should pay attention to if the app is granted for UsbAccessory permission, and should query the service only if it is granted. This can be done by looking into if the intent (action=USBTransport.ACTION_USB_ACCESSORY_ATTACHED) has EXTRA_PERMISSION_GRANTED. Current design relies on SDL app to launch/query SdlAoaRouterService only if USB permission is granted.

[joeygrover]

I reviewed the linked code, thank you for that.

I still believe we need a lot more discussion/information on this proposal.

Why is a second router service the best idea?

The author should clearly state why this approach is the best to implement. It is not clearly stated because of the lack of alternatives stated even though there are plenty.

I believe it is not the best approach as we are asking developers to add not only more code to their projects, but redundant modifications. Every time we ask the developer to do something we need to have a specific and absolute use case for doing so. Just adding more and more because "it's not that big" is not an acceptable reason. Why should developers essentially have to double their multiplexing integration to achieve nearly the same result?

We can make changes to the router service to accommodate the USB transport and any other transports so why shouldn't we do that? (AltTransport as mentioned can be made production) The lifecycle of the router service can be changed to follow a combination of bluetooth and USB, there is no harm in that.

Two notification icons

This concern has not been addressed:

[...] this would imply that the phone would then have two foreground router services and thus two persistent notifications which is irresponsible and not a great user experience.

Trusted Routers

This question from my first post has not been answered.

[...] how would trusted router security work? Would we have to know include which router service we trusted? Do we just trust all router services from that app if we trust one?

Transport to use

How do apps know which transport/router service to use? Do they care? Do we care? Should all apps try to use the highest bandwidth transport? Or should we maintain multiple connections for different transport types?

Binder transaction Limit

As mentioned earlier there is a 1Mb limit for binder transactions. The author used anecdotal evidence to inform the committee it works, but we will need more concrete, tangible evidence/findings. I would need to see actual measurements of how much data could be sent through the router services binder before it started to overflow. (This is applicable to USB router service due to the nature and data size of video streaming) I would then request even more applicable smoke test of multiple different app types connected at the same time proving there is no degradation. For example, having a navigation app streaming video, music app playing music updating metadata, and weather app providing updates and being able to switch between each seamlessly all using the same transport.

Impact on existing code

New service and TransportConfig will be added. These modification is not big impact to existing code.

After reviewing the POC code it appears that this is not the case. Opening a pull request against the develop branch this is the result:

This is a large change and should be represented as such. There are a lot of code changes made that are not represented in this proposal in the POC that seem necessary and should be contained in some scope in this proposal.

Timing

I want to make sure it is understood that this is a large proposal that is likely not feasible to accommodate into the Android 4.4.0 release even if the proposal is accepted by the deadline. This feature changes how a transport works and needs an extensive amount of testing before making it into production. The timeline of development for the original multiplexing feature was 1.5-2 years. Granted it will not take nearly as long for a feature that is similar or built off of it, but it should give insight that altering transport dynamics is a large scale effort that should not be rushed.

[tsuzuki-uie]

@joeygrover
Thanks comment back and short discussion via webex.
I summarized comparison to AltTransport approach, and some answers for your comments.
summary pdf

[theresalech]

The Steering Committee has voted to return this proposal for revisions, to allow the author to update the proposal based on the discussions here and the separate meeting between the author and project maintainer on September 25, 2017. It was also noted by the author and project maintainer that SDLC Members should make an effort to investigate and understand the issue this proposal is aiming to solve, and understand why the author and project maintainer believe this proposal should be prioritized. If desired, a separate discussion can be scheduled to review the proposal. Further discussion about priority will take place at the 2018 Roadmap Workshop in November.

[theresalech]

The author of this proposal has elected to not make the revisions voted upon by the Steering Committee previously and instead requested that the original proposal be re-reviewed. The Steering Committee agreed to move the original proposal back into review and will vote on the proposal during the 2018-02-06 meeting.

[joeygrover]

The author of the proposal and the project maintainer were not able to agree on an approach to take, so I would like to refer to my previous concerns as they are still valid. However I believe the comparison provided is not accurate and leans biased to the authors solution as a possible misinterpretation of the project maintainers POC (reference).

I admittedly must reject any change that requires the project to add a second service. Adding a second service to another seperate remote process in Android is resource intensive on the system (reference). Keeping a single service is the responsible course to take. The solution can take different forms using a single service and thus they should be presented as alternatives and discussed.

[shiniwat]

Well, if I understand the reference above correctly, it states the service should be stopped as soon as it becomes unneeded. Android system keeps the RAM for service and won't be reclaimed as long as the service process is running. AOA router service starts immediately after USB cable is connected, and stops as soon as USB cable is disconnected. So I think it still complies with Android system guideline, in terms of efficient memory management.

Having said though, introducing another service is NOT the heart of our proposal. It is kind of implementation details, but the point of our proposal is to introduce different logical router that works independently from existing Bluetooth router. We are going to change the approach to not adding another service for AOA multiplexing, while taking the basic architecture as we proposed. We will update more details later.

[tvkanters]

The use of version in this accessory filter seems to abuse the concept and intended purpose of versioning. As this functionality seems unrelated to core changes and what we really want is a feature toggle, the incremental nature of a version doesn't seem appropriate.

Apart from it being semantically confusing, I can foresee issues in the future when there is a change in the core that actually warrants a version increment. If we then have a version 2.0, we'd also need a 2.1 for apps who want to use the new core without implementing multiplexing.
Naturally, a workaround for this would be to force all new apps to support multiplexing, but I don't see this requirement/downside mentioned in the proposal. If I understand it correctly, this would mean newer apps have to follow the 'AOA Router Service' steps posted in the comments here earlier. The accompanying commit doesn't seem trivial enough to warrant making this a requirement for apps.

[joeljfischer]

Admittedly I am an iOS developer, and that is my primary domain. However, I have kept tabs on this and am attempting to understand every side.

First, I'm not sure if @shiniwat speaks for Xevo, but given the comment:

We are going to change the approach to not adding another service for AOA multiplexing, while taking the basic architecture as we proposed. We will update more details later.

This proposal should be returned for revisions or rejected, right? There's no real point in continuing discussion until these changes are added?

Second, this proposal seems rather short and somewhat difficult to understand for such a major change. I believe a more detailed and clearer proposal may be needed to ensure all stakeholders understand the changes being proposed.

[madhuy]

@joeygrover @joeljfischer @tvkanters
Thank you for your feedback and time.

Let me try to address the @joeygrover concerns

Multiple services( Two notifications, trusted Routers):

Xevo is changing implementation to include AOA code in existing service(sdlrouterservice).

Tranport Use:

This proposal focuses on multiplexing AOA (i.e. sharing AOA transport among multiple apps) so whether the transport is used by an app or not is outof scope of this proposal. Another feature may be developed to improve this point in future. For example, Proxy may select a transport based on the app type - if it is "Navigation" app then proxy chooses AOA, otherwise SPP transport.

Binder Transaction Limit

Xevo integrated this solution and verified by using 3 apps (Navigation,Media,non-media) running at the same time. Solution is perfectly working.We have video not sure if we can share in public forum because of NDA with partners.
And it is more generic Android problem not specific to this proposal. Xevo will provide test cases and test results while creating official PR.

Impact on Existing code and Code Size:

it is expected as we are adding new feature. Xevo will provide unit tests to cover the code. If SDLC have any concerns in code please provide comments/feedback Xevo will address all.

Timing:

Xevo understand the it is large proposal and need extensive testing. SDLC can decide timelines and release schedule .

[theresalech]

The Steering Committee voted to return this proposal for revisions. Revisions will include changing the implementation to include AOA code in the existing service, as opposed to a second service, and other details as outlined by the author in the last comment from madhuy. Implementation timing was also discussed, and it was determined it's more likely this feature will be included in the Android 4.6 release scheduled for 2018-06-29 than the Android 4.5 release scheduled for 2018-03-29.

[theresalech]

The author has updated this proposal per the agreed upon revisions, and the revised proposal has now moved into review. The Steering Committee will vote on this revised proposal during the 2018-03-13 meeting.

[theresalech]

The Steering Committee voted to defer this proposal, keeping it in review until our next meeting on 2018-03-20, to allow for more time to review.

[joeygrover]

Transport specific message handlers

SdlRouterService internally holds separate Handlers according to the TransportType, and returns the right Handler when binding to the service, so that IPC channel is isolated per TransportType.

What is the advantage of keeping two separate handlers?

ITransportWriters

What is the purpose of these additions? I don't see any benefit over just keeping the transport as a reference in the SdlRouterService itself as it is today with the bluetooth transport.

Possible permanent Router Service

When a user plugs in their device to an AOA connection, they are prompted with selection dialog. The dialog contains all apps that supported the currently connected module. In this dialog there is also an option to always open a specific app for that module. There will be an issue if the user picks an app to always receive the AOA intent and it propagates the router service. This will force all multiplexed connections to go through that apps router service regardless if there is a newer router service present. If by chance that is not a trusted router service, no other apps will ever connect until the user clears the flag.

This will also have an effect if a router service is currently up and running (bluetooth connected) and the user plugs in the USB cable and the app tries to launch a second router service. This creates a confusing experience for the user.

Packet Priority

There is no discussion on how packet priority will work with the two different transports. Currently each RegisteredApp maintains a queue of packets to send through the connected transport. If we have a case where both bluetooth and USB are connected we will need to determine if we are ok with all apps regardless of transport being placed in the same queue consumer or if we need different consumers based on transport type.

Multiple sessions per app

The proposal assumes that an app will always use the same transport regardless of how many sessions they have or which session wishes to use which transport. That can be a potential issue. If an app has one session that can use just bluetooth, but another that has to have USB, is it acceptable that the router service just forces the second app onto USB? Even if it has already been registered over the bluetooth connection?

Secondary transport consideration

With the recently accepted #405, we will now have to write the proxy and router service in such a way that the registered apps can communication through multiple different transports at the same time. This proposal will have to be updated to reflect that.

[shiniwat]

@joeygrover Thanks for the comments.

Transport specific message handlers

What is the advantage of keeping two separate handlers?

The purpose of separating the handler for AOA transport from existing handler is to isolate message-handling between BT messages and AOA messages, which makes BT router being intact.

ITransportWriter

What is the purpose of these additions? I don't see any benefit over just keeping the transport as a reference in the SdlRouterService itself as it is today with the bluetooth transport.

TransportWriter is added mainly for improving code readability. This also makes it easier to extend the transport and/or adding another transport support to SdlRouterService.

Possible permanent Router Service

There will be an issue if the user picks an app to always receive the AOA intent and it propagates the router service. This will force all multiplexed connections to go through that apps router service regardless if there is a newer router service present.

As far as all SDL applications share the same accessory_filter (and we assume so), it is kind of limitation of Android system that all applications that have USB_ACCESSORY_ATTACHED intent-filter can be a router, and it is user choice which app is chosen as the activated app. On the other hand, current BT router has the logic to prevent secondary service from launching if SdlRouterService already exists on the system. In fact, the activated app by USB_ACCESSORY_ATTACHED broadcast intent has nothing to do with the permission to access the UsbAccessory. Therefore, if SdlRouterService is already running and the currently running router service requests the permission to access the UsbAccessory, everything works as expected. I admit, however, user might be still confused by system dialog that is launched by USB_ACCESSORY_ATTACHED broadcast intent.

This will also have an effect if a router service is currently up and running (bluetooth connected) and the user plugs in the USB cable and the app tries to launch a second router service.

As mentioned already, we can leverage the logic to prevent secondary router service from running if the service already exists.

Multiple sessions per app

Let me address Multiple sessions per app prior to Packet Priority.

The proposal assumes that an app will always use the same transport regardless of how many sessions they have or which session wishes to use which transport.

Yes, I assumed the registered app uses the same transport regardless of how many sessions it has. Currently registered app cannot use multiple transports per session. But I admit this is going to be changed due to simultaneous multiple transports proposal at #405

If an app has one session that can use just bluetooth, but another that has to have USB

We can extend RegisteredApp to support multiple transports. For example, by adding hashmap -- The pair of appId and sessionId pair to transport. We may also need to manage the pair of transport type and sessionId to appId, so that we can manage both incoming and outgoing packets properly.

Packet Priority

If we have a case where both bluetooth and USB are connected we will need to determine if we are ok with all apps regardless of transport being placed in the same queue consumer or if we need different consumers based on transport type.

As mentioned in previous section, I assumed RegisteredApp uses single transport only, but things are going to be change by multiple transports support.
Regarding your question, I think managing the queue per transport would be better. RegisteredApp and PacketWriteBlockingQueue will be extended to support queues per transport.

Secondary transport consideration

With the recently accepted #405, we will now have to write the proxy and router service in such a way that the registered apps can communication through multiple different transports at the same time.

You are right that I did not take account of multiple transports support when I wrote the proposal. While I admit RegisteredApp and some inner stuff must take it into account, I believe the basic design remains the same. I am going to add multiple transport support consideration into the proposal.

[joeygrover]

Transport specific message handlers

Ok, I might have misunderstood this. These two handlers are one for the MultiplexBluetoothTransport and the other for the MultiplexUsbTransport? I thought you were thinking about creating two seperate message handlers for the bound clients.

ITransportWriter

I still don't see the benefit with this. Doesn't it make more sense to just refactor:

private MultiplexBluetoothTransport mSerialService = null;

----- to  --- 

private MultiplexBluetoothTransport bluetoothTransport = null;
private MultiplexUsbTransport usbTransport = null;

That would eliminate an unnecessary abstraction.

Possible permanent Router Service

Are you saying it's possible a user choose App A to receive the USB intent, but if App B has a router service up in can actually grab the USB transport? If that's the case, then it is possible to alter the current flow to start up the newest router service during a USB only connection regardless of which app the user has chosen for the intent. I would like to understand if that is possible, because I didn't believe it was.

Misc.

Ok I can see we are going to need to revise the proposal based on the new secondary transport option and it will affect a few aspects of the proposal. Also, including a new PacketWriteBlockingQueue per transport.

I am also wondering if we want to write a separate proposal that includes the WiFi transport in a similar fashion. It would seem to then move all transport logic out of the individual proxies and all be hosted by the router service.

[theresalech]

The Steering Committee voted to return this proposal for revisions. The revisions should reflect the logic updates necessary given the accepted Simultaneous Multiple Transports Proposal. Also discussed was moving the WiFi transport into the router service as well, then refactoring to remove some code from the proxy. This may require a separate proposal, but should be considered when revising this proposal to support simultaneous multiple transports. Lastly, the author noted that they do believe it's possible that if a user chooses App A to receive the USB intent, but if App B has a router service up it can actually grab the USB transport. They will verify and explore the possibility of altering the current flow to start up the newest router service during a USB only connection regardless of which app the user has chosen for the intent.

[joeygrover]

MultiplexTrannsportConfig is extended to be aware of TransportType. A new TransportType "MULTIPLEX_AOA" is supported in addition to "MULTIPLEX".
SDL application specifies TransportType when configuring MultiplexTransportConfig.

Most apps won't care which transport is their primary as long as they can connect. We should keep that abstracted away from the developer. If an app wishes to use a high bandwidth transport for video/audio services I believe that's where we could extend the config to include information. It is possible we include a map of services to prefered transport types, HashMap<ServiceType,TransportType[]. However, I think we can include a default config for these.

SdlRouterService internally holds separate Handlers according to the TransportType, and returns the right Handler when binding to the service, so that IPC channel is isolated per TransportType.

I still disagree with this approach. All clients should be connecting through the same handler. This will help us keep all requests synchronized as they come in as well as removing unnecessary overhead that the developer has to figure out by defining which transport they want to connect to.

Currently RegisteredApp uses the same TransportType for all sessions, but this will be extended by upcoming simultaneous multiple transports support. RegisteredApp will be extended to support multiple transports per session.

This proposal was already accepted so the information has to be included in this proposal that works with that. This is what we voted on as a revision from the last review session.

The proposal itself does not contain enough support for the simultaneous transports changes and I will need to see how that is planned to be implemented before supporting this proposal.

We have been developing how we believe this feature should be implemented and it should be used as a basis for when it is included. The current branch (See here) supports USB transport through multiplexing as a singular transport. You can quickly compare changes here. We are internally working through how we support the simultaneous transports. I was hoping this revision would include those changes, but the proposal itself does not contain enough support for the simultaneous transports changes and I will need to see how that is planned to be implemented before supporting this proposal fully. We will continue to work on it on our side, and will likely come back with how we believe it should work.

[shiniwat]

Most apps won't care which transport is their primary as long as they can connect. We should keep that abstracted away from the developer. If an app wishes to use a high bandwidth transport for video/audio services I believe that's where we could extend the config to include information. It is possible we include a map of services to preferred transport types, HashMap

The approach sounds good if the proxy runs with the SDLCore that has simultaneous multiple transports support. But what if the proxy runs with current (4.5 or older) version of SDLCore? Explicitly specifying TransportType is actually the base concept of this proposal. You know this proposal is initially written for running with current (4.5 or older) version of SDLCore. Changing this basic concept even for current version of SDLCore implies I need to rewrite the proposal from scratch.

This proposal was already accepted so the information has to be included in this proposal that works with that. This is what we voted on as a revision from the last review session.

The proposal itself does not contain enough support for the simultaneous transports changes and I will need to see how that is planned to be implemented before supporting this proposal.

How about separating the simultaneous multiple transports support from this proposal? I agree that AOA multiplexing should work with simultaneous multiple transports, but it is equally important to make AOA multiplexing to work for current version of SDLCore. As you mentioned, there are many pieces need to be considered to make AOA to work for simultaneous multiple transports, because there are lot of things that will work in different way. How about developing AOA multiplexing in two phases? Phase one will focus on AOA multiplexing that works with current version of SDLCore, which this proposal focuses on. Phase two will cover the AOA multiplexing that works with simultaneous multiple transports, which requires another proposal.

[joeygrover]

I understand the concern, but I do not think the proposal needs to be totally rewritten. There are certain aspects of these feature that have changed over the course of this proposals review period. Therefore, we have to include those changes into the proposal before being accepted.

Unfortunately I do not believe it makes sense to split this proposal into two stages. The simultaneous transport proposal was already accepted and has an intended implementation date for the September releases this year. It does not make sense to create a developer facing API change that is just going to change in the next release when we know it will have to change.

You do bring up an interesting point that I'm not sure was really defined well enough in the simultaneous transport proposal, how does that system work on older Core implementations that don't support the feature? This is where we will have to cleverly craft a system that can handle both while keeping it behind the scenes for developers. The only time that this really becomes an issue is knowing if an app intends to perform video or audio streaming so maybe we add a flag to the proxy that indicates the app has a requirement for high bandwidth. Because essentially that's all we want to know; does this app require a high bandwidth transport and can the library provide them one during this session.

[theresalech]

The Steering Committee has voted to return this proposal for revisions. The author will revise to include more details about simultaneous multiple transport support in this proposal, and may determine if some features of this proposal should be included in a separate proposal. Support for simultaneous multiple transports was determined necessary as the multiple transport feature has been accepted and will be supported in SDL. Additionally, the revisions to this proposal should include details about allowing an app to choose a transport, keeping in mind that we need to know when an app needs a high bandwidth transport. For example, if the app needs high bandwidth, it shouldn't be able to register over bluetooth.

It was noted in discussion that the Project Maintainer is also investigating the best way to handle this within the router service, and will share additional information once available.

[theresalech]

This proposal has been revised by the author and will now be in review until May 22, 2018.

[AndrewRMitchell]

This is a nitpick, the formatting of the link at the end of the Motivation section leads to a broken icon (with working link) in Safari, looks normal in Firefox, and appears with broken icon before a normal link in Chrome. Can we get it cleaned up so it works across browsers? Thanks.

[shiniwat]

Hi @AndrewRMitchell, thanks for pointing this out. Realized this is a trivial error -- removing exclamation mark in md should fix the broken icon, and I will fix it when I have a chance for revising the proposal. In the meantime, please ignore the broken icon for the link. Thanks.

[joeygrover]

I apologize for my last minute comment. I still find a few issues that I have asked to be cleared up in the proposal itself (handler per transport for example) but I would like to bring a different approach to the discussion. Based on this proposal and new ideas I am planning to bring a new evolution proposal to the committee that will overhaul the transport layer of the Android library. As we have discussed and generally agreed to the idea of the router service containing all transports, the underlying architecture would need to be altered to support this in a more efficient way. Currently trying to trace code from off the transport to even the SdlSession is a nightmare of abstracted classes and interfaces. The biggest change is moving WiProProtocol directly into the SdlSession class, introducing a simpler transport layer, TransportManager, and deprecating/removing the use of SdlConnection.

The proposal is a draft in its current state. I wanted to get some information out there, but by no means is it complete. I intentend to break down more of the changes required to make this work. I will also add sequence diagrams for better understanding of how it works.

The current branch is a working branch of the overhaul. There is still cleanup to be done, but it is mostly working for single transport apps. It has not yet integrated the simultaneous transports piece fully.

All items are still works in progress

• Evolution proposal - https://github.com/smartdevicelink/sdl_evolution/pull/495
• Code branch - https://github.com/smartdevicelink/sdl_android/pull/768
• Sample apps - https://github.com/smartdevicelink/sdl_android/files/2028502/sample_apps_2018_05_22.zip

[theresalech]

The Steering Committee voted to defer this proposal. It was determined that the proposal author would work offline with the Project Maintainer on a new proposal (https://github.com/smartdevicelink/sdl_evolution/pull/495), which will incorporate the AOA Multiplexing described in this proposal and also extend to overhaul the transport layer in a way that more efficiently allows the router service to include all transports.

[theresalech]

The Steering Committee voted to reject this proposal in favor of the accepted proposal SDL 0194 – Android Transport Layer Overhaul.