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]

      • Post #4
      • 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]

        • Post #7
        • 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"?


              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".