Edot Android consistent naming (#438)

* Setting a single name for EDOT Android on the
index page

* Updating agent name in getting-started

* Updating EDOT Android name in configuration

* Updated EDOT Android name in manual-instrumentation

* Updating EDOT Android name in automatic-instrumentation

Author: LikeTheSalad

docs/reference/edot-sdks/android/automatic-instrumentation.md

@@ -17,7 +17,7 @@ mapped_pages:
 
 # Automatic instrumentation
 
-The SDK can automatically generate telemetry on your behalf. This allows you to get telemetry data for supported targets without having to write [manual instrumentation](manual-instrumentation.md).
+EDOT Android can automatically generate telemetry on your behalf. This allows you to get telemetry data for supported targets without having to write [manual instrumentation](manual-instrumentation.md).
 
 ## Installation [supported-instrumentations-installation]
 
@@ -27,9 +27,9 @@ To install a supported automatic instrumentation, follow these steps:
 
 1. Choose a [supported instrumentation](#supported-instrumentations).
 2. Add its Gradle plugin to your project in the same location where the [agent](getting-started.md#gradle-setup) is added.
-3. [Initialize the agent](getting-started.md#agent-setup) the same way you would without using automatic instrumentation.
+3. [Initialize EDOT Android](getting-started.md#agent-setup) the same way you would without using automatic instrumentation.
 
-Automatic instrumentations will get installed during the SDK initialization.
+Automatic instrumentations will get installed during EDOT Android's initialization.
 
 ```{tip}
 You can also use instrumentations from [OpenTelemetry Android](https://github.com/open-telemetry/opentelemetry-android/tree/main/instrumentation) through the [OTel Android instrumentation adapter](#adapter-for-otel-android-instrumentations).
@@ -39,7 +39,7 @@ You can also use instrumentations from [OpenTelemetry Android](https://github.co
 
 Some automatic instrumentations perform bytecode instrumentation, also known as _bytecode weaving_, where your application's code, including code from the libraries it uses, is modified at compile-time. This is similar to what `isMinifyEnabled` does with R8 functionalities, automating code changes that you would otherwise need to make manually. 
 
-Bytecode instrumentation is a common technique which may already be used in your project for use cases such as [code optimization](https://developer.android.com/build/shrink-code#optimization) through R8. While useful, bytecode instrumentation can make compilation take longer to complete. Because of this, the agent provides [a way to exclude](#automatic-instrumentation-configuration) specific build types in your app from byte code changes.
+Bytecode instrumentation is a common technique which may already be used in your project for use cases such as [code optimization](https://developer.android.com/build/shrink-code#optimization) through R8. While useful, bytecode instrumentation can make compilation take longer to complete. Because of this, EDOT Android provides [a way to exclude](#automatic-instrumentation-configuration) specific build types in your app from byte code changes.
 
 ## Configuration [automatic-instrumentation-configuration]
 
@@ -128,4 +128,4 @@ dependencies {  // <2>
 
 1. Make sure the adapter is added.
 2. You can find the dependencies needed in the [instrumentation's README file](https://github.com/open-telemetry/opentelemetry-android/tree/main/instrumentation/httpurlconnection#project-dependencies). The same will be the case for any other instrumentation.
-3. The instrumentations that require a `byteBuddy` dependency, do bytecode weaving, as explained in [compilation behavior](#compilation-behavior). An extra plugin named `net.bytebuddy.byte-buddy-gradle-plugin` is required to make this work, as shown [here](https://github.com/open-telemetry/opentelemetry-android/tree/main/instrumentation/httpurlconnection#byte-buddy-compilation-plugin). However, the EDOT agent installs this extra plugin on your behalf, so there's no need for you to do so manually.
+3. The instrumentations that require a `byteBuddy` dependency, do bytecode weaving, as explained in [compilation behavior](#compilation-behavior). An extra plugin named `net.bytebuddy.byte-buddy-gradle-plugin` is required to make this work, as shown [here](https://github.com/open-telemetry/opentelemetry-android/tree/main/instrumentation/httpurlconnection#byte-buddy-compilation-plugin). However, EDOT Android installs this extra plugin on your behalf, so there's no need for you to do so manually.

docs/reference/edot-sdks/android/configuration.md

@@ -17,11 +17,11 @@ mapped_pages:
 
 # Configure the EDOT Android SDK [configuration]
 
-This section contains a comprehensive list of all the configurable parameters available for the SDK, including those you can set during initialization and those you can adjust dynamically afterward.
+This section contains a comprehensive list of all the configurable parameters available for EDOT Android, including those you can set during initialization and those you can adjust dynamically afterward.
 
 ## Initialization configuration 
 
-Initialization configuration is available from the SDK builder shown in [Agent setup](getting-started.md#agent-setup). The following are its available parameters.
+Initialization configuration is available from the EDOT Android builder shown in [Agent setup](getting-started.md#agent-setup). The following are its available parameters.
 
 ### Application metadata
 
@@ -150,7 +150,7 @@ class MyApp : android.app.Application {
 
 ### Intercept resources
 
-The agent creates a [resource](https://opentelemetry.io/docs/specs/otel/overview/#resources) for your signals, which is a set of static global attributes. These attributes help {{kib}} properly display your application's data.
+EDOT Android creates a [resource](https://opentelemetry.io/docs/specs/otel/overview/#resources) for your signals, which is a set of static global attributes. These attributes help {{kib}} properly display your application's data.
 
 You can intercept these resources and read or modify them as shown in the following example.
 
@@ -173,7 +173,7 @@ The resource interceptor is only applied during initialization, as this is the o
 
 ### Intercept exporters
 
-The SDK configures exporters for each signal ([spans](https://opentelemetry.io/docs/languages/java/sdk/#spanexporter), [logs](https://opentelemetry.io/docs/languages/java/sdk/#logrecordexporter), and [metrics](https://opentelemetry.io/docs/languages/java/sdk/#metricexporter)) to manage features like [disk buffering](index.md#disk-buffering) and also to establish a connection with the Elastic export endpoint based on the provided [export connectivity](#export-connectivity) values.
+EDOT Android configures exporters for each signal ([spans](https://opentelemetry.io/docs/languages/java/sdk/#spanexporter), [logs](https://opentelemetry.io/docs/languages/java/sdk/#logrecordexporter), and [metrics](https://opentelemetry.io/docs/languages/java/sdk/#metricexporter)) to manage features like [disk buffering](index.md#disk-buffering) and also to establish a connection with the Elastic export endpoint based on the provided [export connectivity](#export-connectivity) values.
 
 You can intercept exporters to add your own logic, such as logging each signal that gets exported, or filtering some items that don't make sense for you to export. For example:
 
@@ -194,7 +194,7 @@ class MyApp : android.app.Application {
 
 ### Intercept HTTP spans
 
-This is a convenience tool to intercept HTTP-related spans. By default, the agent enhances HTTP span names to include `domain:port` when only an HTTP verb is set. This is [often the case](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name) for HTTP client span names.
+This is a convenience tool to intercept HTTP-related spans. By default, EDOT Android enhances HTTP span names to include `domain:port` when only an HTTP verb is set. This is [often the case](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name) for HTTP client span names.
 
 You can override this behavior by setting your own interceptor, or you can choose to set it to `null` to just turn it off. For example:
 
@@ -213,7 +213,7 @@ class MyApp : android.app.Application {
 
 ### Provide processors
 
-Part of the work that the agent does when configuring the OpenTelemetry SDK on your behalf is to provide processors, which are needed to delegate data to the exporters. For spans, the agent provides a [BatchSpanProcessor](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-trace/latest/io/opentelemetry/sdk/trace/export/BatchSpanProcessor.html); for logs, a [BatchLogRecordProcessor](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-logs/latest/io/opentelemetry/sdk/logs/export/BatchLogRecordProcessor.html); whereas for metrics, it's a [PeriodicMetricReader](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-metrics/latest/io/opentelemetry/sdk/metrics/export/PeriodicMetricReader.html), which is analogous to a processor.
+Part of the work that EDOT Android does when configuring the OpenTelemetry SDK on your behalf is to provide processors, which are needed to delegate data to the exporters. For spans, EDOT Android provides a [BatchSpanProcessor](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-trace/latest/io/opentelemetry/sdk/trace/export/BatchSpanProcessor.html); for logs, a [BatchLogRecordProcessor](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-logs/latest/io/opentelemetry/sdk/logs/export/BatchLogRecordProcessor.html); whereas for metrics, it's a [PeriodicMetricReader](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-metrics/latest/io/opentelemetry/sdk/metrics/export/PeriodicMetricReader.html), which is analogous to a processor.
 
 If you want to provide your own processors, you can do so by setting a custom [ProcessorFactory](https://github.com/elastic/apm-agent-android/blob/main/agent-sdk/src/main/java/co/elastic/otel/android/processors/ProcessorFactory.kt), as shown in the example:
 
@@ -235,12 +235,12 @@ The factory is called once during initialization and needs to provide a processo
 ### Internal logging policy
 
 :::{note}
-Not to be confused with OpenTelemetry's [log signals](https://opentelemetry.io/docs/concepts/signals/logs/). The internal logging policy is about the agent's internal logs that you should see in [logcat](https://developer.android.com/studio/debug/logcat) only.
+Not to be confused with OpenTelemetry's [log signals](https://opentelemetry.io/docs/concepts/signals/logs/). The internal logging policy is about EDOT Android's internal logs that you should see in [logcat](https://developer.android.com/studio/debug/logcat) only.
 :::
 
-The agent creates logs using [Android's Log](https://developer.android.com/reference/android/util/Log) type to notify about its internal events, so that you can check them out in [logcat](https://developer.android.com/studio/debug/logcat) for debugging purposes. By default, all logs are printed for a debuggable app build. However, in the case of non-debuggable builds, only logs at the `INFO` level and higher are printed.
+EDOT Android creates logs using [Android's Log](https://developer.android.com/reference/android/util/Log) type to notify about its internal events, so that you can check them out in [logcat](https://developer.android.com/studio/debug/logcat) for debugging purposes. By default, all logs are printed for a debuggable app build. However, in the case of non-debuggable builds, only logs at the `INFO` level and higher are printed.
 
-If you want to show specific logs from the agent, or even turn off logs altogether, you can do so by providing your own `LoggingPolicy` configuration. The following example shows how to allow all logs of level `WARN` and higher to be printed, whereas those lower than `WARN` are ignored.
+If you want to show specific logs from EDOT Android, or even turn off logs altogether, you can do so by providing your own `LoggingPolicy` configuration. The following example shows how to allow all logs of level `WARN` and higher to be printed, whereas those lower than `WARN` are ignored.
 
 ```kotlin
 class MyApp : android.app.Application {
@@ -289,7 +289,7 @@ Starting from version `1.2.0`, you can remotely manage the EDOT Android behavior
 
 ### Activate central configuration
 
-The remote management is turned off by default. To turn it on, provide your central configuration endpoint when initializing the agent, as shown here:
+The remote management is turned off by default. To turn it on, provide your central configuration endpoint when initializing EDOT Android, as shown here:
 
 ```kotlin
 class MyApp : android.app.Application {
@@ -314,7 +314,7 @@ You can modify the following settings for EDOT Android through the Central Confi
 
 | Setting | Central configuration name | Description | Type |
 |---------|----------------------------|-------------|------|
-| Recording | `recording` | Whether the agent should record and export telemetry or not. By default it's enabled, disabling it is effectively turning the agent off where only the central configuration polling will be performed. | Dynamic |
+| Recording | `recording` | Whether EDOT Android should record and export telemetry or not. By default it's enabled, disabling it is effectively turning EDOT Android off where only the central configuration polling will be performed. | Dynamic |
 | Session sample rate | `session_sample_rate` | To reduce overhead and storage requirements, you can set the sample rate to a value between 0.0 and 1.0. Data will be sampled per session, this is so context in a given session isn't lost. | Dynamic |
 
 Dynamic settings can be changed without having to restart the application.
@@ -356,7 +356,7 @@ You've properly created build config fields from environment variables. To use t
 
 ### Provide data from a properties file
 
-[Properties](https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html) are a common way to provide values to JVM apps through files. Here's an example of how you could use them to provide config values to the agent.
+[Properties](https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html) are a common way to provide values to JVM apps through files. Here's an example of how you could use them to provide config values to EDOT Android.
 
 Given the following example properties file:
 

docs/reference/edot-sdks/android/getting-started.md

@@ -66,7 +66,7 @@ If you'd like to provide these values from outside of your code, using an enviro
 
 ## Start sending telemetry
 
-With the SDK fully initialized, you can start sending telemetry to your {{stack}}.
+With EDOT Android fully initialized, you can start sending telemetry to your {{stack}}.
 
 ### Generate telemetry
 
@@ -116,8 +116,8 @@ After clicking on the span, you should see it in detail.
 
 ## What’s next? [whats-next]
 
-- This guide uses the minimum configuration options needed to initialize the agent. If you'd like to explore what else you can customize, take a look at the [configuration page](configuration.md).
+- This guide uses the minimum configuration options needed to initialize EDOT Android. If you'd like to explore what else you can customize, take a look at the [configuration page](configuration.md).
 
-- In the example, you've manually sent a span, so you've created some [manual instrumentation](manual-instrumentation.md) for your app. While this is helpful and flexible, the agent can also create automatic instrumentations. This means that by simply initializing the agent, it will start sending telemetry data on your behalf without you having to write code. For more details, refer to [Automatic instrumentation](automatic-instrumentation.md).
+- In the example, you've manually sent a span, so you've created some [manual instrumentation](manual-instrumentation.md) for your app. While this is helpful and flexible, EDOT Android can also create automatic instrumentations. This means that by simply initializing EDOT Android, it will start sending telemetry data on your behalf without you having to write code. For more details, refer to [Automatic instrumentation](automatic-instrumentation.md).
 
 - [Spans](https://opentelemetry.io/docs/concepts/signals/traces/#spans) are a great way to measure how long some method, part of a method, or even some broader transaction that involves multiple methods takes to complete. However, spans aren't the only type of [signal](https://opentelemetry.io/docs/concepts/signals/) that you can send using the agent. You can send [logs](https://opentelemetry.io/docs/concepts/signals/logs/) and [metrics](https://opentelemetry.io/docs/concepts/signals/metrics/) too! For more details, refer to [Manual instrumentation](manual-instrumentation.md).