Android support

[jpkrohling]

We currently don't have reports about applications using OpenTracing with Android. It would then be worth doing a research on what's needed to get it working. At this moment, we are not sure what would break and what's missing.

Task outline:

• [ ] Bootstrap an Android project
• [ ] Instrument the code manually using the OpenTracing libraries
• [ ] Assert that the instrumentation works by using the MockTracer

[yurishkuro]

fwiw https://github.com/lightstep/lightstep-tracer-android

[yurishkuro]

One other task that would make sense for Android is to revisit & minimize the dependencies used by Jaeger (in particular, we could try to implement manual marshaling of spans and avoid depending on thrift).

[jpkrohling]

in particular, we could try to implement manual marshaling of spans and avoid depending on thrift

+1 , do we want to do that by ourselves before Outreachy, or do you think this would belong to this Outreachy task?

[yurishkuro]

I think it can be an Outreachy task, since it's not that difficult (more tedious than difficult), but certainly impactful. The main question to me is whether we want to use Thrift or Protobuf encoding, i.e. if we're moving towards protobuf anyway, why bother with manual Thrift in the clients. But at least with Thrift we have an example of how to do it from Adrian's code in Zipkin, I don't know if it's much harder to encode Protobuf manually (I hope it's not that different). Of course going with protobuf creates yet another dependency for completion - having an endpoint in the agent that understands it (and all kinds of other questions around it, UDP vs. ?, etc.)

[jpkrohling]

For protobuf, this might an interesting reference: https://github.com/square/wire

[yurishkuro]

Just had a look at wire, not sure it makes sense. It does bring extra dependencies itself, like guava. And it's main objective appears to be to change how the generated classes look, which is not our primary concern. But it's worth comparing how much size difference there will be between the official protobuf library and wire, when everything is shaded.

A couple more peculiar things about wire. It declares class fileds as public "to avoid generating getters" which reduces code size for Android. But at the same time it provides fluid builders, which add that extra code right back.

And it always boxes the primitive fileds. That would create unnecessary GC pressure for us, since most fileds in the span proto model are required, even if proto3 doesn't support that.

So if we optimize for speed, GC, and code size, I doubt anything will beat manual marshalling.

[jpkrohling]

So if we optimize for speed, GC, and code size, I doubt anything will beat manual marshalling.

I guess this is the key point. My idea, though, was to use both the official protobuf libraries and Wire as an accessory for building/comparing the serialization procedure.

[yurishkuro]

Yes, the tests would need to compare manual serialization with official once.

Btw, I just realized this is an OT issue, but we're discussing Jaeger specific problem. I would suggest to close it and open a clean one for OT. I'm not even sure what we need in OT specifically for Android.