I recently saw a post from GrapheneOS about plans to replace or overhaul the user facing applications. This is great news and I'd like to curate some resources and ideas and start a discussion on this topic.

1. Criteria

The first question I have would be what the criteria is for new applications to be included in GrapheneOS. Here are some things I think to be relevant.

1.1 License

Since one of GrapheneOS's goals is to collaborate with OEMs to offer secure products including locked down devices, certain copyleft licenses that prohibit this, like GPLv3 / LGPLv3 cannot be included in the project. Permissive licenses like MIT / Apache 2.0 are preferred. GrapheneOS uses the MIT license for their own standalone projects.

1.2 Architecture

I assume applications written in Kotlin using Jetpack Compose for the UI are preferred, because of the language advantages and since Compose is the easiest way to build Material Design 3 UI. It's also the preferred toolkit on Android going forward so I expect projects using it to see a higher amount of contributions.

1.3 Privacy & Security

Somebody more knowledgeable on this topic than me might want to comment on this, but here are some things to consider:

  • minimal permissions
  • no proprietary libraries (obviously)
  • additional privacy features (e.g. encryption, screen lock, etc.)

2. Approach

The next question is how to approach this. I see four possible approaches to modernize the user facing applications on GrapheneOS:

(lowest to highest effort)

  1. Replacing the AOSP apps with existing projects that fit the criteria
  2. Overhauling the UI of the AOSP apps
  3. Migrating the AOSP apps to Kotlin and rewriting the UI with Compose
  4. Rewriting the applications from the ground up

Personally I think the most viable approach is a mix of 1 and 2. Looking out for projects that fulfill the requirements and overhauling the rest of the applications seems like the path of least resistance to me.

3. Interesting projects

I searched every repository and list I could find for applications that fit the criteria. Unfortunately the vast majority of newer open-source android projects are GPLv3 licensed. Here are some exceptions. All of them are written in Kotlin and Jetpack Compose using Material Design 3:

Gallery

Gallery is a light-weight media gallery licensed under the Apache-2.0 license.

The AOSP gallery app has an especially dated and user unfriendly UI and there already exists an issue for replacing it. I think this application is currently the best candidate. It's pretty much feature complete and has a modern, user friendly interface.

Florisboard

Florisboard is a popular privacy focused keyboard licenced under the Apache-2.0 license.

GrapheneOS was planing to replace the AOSP keyboard with Florisboard and even contributed Direct Boot support to the project. Unfortunately Florisboard then added the Nuspell library for spellchecking, which is licensed under LGPLv3 and therefore these plans were abandoned. However Florisboard has since removed Nuspell and is working on native implementations for predictive text, spell checking and glide typing in Rust. When these features are implemented the project would be the best option for GrapheneOS since it has direct boot support, is very reliable, fixes many issues of the AOSP keyboard and offers a modern UI.

I see these projects brought up in related discussions a lot, lets quickly go over why they can't be considered:

Fossify

Fossify, formerly Simple Mobile Tools is a suite of basic open-source applications.

Most of these apps are based on AOSP applications that have been migrated to Kotlin. However they still have a pretty dated, XML based UI. Also they are licensed under GPLv3 and can't be included.

You Apps

You Apps is a suite of modern, privacy focused, open-source applications.

All apps are written from scratch in Kotlin using Jetpack Compose and have Material Design 3 UI. I have contributed and helped to maintain these projects, though I haven't been able to work on them for a while now. These would be a great fit for GrapheneOS but they also use the GPLv3 license and are therefore off the table as well.

Overhauling AOSP apps

LineageOS

LineageOS has gone with option 2 and overhauled the AOSP apps in their latest release. They still have the same Java code base and use XML, but the UI has been redesigned and now supports Material Design 3 and dynamic accent colors. The license has not changed from Apache-2.0.

I think it makes a lot of sense to bring these UI changes over to GrapheneOS either by forking the applications or picking up the UI related patches. Is there anything about LineageOS or their applications that would prevent this? Otherwise this seems like the most pragmatic approach by far.

AOSP Clock

The AOSP Team has migrated a couple of the apps to Kotlin, including the Clock. So if option 3 is preferred, the Clock would be a good starting point since the Kotlin migration is already done.

4. Additional questions / ideas

