fenix

Firefox for Android Fenix (internal codename) is the all-new Firefox for Android browser, based on GeckoView and Mozilla Android Components. Getting Involved Please read the Community Participation Guidelines and the Bugzilla Etiquette guidelines before filing an issue. This is our professional working environment as much as it is our bug tracker, and we want to keep our workspace clean and healthy. Guide to Contributing (New contributors start here!) Browse our current Issues, or file a security issue. Matrix: #fenix:mozilla.org channel (We're available Monday-Friday, GMT and PST working hours). Related channels: #mobile-test-eng:mozilla.org channel: for UI test automation #perf-android-frontend:mozilla.org channel: for front-end (JVM) performance of Android apps #android-tips:mozilla.org channel: for tips on Android development Check out the project wiki for more information. See our guide on Writing Custom Lint Rules. 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! I want to open a Pull Request! 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: Every PR must have exactly one issue associated with it. Write a clear explanation of what the code is doing when opening the pull request, and optionally add comments to the PR. Make sure there are tests - or ask for help on how the code should be tested in the Issue! Keep PRs small and to the point. For extra code-health changes, either file a separate issue, or make it a separate PR that can be easily reviewed. Use micro-commits. This makes it easier and faster to review. Add a screenshot for UX changes (this is part of the PR checklist) 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. I want to file an issue! 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 do your best to search for duplicate issues before filing a new issue so we can keep our issue board clean. Every issue should have exactly one bug/feature request described in it. Please do not file meta feedback list tickets as it is difficult to parse them and address their individual points. Feature Requests are better when they’re open-ended instead of demanding a specific solution -ie “I want an easier way to do X” instead of “add Y” Issues are not the place to go off topic or debate. If you have questions, please join the #fenix:mozilla.org channel. Please always remember our Community Participation Guidelines Please do not tag specific team members to try to get your issue looked at faster. We have a triage process that will tag and label issues correctly in due time. If you think an issue is very severe, you can ask about it in Matrix. 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. Build Instructions Pre-requisites: Android SDK To run command line tools, you'll need to configure Java: see our how-to guide. Clone or Download the repository: git clone https://github.com/mozilla-mobile/fenix Import the project into Android Studio or build on the command line: ./gradlew clean app:assembleDebug If this errors out, make sure that you have an ANDROID_SDK_ROOT environment variable pointing to the right path. Make sure to select the correct build variant in Android Studio. See the next section. Make sure to select "Default APK" under Installation Options inside Run/Debug configuration: see this bug. Build Variants For general development, we recommend the debug build variant. Here's an explanation of each variant: debug: the default for developers, similar to most other Android apps. It is debuggable, uses a Nightly GeckoView with debug symbols, adds tools like LeakCanary for troublingshooting, and does not strip unused code. nightly: what we ship to the Firefox Nightly channel, using GeckoView Nightly. beta: what we ship to the Firefox Beta channel, using GeckoView Beta. It is more stable than nightly. release: what we ship as Firefox for Android, using GeckoView Release. It is the most stable. nightly, beta, and release are unsigned and debuggable=false by default. If you want these variants to be: automatically signed, see Automatically signing release builds debuggable=true, see Building debuggable release variants Performanc