Add support for indirect use via android library

[bbetter]

I have multimodule application and I don't want to inject arm directly inside app module
Instead I want to be able to connect it to my android library module and abstract away lib initialization

[LikeTheSalad]

Thank you for your feedback, @bbetter

If I understood correctly, it seems like manually adding the Elastic SDK into your library should sort your use case. We still haven't documented how to do so, but the dependency looks like the following:

implementation "co.elastic.apm:android-sdk:0.4.0"

The version will always match the Gradle plugin version.

After adding the SDK to your library, you can initialize it from there and it should work the same as if you'd have initialized it from your application. Bear in mind that, regardless of whether you initialize it from your application or your library, it is still recommended to apply the Gradle plugin into your application so that you can get access to the compile-time gradle configuration options, as well as automatic instrumentation support.

[bbetter]

Great to see some answer, thanks.
Just a quick question not to create separate issue:
I see min sdk is 26. Is there somethning specific that 24 sdk missing? if i just override sdk for the specific library via Manifest , what are the chances that it's going to work correctly?

[LikeTheSalad]

The decision to have the min SDK version as 26 was made to make the setup process more straightforward and avoiding crashes on older devices. The reason why lowering it would make things more complicated is that the OpenTelemetry SDK uses some classes added in Java 8, which are not available on Android OS versions < Api level 26, on those devices the app would crash with a NoClassDefFoundError (like when running this code for example as the java.time.Duration is one of those newer classes).

There's a way to avoid this, though it would require adding extra dependencies and doing some extra compilation work as well, all of the details are explained in here. We also weren't too sure if the API 26 was too "restrictive", since it seems to be available since mid 2017, so we ultimately ended up setting it as the min one and review that decision later in case some customers would require to lower it.

So based on it, I'm curious to know about your opinion on whether using the API level 26 nowadays is still too soon in general? If that's the case, we'll consider lowering it to 24.

[bbetter]

It might be just our specific scenario to have to use a bit older version . So you're saying if I override library
<uses-sdk tools:overrideLibrary/>
and then add coreLibraryDesugaring
it should save me from unexpected crashes?

also about this

it is still recommended to apply the [Gradle plugin](https://plugins.gradle.org/plugin/co.elastic.apm.android) into your application so that you can get access to the [compile-time gradle configuration options](https://www.elastic.co/guide/en/apm/agent/android/current/configuration.html#_gradle_configuration), as well as automatic instrumentation support.
As I see configuration from ElasticApmConfiguration object doesn't work
it says java.lang.RuntimeException: java.io.FileNotFoundException: co_elastic_apm_android.properties then trying to retrieve environment

can I create this file by myself somewhere in my library root and let it be bundle with app for example
and just specify environment in there?
Or is the configuration without plugin impossible?

[LikeTheSalad]

It might be just our specific scenario to have to use a bit older version . So you're saying if I override library

and then add coreLibraryDesugaring
it should save me from unexpected crashes?

That's correct.

can I create this file by myself somewhere in my library root and let it be bundle with app for example
and just specify environment in there?
Or is the configuration without plugin impossible?

It's not impossible without the plugin, I'll create a couple of tickets to work on making the manual configuration smoother but in the meantime what you could do is:

• Create the asset file co_elastic_apm_android.properties inside your src/main/assets dir within your library.
• Add this line to that properties file: service.deployment_environment=(your env name).
• Make sure to configure your backend connectivity params at runtime as explained here, as well as providing your service name and version at runtime, as shown here.

It should make it work for now. We're continuously making new releases as we're still not GA, so the manual implementation process should improve quite soon.