prepare 5.0.4 release #235
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…t collision handling nor testing.
**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.
…v Attributes to be more consistent and user friendly.
…/sdk/android/LDUtilTest.java Co-authored-by: Matthew M. Keeler <[email protected]>
#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.
…appropriately. (#312) **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 Reproduced the issue and verified it was fixed when fix applied. No change was made to underlying thread creation/priority, so I don't think extensive platform testing is necessary. **Related issues** #234 **Describe the solution you've provided** // This code originally created a one-shot thread for shutting down the event source, but at some point // an Executor was introduced. A thread leak bug was introduced with that Executor because the Executor // was not cleaned up. The thread leak bug was brought to our attention in // #234 . Over time, the code evolved to no longer // need the Executor to be long lived. Reverting to the one-shot thread approach is sufficient to address // the bug. A more appropriate fix would be to refactor/unify the various task executors in the code base // and pass one of those executors in to be used for this purpose. That refactoring is not without risk and // will be reserved for a future major version. **Additional context** Bug was introduced back here: launchdarkly/android-client-sdk-private@37dc435
keelerm84
approved these changes
Feb 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[5.0.4] - 2024-02-27
Fixed: