Feature/TLS cert configuration

[brsgina]

Resolves #1475

This modification allows us to set a client TLS certificate for OtlpHttpExporters in the configuration parameter via the initialize() function.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: brsgina / name: BarsonyGina (08cf155, 1f6c846, 7cb20a6, aa4cfe1)

[codecov]

Codecov Report

❌ Patch coverage is 80.32787% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.23%. Comparing base (89c36e2) to head (7cb20a6).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
...metry/android/agent/OpenTelemetryRumInitializer.kt	64.70%	6 Missing and 6 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1660      +/-   ##
==========================================
+ Coverage   61.92%   62.23%   +0.31%     
==========================================
  Files         159      160       +1     
  Lines        3409     3440      +31     
  Branches      345      348       +3     
==========================================
+ Hits         2111     2141      +30     
+ Misses       1204     1202       -2     
- Partials       94       97       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marandaneto]

This is a serious security issue. APKs are trivially decompilable (e.g., apktool, jadx), so anyone can extract the
private key and impersonate your client

where are you reading this info from? hardcoded or read at runtime from keystore?

[brsgina]

@marandaneto We are aware of the risks of embedding secrets in the APK. The endpoint is protected with mutual TLS (mTLS), so client authentication is based on a certificate, not just a static key.

The private key is stored in the Android Keystore and is not directly extractable. The app never exposes the raw key material; it is only used via the secure hardware-backed keystore APIs.

Additionally, even if someone decompiles the APK, they cannot simply impersonate the client without access to the keystore-protected private key and a valid device context.
Of course, we understand that mobile environments cannot be considered fully secure, so mTLS is combined with additional server-side checks and monitoring.

[breedx-splk]

I like this. I had a few small suggestions, and I do feel like we should definitely try to flag this as incubating. Thanks for the contribution!

[breedx-splk]

This is a serious security issue. APKs are trivially decompilable (e.g., apktool, jadx), so anyone can extract the private key and impersonate your client

where are you reading this info from? hardcoded or read at runtime from keystore?

I think this will virtually always be the case....but this makes it significantly more difficult.

[breedx-splk]

LGTM thanks!

[fractalwrench]

LGTM

[fractalwrench]

My general preference would be for interfaces rather than classes in public APIs, as it avoids exposing <init> functions publicly and also tends to allow for more flexibility if we ever want to switch out a specific implementation for another. That feedback isn't blocking however.