Some ideas to make adam a bit lighter as a library?

[mrubinsquare]

First, what a great library and tool! This was so handy, worked easily out of the box, and the documentation is excellent. The Kolin first, coroutine first approach was very much appreciated, too. I'm grateful that I could use it.

I'm consuming adam in what might be a somewhat unusual way by actually using it from within an Android app (and then connecting to the adb server at 10.0.2.2) for debug builds. I'm guessing this is not the main consumer you were envisioning, but nonetheless, here I am :) The library is a bit heavy as a dependency, even for just debug builds, and so I was thinking about how it might be lightened. One obvious change, I think, is to move the annotation dependencies to compileOnly. That won't save much, but it is something, and seems like a good idea. But a more interesting suggestion, perhaps, is to make some of the functionality optional. adam is incredibly full featured, but we won't be needing the gRPC support, say. I actually experimented with using gradle excludes to trim out those gRPC related dependencies, but I'm suggesting modifying the gRPC support (for example) to be a distinct dependency that I could choose to include or not. So there would be a core adam library and then some optional extension libraries. I'm not sure how hard it would be to segregate that out in the code. And of course, perhaps the same treatment can be done for other bits.

Thanks again for the library, your articles, and the documentation.

[Malinskiy]

Hey @mrubinsquare, thanks for your feedback! :)

Using adam from Android, especially from tests, is a use-case I've considered here to some extent, e.g. AdbRule and an example of how it's used in a test. Same kind of idea is implemented with rules that target gRPC and telnet access. You can find more information on this in special section the docs.

I can definitely see how large footprint of the library can be an issue: just adding adam in the current form to the Android test code means you have to use multidex.

Talking about reducing the number of dependencies: it is certainly possible to separate the gRPC code out, but my suspicion is that the main contributor is netty: it's used both for gRPC communication and adb/telnet via a transitive dependecy in vertx. There is a dead-ish part of the code that still supports ktor and I've done some work to minimise code's depdendency on that. Unfortunately, kotlin's primitives that support async streams of byte data (e.g. ByteReadChannel in ExecInRequest) have been moved from a kotlinx-io into ktor project. Unless there is a nice abstraction over byte channels that is universal, it's hard to move the project away from ktor.

Using compileOnly sounds like a nice way to trim the dependencies here and could definitely be leveraged. Another option is to actually split adam into the adb+telnet part and gRPC as a separate module.

I'm curious if excliding gRPC libs actually allowed you to skip multidexing, keen to hear about the results there.

[Malinskiy]

Hey @mrubinsquare ! I did some quick experimentation with extracting gRPC client for emulator on branch https://github.com/Malinskiy/adam/tree/feature/separate-emulator-proto. Could you give it a try? I'd like to understand if this improves the situation for you or not.

[mrubinsquare]

@Malinskiy , I'm so sorry I've been so slow to respond -- was having trouble carving out time. I'll make this a top priority tomorrow, and thank you for your thoughtful comments and work!

[mrubinsquare]

Hmm. I may not be doing what you expected for me to experiment. I git cloned the project, checkout that branch (separate-emulator-proto), and tried to assembleRelease, and I got a bunch of Unresolved reference errors in EmulatorControllerOuterClassGrpcKt.kt. I thought I'd build it, see how big the artifact is, pull the newly built one into my project and see what our resulting size was and that it worked . . . Should I be going about this another way?

[Malinskiy]

CI passed on the branch so it should assemble AFAIU. Maybe proto plugin leaves something in the build directory and you need a gradle clean?

My interest with your tests is how much can we save for Android's case in terms of number of methods as well as just the size of the binary

[Malinskiy]

This is what I get as a result of separating gRPC into a separate module on a test app: