Frequently asked questions

Android devices with an API level below 26 (older than Android 8.0) have limited support for Java 8 features and types, which can cause your app to crash when using those types while running on those older-than-8.0 devices. For example, if one of your app’s dependencies uses the Base64 type (added in API level 26), and your app is installed on an Android device with OS version 7.0 (API level 24), a crash will happen when the code that uses said type is executed due to a "class not found" error.

To prevent these kinds of issues on devices using Android OS older than 8.0, you must add Java 8 desugaring support to your app. This requirement is inherited from the OpenTelemetry Java SDK, which this project is built upon, where several of the unsupported types for Android versions older than 8.0 are used.

TL;DR: It’s complicated to change it to another name because of its widespread adoption within the OpenTelemetry community.

For historic reasons, service has been the default way of referring to "an entity that produces telemetry". This term made its way into OpenTelemetry to a point where it was marked as one of the first "stable" resource names, meaning that it was no longer possible/feasible to make a change to another name that would better represent any kind of telemetry source. This has been debated several times within the community. A recent discussion attempts to explain the service description and what it should represent in an effort to reduce confusion. However, there doesn’t seem to be a consensus.