Story details: https://app.shortcut.com/launchdarkly/story/205159

…t collision handling nor testing.

…ifier

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions.

**Related issues**

[Provide links to any issues in this repository or elsewhere relating to
this pull request.

](https://app.shortcut.com/launchdarkly/story/204369/core-telemetry-in-android-sdk)

**Describe the solution you've provided**

See
https://github.com/launchdarkly/sdk-specs/blob/ta/sc-203619/auto-env-attributes-software-specs/specs/CONTEXTENVDATA-context-environment-data/ImplementationGuidance.md#object-oriented-sdks-with-persistence

**Describe alternatives you've considered**

See
https://launchdarkly.atlassian.net/wiki/spaces/PD/pages/2426306660/Mobile+Telemetry+Brainstorming+Investigation#Implementation-Ideas

This pull request was auto generated by the Launchdarkly Github
Standards automation platform.

* Add default CODEOWNERS file

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/204374/android-telemetry-add-opt-in-out-support

**Describe the solution you've provided**

Piped boolean through config and contract testing layers into LDClient's
use of context modifiers.

**Describe alternatives you've considered**

None others strongly considered, current solution is pretty much the
minimal solution.

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions.

**Related issues**


https://app.shortcut.com/launchdarkly/story/208999/android-telemetry-implement-new-os-attribute-spec

**Describe the solution you've provided**

OS Name will take the form of "Android<SDKINT>".  Example: Android21

**Describe alternatives you've considered**

Android API 23 (too wordy)
Android M (multiple ways to get the Letter code for the OS across
different API levels, not worth the difficulty to implement. Also,
they're going to run out of Letters, so seems risky over the next 5
years).

… moved locale from ld_device to ld_application

…… (#302)

… moved locale from ld_device to ld_application

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/208863/android-telemetry-stable-ld-application-key

**Describe the solution you've provided**

Updated callable of the ld_application recipe.

**Describe alternatives you've considered**

Could have done a large closure for creating each context instead of
having recipes, but there would be duplicated code related to iterating
over the attributes and handling set failures. That seemed like a big
enough con to dissuade me from doing that.

…ted code and tests.

… (#303)

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/204374/android-telemetry-add-opt-in-out-support

**Describe the solution you've provided**

In the next major version, customers must make a decision on whether to
opt in/out of env attributes. A required parameter on the LDConfig
constructor was chosen during the SDK technical discussion. The required
parameter is an enum type for extra API clarity.

**Describe alternatives you've considered**

Other ideas considered during the SDK technical discussion

a fluent builder with multiple types to control when the build()
function can be called.
alternative SDKs for the feature (possible, but high maintenance costs)

Merging feature branch into 5.x branch.

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/210352/android-add-deprecation-warnings-for-lduser-functionality

**Requirements**

- [ ] I have added test coverage for new or changed functionality
Only removing code, so not additional coverage.

- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/210354/android-remove-lduser-in-the-auto-env-branch

**Describe the solution you've provided**

Pew, pew, pewwww, pew pew.  Die LDUser, die!

…#307)

Documentation pass found one version that needed to be updated.

Just propagating into main.

…v Attributes to be more consistent and user friendly.

…/sdk/android/LDUtilTest.java

Co-authored-by: Matthew M. Keeler <keelerm84@gmail.com>

…… (#309)

Need to merge test harness changes before this will pass.

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/213112/inconsistent-applicationname-and-applicationversionname-validation

**Describe the solution you've provided**

- Added sanitization logic to application info fields where spaces are
now converted to hyphens. This is to help customers create values that
will be accepted by our cloud infrasturcture.
- Updated fallback logic to fallback to next source of application info
if the applicationID is invalid. This invalid ID would be rejected by
the cloud, so making that consistent.
- Fixing bug in hashing to calulcate ld_application key where an omitted
version would actually result in hash("myID:nil") when it should have
been hash("myID:")

**Describe alternatives you've considered**

See:
https://launchdarkly.atlassian.net/wiki/spaces/~63fb3c420d9b61193c23bde7/pages/2544828779/213112+-+Consistent+application+info+validation

We have discussed and agreed to modify the logic to not include the
version as the context key generation. We will release this as a bug fix
to make sure customers don't stuck on a version with old logic
available.

…… (#311)

… condition

**Requirements**

- [ ] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [ ] I have validated my changes against all supported platform
versions

**Related issues**


https://app.shortcut.com/launchdarkly/story/229919/support-58536-crash-initializing-android-sdk

**Describe the solution you've provided**

Root cause of crash is that multiple calls to update from different
sources can cause a event source to be stopped just before start is
called on the event source. This results in the event source being in a
bad state, leading to the crash. The fix is to only allow one thread
into the updateDataSource block at a time by making it synchronized.

**Describe alternatives you've considered**

Also considered updating the event source to silently ignore the request
to start again after it has been stopped. I prefer code less
permissive/lenient code in this case since we really should know exactly
when we are starting and stopping eventsources.