|Kainalu Hagiwara 379c35e4c0||1 year ago|
|.github||1 year ago|
|app||1 year ago|
|automation||1 year ago|
|buildSrc||1 year ago|
|certificates||2 years ago|
|config||1 year ago|
|docs||1 year ago|
|fastlane||1 year ago|
|gradle/wrapper||1 year ago|
|mozilla-detekt-rules||1 year ago|
|mozilla-lint-rules||1 year ago|
|taskcluster||1 year ago|
|.adjust_token||2 years ago|
|.cron.yml||1 year ago|
|.editorconfig||2 years ago|
|.gitattributes||2 years ago|
|.gitignore||1 year ago|
|.taskcluster.yml||1 year ago|
|CODE_OF_CONDUCT.md||2 years ago|
|Gemfile||2 years ago|
|Jenkinsfile||1 year ago|
|LICENSE||2 years ago|
|README.md||1 year ago|
|build.gradle||1 year ago|
|codecov.yml||2 years ago|
|gradle.properties||2 years ago|
|gradlew||1 year ago|
|gradlew.bat||1 year ago|
|l10n.toml||1 year ago|
|settings.gradle||1 year ago|
|version.txt||1 year ago|
** Note: The team is currently experiencing heavy triage and review load, so when triaging issues, we will mainly be looking to identify S1 (high severity) issues. See our triage process here. Please be patient if you don't hear back from us immediately on your issue! **
We encourage you to participate in this open source project. We love Pull Requests, Bug Reports, ideas, (security) code reviews or any other kind of positive contribution.
Since we are a small team, however, we do not have the bandwidth to review unsolicited PRs. Please follow our Pull Request guidelines, or we may close the PR.
To make it easier to review, we have these PR requirements:
As a small team, we have to prioritize our work, and reviewing PRs takes time. We receive lots of PRs every day, so if you can keep your PRs small, it helps our small team review and merge code faster, minimizing stale code.
Keep in mind that the team is very overloaded, so PRs sometimes wait for a very long time. However this is not for lack of interest, but because we find ourselves in a constant need to prioritize certain issues/PRs over others. If you think your issue/PR is very important, try to popularize it by getting other users to comment and share their point of view.
Great! We encourage you to participate in this open source project. We love Pull Requests, Bug Reports, ideas, (security) code reviews or any other kind of positive contribution.
To make it easier to triage, we have these issue requirements:
Please keep in mind that even though a feature you have in mind may seem like a small ask, as a small team, we have to prioritize our planned work and every new feature adds complexity and maintenance and may take up design, research, marketing, product, and engineering time. We appreciate everyone’s passion but we will not be able to incorporate every feature request or even fix every bug. That being said, just because we haven't replied, doesn't mean we don't care about the issue, please be patient with our response times as we're very busy.
Before you attempt to make a contribution please read the Community Participation Guidelines.
Guide to Contributing (New contributors start here!)
Matrix: #fenix:mozilla.org channel (We're available Monday-Friday, GMT and PST working hours). Related channels:
Check out the project wiki for more information.
Localization happens on Pontoon. Please get in touch with delphine (at) mozilla (dot) com directly for more information.
Beginners! - Watch out for Issues with the "Good First Issue" label. These are easy bugs that have been left for first timers to have a go, get involved and make a positive contribution to the project!
Note: Both Android SDK and NDK are required.
git clone https://github.com/mozilla-mobile/fenix
./gradlew clean app:assembleGeckoBetaDebug
Use app:assembleGeckoNightlyDebug to build with the Gecko Nightly version instead.
If this errors out, make sure that you have an
variable pointing to the right path.
We have a lot of build variants. Each variant is composed of two flavors. One flavor is the version of Gecko to use and the other describes which app id and settings to use. Here is a description of what each means:
For accurate performance measurements, read this section!
If you want to analyze performance during local development (note: there is a non-trivial performance impact - see caveats):
forPerformanceTestvariant with local Leanplum, Adjust, & Sentry API tokens: contact the front-end perf group for access to them
forPerformanceTestis a release variant with
debuggableset to true. There are numerous performance-impacting differences between debug and release variants so we need a release variant. To profile, we also need debuggable, which is disabled on other release variants. If API tokens are not provided, the SDKs may change their behavior in non-trivial ways.
forPerformanceTest variants with API tokens already added are also available from Taskcluster.
If you want to run performance tests/benchmarks in automation or locally:
For additional context on these recommendations, see the perf build variant analysis.
Before you can install any release variants including
forPerformanceTest, you will need to sign them: see Automatically signing release builds for details.
To reduce review turn-around time, we'd like all pushes to run tests locally. We'd
recommend you use our provided pre-push hook in
Using this hook will guarantee your hook gets updated as the repository changes.
This hook tries to run as much as possible without taking too much time.
To add it on Mac/Linux, run this command from the project root:
ln -s ../../config/pre-push-recommended.sh .git/hooks/pre-push
or for Windows run this command using the Command Prompt with administrative privileges:
mklink .git\hooks\pre-push ..\..\config\pre-push-recommended.sh
or using PowerShell:
New-Item -ItemType SymbolicLink -Path .git\hooks\pre-push -Value (Resolve-Path config\pre-push-recommended.sh)
To push without running the pre-push hook (e.g. doc updates):
git push <remote> --no-verify
Note: If while pushing you encounter this error "Could not initialize class org.codehaus.groovy.runtime.InvokerHelper" and are currently on Java14 then downgrading your Java version to Java13 or lower can resolve the issue
Steps to downgrade Java Version on Mac with Brew:
sudo rm -fr /Library/Java/JavaVirtualMachines/<jdk-version>
brew tap homebrew/cask-versions
brew search java
brew install java11
You can speed up local development by setting a few helper flags available in
local.properties. Some flags will make it easy to
work across multiple layers of the dependency stack - specifically, with android-components, geckoview or application-services.
To sign your release builds with your debug key automatically, add the following to
With this line, release build variants will automatically be signed with your debug key (like debug builds), allowing them to be built and installed directly through Android Studio or the command line.
This is helpful when you're building release variants frequently, for example to test feature flags and or do performance analyses.
If you're making changes to these projects and want to test them in Fenix, auto-publication workflow is the fastest, most reliable way to do that.
local.properties, specify a relative path to your local
application-services checkouts. E.g.:
Once these flags are set, your Fenix builds will include any local modifications present in these projects.
Specify a relative path to your local
mozilla-central checkout via
and optional a path to m-c object directory via
If these are configured, local builds of GeckoView will be used instead of what's configured in Dependencies.kt. For more details, see https://firefox-source-docs.mozilla.org/mobile/android/geckoview/contributor/geckoview-quick-start.html#include-geckoview-as-a-dependency
This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/