fenix

⚠️ Fenix (Firefox for Android) moved to a new repository. It is now developed and maintained as part of: https://github.com/mozilla-mobile/firefox-android

6,465

1,272

6,465

View on GitHub

Top Related Projects

brave-browser

17,709

Brave browser for Android, iOS, Linux, macOS, Windows.

src

2,751

Source-code used in Kiwi Browser for Android

bromite

5,836

Bromite is a Chromium fork with ad blocking and privacy enhancements; take back your browser!

Quick Overview

Mozilla-mobile/fenix is the repository for Firefox for Android, a modern and feature-rich mobile browser. It's built using Kotlin and follows Mozilla's commitment to privacy and open-source development, offering users a fast, secure, and customizable browsing experience on Android devices.

Pros

Open-source development, allowing for community contributions and transparency
Strong focus on privacy and security features
Highly customizable user interface and browsing experience
Regular updates and active development from Mozilla

Cons

May have a smaller user base compared to some other mobile browsers
Some users report occasional stability issues or bugs
Limited extension support compared to desktop Firefox
Performance can vary depending on device specifications

Getting Started

To contribute to the Fenix project:

Fork the repository on GitHub
Clone your fork: git clone https://github.com/your-username/fenix.git
Set up the development environment following the instructions in the CONTRIBUTING.md file
Make your changes and submit a pull request for review

For users, simply download Firefox for Android from the Google Play Store or F-Droid to start using the browser.

Competitor Comparisons

brave-browser

17,709

Brave browser for Android, iOS, Linux, macOS, Windows.

Pros of Brave

Built-in ad and tracker blocking, offering enhanced privacy out-of-the-box
Integrated cryptocurrency wallet and rewards system
More extensive customization options for users

Cons of Brave

Larger codebase, potentially leading to more complex maintenance
Less frequent updates compared to Fenix
Some features may be considered bloat by users seeking a simpler browser

Code Comparison

Fenix (Kotlin):

class BrowserFragment : BaseBrowserFragment(), UserInteractionHandler {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        return inflater.inflate(R.layout.fragment_browser, container, false)
    }
}

Brave (C++):

class BraveBrowserProcess : public BrowserProcess {
 public:
  BraveBrowserProcess(StartupData* startup_data);
  ~BraveBrowserProcess() override;

  void StartBrowserProcessImpl() override;
};

Both repositories use different primary languages (Kotlin for Fenix, C++ for Brave) reflecting their distinct architectures. Fenix focuses on a mobile-first approach with a more streamlined codebase, while Brave offers a feature-rich desktop and mobile browser with additional privacy and cryptocurrency features. The code snippets demonstrate the different approaches to implementing core browser functionality in their respective languages and frameworks.

Android

3,759

DuckDuckGo Android App

Pros of DuckDuckGo Android

Stronger focus on privacy and tracking prevention
Simpler, more streamlined user interface
Faster initial load times and lower resource usage

Cons of DuckDuckGo Android

Less customization options compared to Fenix
Smaller developer community and ecosystem
Limited integration with third-party services

Code Comparison

Fenix (Kotlin):

class BrowserFragment : BaseBrowserFragment(), UserInteractionHandler {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return inflater.inflate(R.layout.fragment_browser, container, false)
    }
}

DuckDuckGo Android (Java):

public class BrowserFragment extends Fragment {
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        View rootView = inflater.inflate(R.layout.fragment_browser, container, false);
        return rootView;
    }
}

Both projects use similar fragment-based architectures, but Fenix is written in Kotlin while DuckDuckGo Android primarily uses Java. Fenix's codebase tends to be more concise due to Kotlin's features, while DuckDuckGo Android's Java code is more verbose but potentially more familiar to some developers.

src

2,751

Source-code used in Kiwi Browser for Android

Pros of Kiwi Browser

More customizable and extensible, allowing for greater user control
Supports Chrome extensions, providing a wider range of add-ons
Focuses on privacy features and ad-blocking capabilities

Cons of Kiwi Browser

Smaller development team, potentially slower updates and bug fixes
Less frequent releases compared to Fenix
May have compatibility issues with some websites due to modifications

Code Comparison

Fenix (Kotlin):

class BrowserFragment : Fragment() {
    private lateinit var browserToolbarView: BrowserToolbarView
    private lateinit var engineView: EngineView
    // ...
}

Kiwi Browser (C++):

class BrowserView : public views::WebView {
 public:
  BrowserView(Browser* browser, BrowserViewLayout* layout);
  // ...
};

The code snippets show different approaches to implementing browser views. Fenix uses Kotlin and a fragment-based structure, while Kiwi Browser uses C++ and a custom view class. This reflects the different architectures and languages used in each project.

bromite

5,836

Bromite is a Chromium fork with ad blocking and privacy enhancements; take back your browser!

Pros of Bromite

Enhanced privacy features, including built-in ad blocking and fingerprinting protection
Chromium-based, offering better compatibility with modern web standards
Regular security updates and patches

Cons of Bromite

Smaller development team, potentially slower feature implementation
Limited to Android platform, not available for iOS or desktop
Less extensive customization options compared to Fenix

Code Comparison

Bromite (AdBlocker implementation):

public class AdBlocker {
    private static final String AD_HOSTS_FILE = "hosts.txt";
    private static final Set<String> AD_HOSTS = new HashSet<>();

