Fix part of #4410, #4300, #2432: Create dedicated alpha application component #4414
Conversation
This file contains 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
This simplifies application component management significantly and allows individual build flavors to have their own unique module lists.
|
Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue. |
oppiabot
bot
added
the
stale
oppiabot
bot
removed
the
stale
|
Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue. |
oppiabot
bot
added
the
stale
oppiabot
bot
removed
the
stale
|
Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue. |
oppiabot
bot
added
stale
|
Force-merging this due to the time sensitivity of the release for which it's tied. I've review the PR myself, but I'll make sure it's reviewed post-merge. |
6 tasks
BenHenning
added a commit
that referenced
this pull request
Aug 19, 2022
## Explanation Fixes #4410 This PR builds on #4414 by introducing a new alpha component that's specific to the team's ongoing research project in Kenya. This build serves three benefits: 1. It allows us to ensure end users can easily distinguish between alpha & study-specific alpha flavors of the app (since they will now have different build flavors). 2. It ensures we can explicitly version the binaries such that the study binary always takes precedence on Play Store. 3. It allows us to define study-specific parameters without needing manual changes during release (such as automatically enabling the learner study feature, which this PR is doing for the new build flavor). A few important things to note: - There are no new tests for the new components since they are mostly uninteresting to test (similar to other build flavor components). - The new components are temporary are will be reoved (#4419 is tracking this). - This PR is a recreation of #4420 since the new build flavor was being originally being introduced after the new beta & GA flavors (but this is no longer the case due to the beta release being delayed). - The new build flavor is not being added to CI build tests mainly because it's unlikely for this build to break versus the alpha build (as the two are so similar), and because of the temporary nature of this version of the app. - The new classes needed to be exempted for Gradle builds since Gradle was having difficulty with the fact that the new study-specific alpha component was a separate Dagger graph (our Gradle configuration, unlike Bazel, can't manage multiple Dagger graphs in the same build tree). This seems like a reasonable thing to do since the study-specific version of the app can't be built on Gradle, anyway. This ## Essential Checklist - [x] The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".) - [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation. - [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide). - [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)). - [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop". - [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)). ## For UI-specific PRs only This PR has no user-facing side effects except the fact that the version name is different now for the study-specific version of the app (which doesn't seem particularly important to show a video/screenshot for). Commits: * Create dedicated alpha application component. This simplifies application component management significantly and allows individual build flavors to have their own unique module lists. * Fix broken test per earlier changes. * Add Kenya study-specific alpha build flavor. This new build flavor automatically enables the study-specific learner study feature flag. Cherry-pick of eef2f4c from the original #4420. * Update build_flavors.bzl Remove beta version declaration since that doesn't belong in this branch. * Post-CP fixes. * Fix Gradle builds. * Update TransformAndroidManifestTest.kt Correct typos.
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.
Explanation
Fixes part of #4410, #4300, and #2432.
This PR refactors the existing approach for managing application-level build dependencies by splitting up OppiaApplication ApplicationComponent into two: one for the developer build, and one for alpha. The existing OppiaApplication was retrofitted to be a base abstract class for both of the flavor-specific applications, and also for the e2e test TestApplication class (which subsequently simplified that).
This has overall resulted in a decrease in complexity since it now allows us to select specific dependencies per flavor of the app which should significantly simplify ongoing release automation work, plus other flavor-specific gating that we may want to do in the future without having to rely on a human to manually enable/disable certain modules during release time.
A few other small things of note:
Essential Checklist
For UI-specific PRs only
N/A -- This is an infrastructure-only change.