Meta issue: AutobahnAndroid 2

[oberstet]

This is a meta issue to organize the issues related to bringing AutobahnAndroid up-to-date with the current WAMP ecosystem.

We'll be calling that next major release "AutobahnAndroid 2" for now.

Situation

AutobahnAndroid is a subproject of Autobahn.

"The Autobahn project provides open-source implementations of the The WebSocket Protocol and The Web Application Messaging Protocol (WAMP) network protocols."

AutobahnAndroid is a WebSocket and WAMP client library implementation specifically for Android. However, right now, it has multiple, concrete and important issues that need to get "fixed":

1. upgrade to WAMP v2 (the current WAMP protocol version, which is a major revision of WAMP v1) - AutobahnAndroid is still at WAMP v1 and incompatible with Crossbar.io and other WAMP routers
2. support TLS (and hence secure WebSocket wss): rip out use of NIO. Network IO should be done on reader/writer background threads (that's already the case), and use blocking IO on these (not yet, it is using NIO - a major PITA with no gain)
3. Ensure the library works for both UI apps and background services, eg don't resolve/connect TCP sockets on the main thread (network IO already happens on background reader/writer threads, but not DNS resolve and initial socket connect)
4. Update to Android 4.1+ ("Jellybean") APIs (everything before Android 4.1 will be unsupported)
5. Update to latest Jackson (JSON ser/unser)
6. support active sending of WebSocket Pings and client initiated automatic WebSocket Ping/Pong with timeouts for fast detection of TCP connection loss
7. support automatic reconnection at the WebSocket and WAMP level

Further, these would be nice, but can come later

• support WAMP-CRA authentication
• support WAMP-cryptosign authentication
• support different WAMP serializers: not only JSON, but also CBOR via https://github.com/FasterXML/jackson-dataformat-cbor
• support WebSocket compression ("permessage-deflate")

We should also

• Change license from Apache to MIT

For testing/examples:

• The library must be tested at the WebSocket level with http://autobahn.ws/testsuite/ and everything (other than optional things like WebSocket compression) MUST pass green (strict!)
• The library must be test at the WAMP level against Crossbar.io: http://crossbar.io
• We need (to update) the following test programs (written using the revised library):
  • a simple WebSocket usage example
  • a simple WAMP usage example ("Hello WAMP" .. like we have for other Autobahn languages .. which demonstrates all 4 WAMP interactions (call/register/subscribe/publish)
  • a AutobahnTestsuite client app (for testing the library)

Next Steps

The API as defined here and here needs to be revised.

There should be a separate issue for this, as it needs discussion and close collaboration.

[narendran87]

I also support this to be a major issue as of now - It puts the android implementations on hold which is one of the biggest application fronts.

[oberstet]

From https://groups.google.com/forum/#!topic/autobahnws/g7F-v6PrsX4:

AutobahnAndroid:

This has been unmaintained for some time, as the code base has major
issues that essentially would require a complete rewrite:

• WAMP v1 only
• use of plain callbacks in user API
• no TLS (NIO sucks)

Note: Right now, for Java and WAMP, have a look at
https://github.com/Matthias247/jawampa - this is WAMPv2 and based on
RxJava. If you are using Akka, there is
https://github.com/angiolep/akka-wamp

If we find time, we'd rather strive for a AutobahnJava that is:

• WAMP v2 (only)
• based on Java 8 CompletableFuture
• works on Android and outside thereof

---

Rgd CompletableFuture and Android:

• it's only avail on Android 7 ("Nougat") API level 24 and later: https://developer.android.com/reference/java/util/concurrent/CompletableFuture.html
• however, there is a backport here: https://github.com/streamsupport/streamsupport

Ideally, we would use the backport when on Android < 7, and the native stuff on Android 7+ and Java 8+.

[om26er]

I have been looking into this. The current websocket implementation is tied closely to Android i.e. makes use of Handler that is android specific and other bits. So the logical first step here would be to make sure the websocket dependency on Android is removed. The next thing then would be to get rid of NIO, I hacked around some code that does a websocket handshake using plain Socket, making no use of SocketChannel, though its ugly for now.

Once we are able to cleanup the base, it will clear the path for WAMP v2.

[oberstet]

@om26er Removing NIO from WebSocket as a first step makes sense!

So, essentially only touch and update the WebSocket/Android parts of the library. Remove NIO and support TLS. Stay with the reader/writer thread based design. Leave the WebSocket API as is (plain callback based).

As a result, we should have a WebSocket(-client) on Android library that is TLS capable.

It would also be nice to:

• allow building of the library in a Docker container defined from a Dockerfile, containing the whole Java/Android toolchain needed
• ideally, I have the source code of the library on my host (notebook), have these source mounted into toolchain Docker container started, the library is built inside the container and produces a APK that is left on the host again, from where I can then
• deploy it to Maven

[oberstet]

This is now implemented

[herbeth1u]

Update to Android 4.1+ ("Jellybean") APIs (everything before Android 4.1 will be unsupported)

Ideally, we would use the backport when on Android < 7, and the native stuff on Android 7+ and Java 8+.

What about these points? Is compatibility for Android < Nougat still planned? Thanks.

[om26er]

I took a quick look into streamsupport and from the brief look of it(and some testing), it seems that its just a matter of adding the library to the gradle project and updating our imports.

My main concern is that we don't know how well supported the backport is and if there are any bugs that we inherit with streamsupport and more importantly, if its solely a community effort or does it have some commercial backing.

@oberstet will have a better answer if support for Android < Nougat is planned.

[oberstet]

Currently, Nougat is at roughly 12% global distribution, so support for versions before is of commercial interest in principle.

However, this is lower priority (commercially) compared to first-class, Netty-based Java 8 support. Because this is what enables to integrate Java backend/server code into a whole (WAMP) system.

Commercial interest in AutobahnJava at the WAMP level on Android seems to be limited. Because there is AutobahnJS, and I can get away with a nice mobile HTML5 app or something. Less and less reasons a native app is required. At the WebSocket level, we don't have much interest commercially there, because we (obviously) care more about WAMP;)

Finally, WAMP can nowerdays also run over RawSocket - which is simpler to implement and get right than WebSocket, and also comes with less processing overhead. And when RawSocket is run over TLS/443, it pretty much has the same network transparency as WebSocket.

Only when there is a TLS unwrapping intermediary, the Web compatible design of WebSocket comes into play. However, at that point (a TLS intercepting intermediary in the line), one should probably worry about more than WAMP or WebSocket;)

[oberstet]

That being said, contributions are welcome of course!

Best would be PRs. We have some of CI already and we can review in the light of that.

However. we still need a covering set of unit tests and probably intergration tests (like in AB JS). Currently, we build and run exactly one program. Better than nothing. But. So this is also an area where contributions would be highly welcome!

[om26er]

If java had an equivalent of c++' ifdef this would be a simple thing to do. Finding a way that does not result in lots of code duplication will be a challenge here.