• [deleted]

  • Post #4

matchboxbananasynergy The title suggests what he wants to uae them for, tinkering. And apologies for what I said, it was merely quoted from different source. Next time I will hold my horses trying to help, it isn't always appreciated.

      [deleted] Don't be so hard on yourself. I am always interested to read your posts and comments in this forum. I appreciate.

        matchboxbananasynergy

        That's the source for the equalizer and camera apps respectively. You have to build them from source. And they're buried amongst the other 2.5k (?!?!) repositories on LineageOS's GitHub. But if you use the search bar, you can probably find the repositories for the apps you want.

          a year later

          Reviving this thread a bit.

          LineageOS has all their apps on Github. They dont have release APKs and also use the same basic android names (like com.android.deskclock) so installing them on GrapheneOS or even stock Android does not work.

          The packagemanager tries an upgrade but fails to do so.

          To install them, you need to clone the repo and change the app ID, then build the APK. I began doing that but not successful.

          Advantages: LineageOS has made progress reviving the old stock Android apps, mainly modern Material design and likely updated libraries.

          It would be great if GrapheneOS devs could integrate these updates, as the core apps are often very outdated. But they work really good, and have some needed features like the early-boot wake of the Clock.

          What would be the requirement? Can GrapheneOS use these apps?

          I dont think they have changed the license.

          https://lineageos.org/Changelog-28/

          This changelog has good presentations of the apps. Honestly they look stunning.

          I just did another donation to GrapheneOS and encourage you to follow. Maybe if your hiring is successful, you have more people to do things like that?

          The apps really look stunning and would catapult the default user experience a ton. An OS that you can install and that looks well out of the box.

          • de0u replied to this.

            missing-root What would be the requirement? Can GrapheneOS use these apps?

            One question is the licensing of the code itself. Another question is the licensing of the "dependencies", meaning any libraries that are built into the final app. I believe the GrapheneOS developers do not wish to ship GPL'd code outside of the kernel.

            Another issue is code review -- in particular, security. I suspect somebody trusted by the GrapheneOS developers would need to go through the code of the LineageOS apps literally line by line.

            Something that might help would be inventorying currently-open issues in the GrapheneOS issue tracker to see if the LineageOS apps would address any of those issues.

            If Google suddenly ditches one or more of their stale apps, the balance might shift toward the project allocating time to look at the LineageOS apps (or apps from other distributions).

            Please note that I do not speak for the GrapheneOS project.

                missing-root It would be great if GrapheneOS devs could integrate these updates, as the core apps are often very outdated. But they work really good, and have some needed features like the early-boot wake of the Clock.

                Here I am not quite sure what is being referred to. I think the current GrapheneOS "Clock" app supports Direct Boot, at least for built-in alarm sounds.

                    11 days later

                    de0u yes the clock does, as do all other clocks based on the AOSP clock I think.

                    https://discuss.grapheneos.org/d/10436-clocks-supporting-direct-boot

                    I am purely talking about design. The old AOSP clock is extremely ugly. It also lacks some features like volume button integration, I think.

                    LineageOS also takes the AOSP apps but modernized the UI to use the current Material design. Unlike GrapheneOS, where the apps are just the old ones. Afaik.

                      de0u I think Google ditched these AOSP apps long ago. I am talking about clock, calendar, gallery, phone, sms, calculator.

                      These all use different styles, with the Gallery looking most outdated.

                      Honestly about the GPL code, if vendors want to restrict user freedoms, they can just leave out these apps.

                      I dont imagine that a proprietary OS would keep these pretty awful looking apps anyways.

                      I dont know how GrapheneOS devs manage the updates, because they look outdated, but may be updated to modern libraries.

                      I remember reading something like "these apps are old and offline, there is little risk"

                      • de0u replied to this.

                          missing-root I think Google ditched these AOSP apps long ago. I am talking about clock, calendar, gallery, phone, sms, calculator.

                          These all use different styles, with the Gallery looking most outdated.

                          Agreed.

                          I think essentially the same set of issues was discussed at the beginning of the year, e.g.: https://discuss.grapheneos.org/d/10028-discussion-and-ideas-about-preinstalled-apps/5 et seq. I am not aware that the thinking of the project leadership about various versions of the GPL has changed (another statement here).

                          Thus, with respect to the possibility of incorporating LineageOS apps into GrapheneOS, I think two key issues are that the LineageOS apps would need a line-by-line security review, and that they would need to avoid building in GPL'd libraries. The first one is hard for anybody but project leadership to evaluate, but the question of which libraries the LineageOS apps depend on, and what their licenses are, is something that could be looked into by various people.

                              de0u
                              I don't think a line-by-line review is necessary or even possible. The Clock app alone has over 30.000 Lines of code. Checking what dependencies are used, what permissions are requested and running code quality tests should be sufficient. These apps don't have internet access and since they're also AOSP based, there can be more trust in the code base than with a new third party application. As for the licenses, on a surface level it's looking good. I checked the Calculator, Contacts, Clock, Phone, Messaging, Files and Gallery apps. All of them use Apache-2.0, even their new Gallery app. The contacts app includes a .mp3 file, licensed under CC-BY-3.0, but that can just be removed. There a tools the list all dependencies and check their licenses, so this shouldn't be too big of a deal either. Looking over the changes that have been made on top of AOSP, I haven't seen changes to the dependencies yet, so I'm optimistic about it.

                                  Moonji Thanks for looking into the dependency issue. Let us know how it goes.

                                  Moonji I don't think a line-by-line review is necessary or even possible. The Clock app alone has over 30.000 Lines of code. Checking what dependencies are used, what permissions are requested and running code quality tests should be sufficient. These apps don't have internet access and since they're also AOSP based, there can be more trust in the code base than with a new third party application.

                                  I don't think "does/doesn't have Internet access" is the same as "needs/doesn't-need to be secure"! The phone and SMS/MMS apps present plenty of attack surface!

                                  Also, having at one time been part of AOSP does not provide a magical trust aura. Aside from deliberate supply-chain attacks (xz), anybody can make a mistake. For sure the AOSP code base has previously contained security bugs!