-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix part of #4410, #4300, #2432: Create dedicated alpha application component #4414
Fix part of #4410, #4300, #2432: Create dedicated alpha application component #4414
Conversation
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. |
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. |
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. |
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. |
## 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.
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.