If anyone knows additional projects that could be interesting let me know and I'll add them to the list. To the GrapheneOS Team, are there already concrete plans on how the proceed with this and if so, how can I contribute towards them?

    Hi there, and thanks for your insightful and detailed post.

    In time, you might very well get a more detailed response here from another moderator, but I just want to say that the GrapheneOS development team is not particularly active on this forum. This forum is more orientated around the user base.

    Most of the development work goes on on GitHub, and you can absolutely find the developers there: https://github.com/GrapheneOS.

    But as it seems you are looking to discuss this directly with the GrapheneOS project itself, I would suggest either an email to the project https://grapheneos.org/contact#contacting-the-project, or raising it in the development chatroom accessible over Matrix/Discord/Telegram: https://grapheneos.org/contact#community-chat.

    You mentioned that you are looking to support the app development at GrapheneOS. Are you interested to work for them? If so, you might care to look at the hiring page of the GrapheneOS website: https://grapheneos.org/hiring, to see what the expectations would be.

    Note that this information is provided in my capacity as a moderator of the GrapheneOS community (forum and chatrooms): I do that as a volunteer, and opinions are my own.

    Moonji
    Good overview and, I think, generally in line with the team at GrapheneOS.

    Along with what you mention we are looking for good app functionality and code quality. Also that there are people available to maintain the app going forward.

    Although its more modern, using compose, rather than view is not important as compose comes with some of its own problems.

    Theres still some debates over replacing or modernizing different apps, if there are existing apps that may be suitable etc.

    Theres many things to consider before we can make a firm decision on what best to do for each app. There is also the availability of team members to work on this. Whether its writing code, reviewing code, testing, negotiating with existing projects etc. Whatever path is taken will involve significant efforts from us.

    We always have lots of things we are actively working on and lots of work planned. Replacing or improving the AOSP apps is something thats often discussed but is not currently a top priority. It is something we would like to do soon and we have already spent a fair amount of time exploring various options - again code review, app testing and negotiations.

    We are actively recruiting more developers and are open to collaborating on existing apps if the fit is right.

    At some point all the necessary factors will fall into place for us to be able to start work on improving or replacing one or some of these apps.

    Most of these apps provide functionality that is required to pass the Compatibility Test Suite (CTS). Except for a few tests that we fail due to security or privacy features we aim to comply with CTS. CTS requires operating systems to handle various intents which GrapheneOS relies on AOSP apps to provide. Many third party apps rely on these intents. We have to provide alternative apps that handle these intents if the AOSP apps will be removed.

    eg. You can see all the various intents that Gallery handles listed in its manifest
    https://github.com/GrapheneOS/platform_packages_apps_Gallery2/blob/14/AndroidManifest.xml

      • [deleted]

      • Edited

      I would like to put a spotlight on Aves Gallery. It has good code quality, very friendly UI, exceptional UX, and a fair amount of features. I'd recommend the dev team to consider looking into it if they havent already, as it would be a shame to miss.

        • [deleted]

        • Edited

        I understand that this is an important feature to expect for some people from a core app.
        I never cared about it or known its missing this.

        Carlos-Anso
        Thanks for going more into detail on the requirements. Taking these additions into consideration, the LineageOS applications definitely seem like the best candidates in most of the cases. Since they are continuations of the AOSP applications they should handle all the intents like before. And because they are tied to the OS I have confidence in them being actively maintained for a long time. Also with Google continuing the tear down the AOSP project by deprecating the Dialer and Messaging apps a collaboration between projects would be beneficial in keep these apps alive.

        Moonji

        Since one of GrapheneOS's goals is to collaborate with OEMs to offer secure products including locked down devices, certain copyleft licenses that prohibit this, like GPLv3 / LGPLv3 cannot be included in the project.

        Can you explain how copyleft licences prohibit "offering secure products including locked down devices"?


          • Edited

          studog Can you explain how copyleft licences prohibit "offering secure products including locked down devices"?

          I am not a lawyer, but at a high level the GPL requires that the user of a device be able to modify the source code to make the device do different things. If the device is locked down, that is not possible.

          https://en.m.wikipedia.org/wiki/Tivoization

            studog
            Like it's stated in the article @de0u linked, the GPLv3 license was specifically developed to prevent usage of the licensed software in locked down devices. You can also refer to this thread about the license issues with Florisboard.

              Hello, in terms of perimeter of the OS apps, are the clock and the calculator indispensable ? I would rather have the perimeter limited to what is actually needed for the system to run. Users can add whatever apps they prefer.

                de0u

                I am familiar with Tivoization. It doesn't apply at the user app level though. Even a locked down device can install user apps, and, if that's a user app that has been compiled from source (with a GPLv3 licence) with some changes I made, I can and should be able to install that.

                Maybe I'm not understanding what you mean by "locked down"?

                Moonji

                I read the thread, it doesn't enlighten me. I think I might have a different idea than GrapheneOS of what "locked down" means.

                  Eirikr70

                  Automatic transmission isn't required for a car to run, but many people won't buy a car without it.


                  I'd say calculator and clock are required apps. Calculating is the very heart of what computers do after all.

                  studog
                  From my understanding the problem is the following: If a part of the OS like the keyboard application is licensed under GPLv3, an OEM that wants to ship their device with GrapheneOS could face legal trouble if they lock it down, since that would violate the license of that part of the code. Since GrapheneOS wants to make it possible for OEM to make locked down devices with Graphene and make it as easy as possible at that, they can't include GPLv3 licensed code. Of course you can install GPLv3 licensed software afterwards, but what ships with the OS needs to be permissively licensed.

                    Eirikr70
                    There was a pretty heated discussion about this on here, but unfortunately I can't find it. However I don't think the set of default applications will change or should change. GOS is very serous about offering a secure way to their users to obtain software, like they've demonstrated recently by including a mirror of the Accrescent Store. Providing them with a basic set of apps, so they don't have to install them from other places like F-Droid should go along with that. However I can understand that the current set of applications is not ideal. That's why I started this discussion after all. If you don't like the Clock / Calculator apps, you can just disable them and they will not take up any storage.

                    Moonji

                    This is still a bit of hand-waving, I think. Let me try to clarify.

                    GOS ships with a keyboard (as a specific example), that's licenced GPLv3. That means end users can request the keyboard source (which is open source due to GPLv3), make some modifications, compile their own version, then load that APK (however they do that), and then run their modified keyboard instead of the shipped keyboard.

                    If "locked down" means "can't install any user-space apps", then yes, GPLv3 is an issue.
                    If "locked down" means "can install user-space apps", then I don't see how the GPLv3 is a problem in the above sequence.

                    Edit: I'm not trying to argue GOS' decision on this, only trying to understand something that others understand that I do not.

                    studog Even a locked down device can install user apps [...]

                    That assumes a very specific notion of "locked down"!

                    One example I have seen raised in the past is a security camera. For some people, being able to buy a security camera where none of the software (not kernel code, not user-space code) can be replaced would be attractive, because then it is possible to believe that remote threat actors can't invisibly replace the software.

                    It is true that a device with a locked-down OS that allowed free installation of apps would not be a "Tivoization" problem, but a device with a locked-down OS and a fixed, unchangeable set of apps would be.

                    Regardless, I believe that the GrapheneOS project has been opposed to any GPLv3 code, and, I believe, to adding any GPL'd code to user space.

                      de0u

                      Yes, I mentioned that I might not understand precisely what "locked down" means in this context.


                      A fixed unchangeable set of apps seems problematic in any circumstance, because this precludes the ability to receive security-related updates. Nonetheless, I can imagine that there is some market for this sort of "locked down".

                      • de0u replied to this.

                        studog A fixed unchangeable set of apps seems problematic in any circumstance, because this precludes the ability to receive security-related updates.

                        In the case of a $50 security camera, if the manufacturer isn't likely to issue a security update after a year, the effective security upgrade path would be replacing the device. But if the device is shipped with a path for installing additional code, that path might be abused, so it might be better to just not have such a path. For example, perhaps the manufacturer's update system requires ostensible upgrades to be signed, but the signing key is leaked (similar to Fairphone).

                        But the "Tivoization" argument isn't really about that. In the Tivo case, the device was locked down so that the company had a path for issuing upgrades but only the company could. In such a model, security upgrades from the company are not precluded. But this situation is viewed by some as intolerable, because some people want end users to be able to apply arbitrary updates to a device. This gave rise to GPLv3.

                        Overall, "locked down" doesn't have a single meaning. Some definitions of "locked down" are clearly incompatible with GPLv3, because GPLv3 was written expressly to conflict with those definitions of "locked down".

                        Meanwhile, there are multiple licenses that clearly do not conflict with any definition of "locked down".