Feature Request: Allow Explicit Configuration of service.name for Android RUM Instrumentation Problem

[simplekjl]

The current OpenTelemetry Android RUM SDK automatically determines the service.name resource attribute from the Android Manifest's android:label using applicationContext.applicationInfo.labelRes. This behavior is problematic for modern Android build setups.

In our configuration, and in many projects, the android:label uses placeholders (e.g., android:label="${appName}${appNameSuffix}") which are resolved at build time (e.g., via Gradle) and do not point to a string resource ID. Consequently, the internal readAppName function fails to retrieve a valid string, defaulting the service.name to "unknown_service:android".

Evidence of Limitation
The current implementation appears to rely on application.applicationContext.applicationInfo.labelRes, as shown in the provided snippet:

private fun readAppName(application: Application): String =
    try {
        val stringId =
            application.applicationContext.applicationInfo.labelRes
        application.applicationContext.getString(stringId) // Fails if labelRes is not a valid resource ID
    } catch (_: Exception) {
        DEFAULT_APP_NAME // Defaults to "unknown_service:android"
    }

Attempting to override the service.name via OtelRumConfig().setGlobalAttributes() is ineffective because the default Android resource attributes, including the problematic service.name derived from the Manifest, are applied after the GlobalAttributes provided in the configuration, or they are generated by AndroidResource.createDefault() which gets merged in a way that the Manifest-derived value takes precedence.

is there any other that the current implementation allows to change this?

[simplekjl]

on iOS it can be done passing configuration to the tracer, I wonder if we have the same for android.

[breedx-splk]

I was able to reproduce this with the demo app. Seems like a problem for modern android development practices and we should fix this. Thanks for letting us know!

[breedx-splk]

@simplekjl please have a look at #1302 and let us know if that will suffice for you.

This does not provide the ability to fully customize the resource. That is available today, however, but we believe that most users will not need to do this. As a result, this is not currently exposed via the initializer, and will require direct use of the OpenTelemetryRumBuilder, which provides methods to set the resource or to merge in a customized one.

[simplekjl]

@breedx-splk to give you more context is to separate our traces and logs in Grafana using the service.name we can achieve this with ease using service.name as follows:

• dev-android
• release-android
  which differs from using the appName of the flavors

Our backend currently follows this approach and we want to match this configuration with the mobile apps.

I am also open to propose the usage of a different approach if there is any good practice to do it while integrating traces and logs between BE and FE.