    static {
        loadAdHosts();
    }
}

Fenix (Tracking Protection implementation):

class TrackingProtectionPolicy(
    val cookiePolicy: CookiePolicy = ACCEPT_NON_TRACKERS,
    val strictSocialTrackingProtection: Boolean = false,
    val useForPrivateSessions: Boolean = false,
    val useForRegularSessions: Boolean = false
)

Both projects implement privacy-enhancing features, but their approaches differ. Bromite focuses on ad blocking using a hosts file, while Fenix employs a more comprehensive tracking protection policy. Fenix's implementation is more flexible, allowing for different policies in private and regular browsing sessions.

Etar-Calendar

2,017

Android open source calendar

Pros of Etar-Calendar

Lightweight and focused solely on calendar functionality
Open-source and privacy-oriented, with no tracking or data collection
Simple and intuitive user interface

Cons of Etar-Calendar

Limited features compared to more comprehensive mobile browsers
Smaller community and less frequent updates
Lacks integration with other services or extensions

Code Comparison

Etar-Calendar (Java):

public class Event implements Parcelable, Cloneable {
    private long mId;
    private int mCalendarId;
    private String mTitle;
    private String mDescription;
    private String mEventLocation;

Fenix (Kotlin):

class TabSessionState(
    val id: String,
    val content: ContentState,
    val trackingProtection: TrackingProtectionState = TrackingProtectionState(),
    val engineState: EngineState = EngineState(),
    val extensionState: Map<String, WebExtensionState> = emptyMap(),

The code snippets show that Etar-Calendar focuses on event management with properties like title, description, and location. In contrast, Fenix deals with browser-specific concepts such as tab sessions, content states, and tracking protection.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

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

Performance Build Variants

For accurate performance measurements, read this section!

To analyze performance during local development build a production variant locally (this could either be the Nightly, beta or release). Otherwise, you could also grab a pre-existing APK if you don't need to test some local changes. Then, use the Firefox profiler to profile what you need!

For more information on how to use the profiler or how to use the build, refer to this how to measure performance with the build

If you want to run performance tests/benchmarks in automation or locally use a production build since it is much closer in behavior compared to what users see in the wild.

Before you can install any release builds, You will need to sign production build variants: see Automatically signing release builds for details.

Known disabled-by-default features

Some features are disabled by default when Fenix is built locally. This can be problematic at times for checking performance since you might want to know how your code behaves with those features. The known features that are disabled by default are:

Sentry
Adjust
Mozilla Location Services (also known as MLS)
Firebase Push Services
Telemetry (only disabled by default in debug builds)
Nimbus

Pre-push hooks

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 config/pre-push-recommended.sh. 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.

Before you can run the hook, you'll need to configure Java properly because it relies on command line tools: see our how-to guide.

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:

Install Homebrew (https://brew.sh/)
run brew update
To uninstall your current java version, run sudo rm -fr /Library/Java/JavaVirtualMachines/<jdk-version>
run brew tap homebrew/cask-versions
run brew search java
If you see java11, then run brew install java11
Verify java-version by running java -version

local.properties helpers

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.

Automatically sign release builds

To sign your release builds with your debug key automatically, add the following to <proj-root>/local.properties:

autosignReleaseWithDebugKey

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.

Building debuggable release variants

Nightly, Beta and Release variants are getting published to Google Play and therefore are not debuggable. To locally create debuggable builds of those variants, add the following to <proj-root>/local.properties:

debuggable

Setting raptor manifest flag

To set the raptor manifest flag in Nightly, Beta and Release variants, add the following to <proj-root>/local.properties:

raptorEnabled

Auto-publication workflow for android-components and application-services

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.

In local.properties, specify a relative path to your local android-components and/or application-services projects. E.g.:

autoPublish.android-components.dir=../firefox-android/android-components
autoPublish.application-services.dir=../application-services

Note that the Android Components project was already migrated to the new firefox-android repository. Therefore, this auto publication workflow won't be neccessary for Android Components once Fenix is integrated in the new repository as well.

Once these flags are set, your Fenix builds will include any local modifications present in these projects.

See a demo of auto-publication workflow in action.

In order to build successfully, you need to check out a commit in the dependency repository that has no breaking changes. The two best ways to do this are:

Run the <android-components>/tools/list_compatible_dependency_versions.py script to output a compatible commit
Check out the latest commit from main in this repository and the dependency repository. However, this may fail if there were breaking changes added recently to the dependency.

If you're trying to build fenix with a local ac AND a local GV, you'll have to use another method: see this doc.

Using Nimbus servers during local development

If you're working with the Nimbus experiments platform, by default for local development Fenix configures Nimbus to not use a server.

If you wish to use a Nimbus server during local development, you can add a https:// or file:// endpoint to the local.properties file.

nimbus.remote-settings.url

Testing experimental branches should be possible without a server.

Using custom Glean servers during local development

If you wish to use a custom Glean server during local development, you can add a https:// endpoint to the local.properties file.

glean.custom.server.url

GeckoView

Specify a relative path to your local mozilla-central checkout via dependencySubstitutions.geckoviewTopsrcdir, and optional a path to m-c object directory via dependencySubstitutions.geckoviewTopobjdir.

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

See notes on building successfully in the android-components auto-publication section.

License

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/

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot