Related
【ROM 4.3.1【UN-OFFICIAL PURE AOSP】InsomniaAOSP【10/22/13 v.1.0】
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Open Source
What is the Android Open Source Project?
We use the phrase "Android Open Source Project" or "AOSP" to refer to the people, the processes, and the source code that make up Android.
The people oversee the project and develop the actual source code. The processes refer to the tools and procedures we use to manage the development of the software. The net result is the source code that you can use to build cell phone and other devices.
Why did we open the Android source code?
Google started the Android project in response to our own experiences launching mobile apps. We wanted to make sure that there would always be an open platform available for carriers, OEMs, and developers to use to make their innovative ideas a reality. We also wanted to make sure that there was no central point of failure, so that no single industry player could restrict or control the innovations of any other. The single most important goal of the Android Open-Source Project (AOSP) is to make sure that the open-source Android software is implemented as widely and compatibly as possible, to everyone's benefit.
You can find more information on this topic at our Project Philosophy page.
What kind of open-source project is Android?
Google oversees the development of the core Android open-source platform, and works to create robust developer and user communities. For the most part the Android source code is licensed under the permissive Apache Software License 2.0, rather than a "copyleft" license. The main reason for this is because our most important goal is widespread adoption of the software, and we believe that the ASL2.0 license best achieves that goal.
You can find more information on this topic at our Project Philosophy and Licensing pages.
Why is Google in charge of Android?
Launching a software platform is complex. Openness is vital to the long-term success of a platform, since openness is required to attract investment from developers and ensure a level playing field. However, the platform itself must also be a compelling product to end users.
That's why Google has committed the professional engineering resources necessary to ensure that Android is a fully competitive software platform. Google treats the Android project as a full-scale product development operation, and strikes the business deals necessary to make sure that great devices running Android actually make it to market.
By making sure that Android is a success with end users, we help ensure the vitality of Android as a platform, and as an open-source project. After all, who wants the source code to an unsuccessful product?
Google's goal is to ensure a successful ecosystem around Android, but no one is required to participate, of course. We opened the Android source code so anyone can modify and distribute the software to meet their own needs.
What is Google's overall strategy for Android product development?
We focus on releasing great devices into a competitive marketplace, and then incorporate the innovations and enhancements we made into the core platform, as the next version.
In practice, this means that the Android engineering team typically focuses on a small number of "flagship" devices, and develops the next version of the Android software to support those product launches. These flagship devices absorb much of the product risk and blaze a trail for the broad OEM community, who follow up with many more devices that take advantage of the new features. In this way, we make sure that the Android platform evolves according to the actual needs of real-world devices.
How is the Android software developed?
Each platform version of Android (such as 1.5, 1.6, and so on) has a corresponding branch in the open-source tree. At any given moment, the most recent such branch will be considered the "current stable" branch version. This current stable branch is the one that manufacturers port to their devices. This branch is kept suitable for release at all times.
Simultaneously, there is also a "current experimental" branch, which is where speculative contributions, such as large next-generation features, are developed. Bug fixes and other contributions can be included in the current stable branch from the experimental branch as appropriate.
Finally, Google works on the next version of the Android platform in tandem with developing a flagship device. This branch pulls in changes from the experimental and stable branches as appropriate.
You can find more information on this topic at our Branches and Releases.
Why are parts of Android developed in private?
It typically takes over a year to bring a device to market, but of course device manufacturers want to ship the latest software they can. Developers, meanwhile, don't want to have to constantly track new versions of the platform when writing apps. Both groups experience a tension between shipping products, and not wanting to fall behind.
To address this, some parts of the next version of Android including the core platform APIs are developed in a private branch. These APIs constitute the next version of Android. Our aim is to focus attention on the current stable version of the Android source code, while we create the next version of the platform as driven by flagship Android devices. This allows developers and OEMs to focus on a single version without having to track unfinished future work just to keep up. Other parts of the Android system that aren't related to application compatibility are developed in the open, however. It's our intention to move more of these parts to open development over time.
When are source code releases made?
When they are ready. Some parts of Android are developed in the open, so that source code is always available. Other parts are developed first in a private tree, and that source code is released when the next platform version is ready.
In some releases, core platform APIs will be ready far enough in advance that we can push the source code out for an early look in advance of the device's release; however in others, this isn't possible. In all cases, we release the platform source when we feel the version has stabilized enough, and when the development process permits. Releasing the source code is a fairly complex process.
What is involved in releasing the source code for a new Android version?
Releasing the source code for a new version of the Android platform is a significant process. First, the software gets built into a system image for a device, and put through various forms of certification, including government regulatory certification for the regions the phones will be deployed. It also goes through operator testing. This is an important phase of the process, since it helps shake out a lot of software bugs.
Once the release is approved by the regulators and operators, the manufacturer begins mass producing devices, and we turn to releasing the source code.
Simultaneous to mass production the Google team kicks off several efforts to prepare the open source release. These efforts include final API changes and documentation (to reflect any changes that were made during qualification testing, for example), preparing an SDK for the new version, and launching the platform compatibility information.
Also included is a final legal sign-off to release the code into open source. Just as open source contributors are required to sign a Contributors License Agreement attesting to their IP ownership of their contribution, Google too must verify that it is clear to make contributions.
Starting at the time mass production begins, the software release process usually takes around a month, which often roughly places source code releases around the same time that the devices reach users.
How does the AOSP relate to the Android Compatibility Program?
The Android Open-Source Project maintains the Android software, and develops new versions. Since it's open-source, this software can be used for any purpose, including to ship devices that are not compatible with other devices based on the same source.
The function of the Android Compatibility Program is to define a baseline implementation of Android that is compatible with third-party apps written by developers. Devices that are "Android compatible" may participate in the Android ecosystem, including Google Play; devices that don't meet the compatibility requirements exist outside that ecosystem.
In other words, the Android Compatibility Program is how we separate "Android compatible devices" from devices that merely run derivatives of the source code. We welcome all uses of the Android source code, but only Android compatible devices -- as defined and tested by the Android Compatibility Program -- may participate in the Android ecosystem.
How can I contribute to Android?
There are a number of ways you can contribute to Android. You can report bugs, write apps for Android, or contribute source code to the Android Open-Source Project.
There are some limits on the kinds of code contributions we are willing or able to accept. For instance, someone might want to contribute an alternative application API, such as a full C++-based environment. We would decline that contribution, since Android is focused on applications that run in the Dalvik VM. Alternatively, we won't accept contributions such as GPL or LGPL libraries that are incompatible with our licensing goals.
We encourage those interested in contributing source code to contact us via the AOSP Community page prior to beginning any work. You can find more information on this topic at the Getting Involved page.
How do I become an Android committer?
The Android Open Source Project doesn't really have a notion of a "committer". All contributions -- including those authored by Google employees -- go through a web-based system known as "gerrit" that's part of the Android engineering process. This system works in tandem with the git source code management system to cleanly manage source code contributions.
Once submitted, changes need to be accepted by a designated Approver. Approvers are typically Google employees, but the same approvers are responsible for all submissions, regardless of origin.
You can find more information on this topic at the Submitting Patches page.
Compatibility
What does "compatibility" mean?
We define an "Android compatible" device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.
In other words, compatibility is a prerequisite to participate in the Android apps ecosystem. Anyone is welcome to use the Android source code, but if the device isn't compatible, it's not considered part of the Android ecosystem.
What is the role of Google Play in compatibility?
Devices that are Android compatible may seek to license the Google Play client software. This allows them to become part of the Android app ecosystem, by allowing users to download developers' apps from a catalog shared by all compatible devices. This option isn't available to devices that aren't compatible.
What kinds of devices can be Android compatible?
The Android software can be ported to a lot of different kinds of devices, including some on which third-party apps won't run properly. The Android Compatibility Definition Document (CDD) spells out the specific device configurations that will be considered compatible.
For example, though the Android source code could be ported to run on a phone that doesn't have a camera, the CDD requires that in order to be compatible, all phones must have a camera. This allows developers to rely on a consistent set of capabilities when writing their apps.
The CDD will evolve over time to reflect market realities. For instance, the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit telephony hardware, allowing for non-phone devices such as tablet-style music players to be compatible. As we make these changes, we will also augment Google Play to allow developers to retain control over where their apps are available. To continue the telephony example, an app that manages SMS text messages would not be useful on a media player, so Google Play allows the developer to restrict that app exclusively to phone devices.
If my device is compatible, does it automatically have access to Google Play and branding?
Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. Device manufacturers should contact Google to obtain access to Google Play.
If I am not a manufacturer, how can I get Google Play?
Google Play is only licensed to handset manufacturers shipping devices. For questions about specific cases, contact [email protected].
How can I get access to the Google apps for Android, such as Maps?
The Google apps for Android, such as YouTube, Google Maps and Navigation, Gmail, and so on are Google properties that are not part of Android, and are licensed separately. Contact [email protected] for inquiries related to those apps.
Is compatibility mandatory?
No. The Android Compatibility Program is optional. Since the Android source code is open, anyone can use it to build any kind of device. However, if a manufacturer wishes to use the Android name with their product, or wants access to Google Play, they must first demonstrate that the device is compatible.
How much does compatibility certification cost?
There is no cost to obtain Android compatibility for a device. The Compatibility Test Suite is open-source and available to anyone to use to test a device.
How long does compatibility take?
The process is automated. The Compatibility Test Suite generates a report that can be provided to Google to verify compatibility. Eventually we intend to provide self-service tools to upload these reports to a public database.
Who determines what will be part of the compatibility definition?
Since Google is responsible for the overall direction of Android as a platform and product, Google maintains the Compatibility Definition Document for each release. We draft the CDD for a new Android version in consultation with a number of OEMs, who provide input on its contents.
How long will each Android version be supported for new devices?
Since Android's code is open-source, we can't prevent someone from using an old version to launch a device. Instead, Google chooses not to license the Google Play client software for use on versions that are considered obsolete. This allows anyone to continue to ship old versions of Android, but those devices won't use the Android name and will exist outside the Android apps ecosystem, just as if they were non-compatible.
Can a device have a different user interface and still be compatible?
The Android Compatibility Program focuses on whether a device can run third-party applications. The user interface components shipped with a device (such as home screen, dialer, color scheme, and so on) does not generally have much effect on third-party apps. As such, device builders are free to customize the user interface as much as they like. The Compatibility Definition Document does restrict the degree to which OEMs may alter the system user interface for areas that do impact third-party apps.
When are compatibility definitions released for new Android versions?
Our goal is to release new versions of Android Compatibility Definition Documents (CDDs) once the corresponding Android platform version has converged enough to permit it. While we can't release a final draft of a CDD for an Android software version before the first flagship device ships with that software, final CDDs will always be released after the first device. However, wherever practical we will make draft versions of CDDs available.
How are device manufacturers' compatibility claims validated?
There is no validation process for Android device compatibility. However, if the device is to include Google Play, Google will typically validate the device for compatibility before agreeing to license the Google Play client software.
What happens if a device that claims compatibility is later found to have compatibility problems?
Typically, Google's relationships with Google Play licensees allow us to ask them to release updated system images that fix the problems.
Compatibility Test Suite
What is the purpose of the CTS?
The Compatibility Test Suite is a tool used by device manufacturers to help ensure their devices are compatible, and to report test results for validations. The CTS is intended to be run frequently by OEMs throughout the engineering process to catch compatibility issues early.
What kinds of things does the CTS test?
The CTS currently tests that all of the supported Android strong-typed APIs are present and behave correctly. It also tests other non-API system behaviors such as application lifecycle and performance. We plan to add support in future CTS versions to test "soft" APIs such as Intents as well.
Will the CTS reports be made public?
Yes. While not currently implemented, Google intends to provide web-based self-service tools for OEMs to publish CTS reports so that they can be viewed by anyone. CTS reports can be shared as widely as manufacturers prefer.
How is the CTS licensed?
The CTS is licensed under the same Apache Software License 2.0 that the bulk of Android uses.
Does the CTS accept contributions?
Yes please! The Android Open-Source Project accepts contributions to improve the CTS in the same way as for any other component. In fact, improving the coverage and quality of the CTS test cases is one of the best ways to help out Android.
Can anyone use the CTS on existing devices?
The Compatibility Definition Document requires that compatible devices implement the 'adb' debugging utility. This means that any compatible device -- including ones available at retail -- must be able to run the CTS tests.
Click to expand...
Click to collapse
SOURCE
Click to expand...
Click to collapse
INITIAL RELEASE 10/22/2013 @ 5:54 am
Click to expand...
Click to collapse
InsomniaAOSP v1.0
Click to expand...
Click to collapse
Standard Core gapps
Click to expand...
Click to collapse
WORK IN PROGRESS ALL MAINTAINERS COLLABORATE IN GIVING CREDITS
Click to expand...
Click to collapse
Android Open Source Project
CodeKill13
Ubuntu
Linux Mint
Github
Flar
Peter Poelman
itsme
Stericson
JesusFreke
CyanogenMOD
AOKP
PacROM
Rootbox
Evervolv
ParanoidAndroid
slimroms
Team-Hydra -Device Trees-Kernel
Team Horizon
The mikmik
AndroidSpin
Android Police
VanirAOSP
CodefireXexperiment
albinoman887
TheMuppets
Htc
Samsung
TheBr0ken
snuzzo
T-Macgnolia
ljjehl
Saif Kotwal
pr0xy man1Ac
Djwuh
ammikam
!I am not responsible for anything that happens to you or your device as a result of flashing this rom. If you decide to install this rom then you've taken responsibility for any risks involved !!
reserrrrved
Nice to see another 4.3.1 rom for our sensation
Keep the good work, will flash it tommorow
Sent from my HTC Sensation using XDA Premium 4 mobile app
Looks good shall test in the morning , thanks
Sent from my HTCSensation using Tapatalk
Tried it already from DK's thread on other forum.
There are issues with languages, not everything is translated to russian for instance.
Also there are plenty of CM ringtones, why is that?
WiFi hotspot is not working, cannot even detect an access point.
Launcher has weird wallpaper alingment, that doesn't fit at very left or right...
All these are minor issues to polish in the future.
Oh, why there's a theme engine, is it a part of AOSP now or a bonus from CM?
I'm glad see another pure (or maybe not so much) AOSP ROM.
Since there's no new SuperXE ROMs we welcome the new effort with a big smile on our never well shaved faces.
Noobel said:
Tried it already from DK's thread on other forum.
There are issues with languages, not everything is translated to russian for instance.
Also there are plenty of CM ringtones, why is that?
WiFi hotspot is not working, cannot even detect an access point.
Launcher has weird wallpaper alingment, that doesn't fit at very left or right...
All these are minor issues to polish in the future.
Oh, why there's a theme engine, is it a part of AOSP now or a bonus from CM?
I'm glad see another pure (or maybe not so much) AOSP ROM.
Since there's no new SuperXE ROMs we welcome the new effort with a big smile on our never well shaved faces.
Click to expand...
Click to collapse
hahahah..I agree with this " our never well shaved faces".. New ROM to play with....Good job
Nice to see it's playing again. Don't let our Senny dead.
oooo another AOSP for my Sensation! Bring it on! Thank you!!
---------- Post added at 04:35 AM ---------- Previous post was at 04:34 AM ----------
Any listing of what is working and what is not?
Good work, i'll try it
anyone got any feedback on this one?
Sage said:
anyone got any feedback on this one?
Click to expand...
Click to collapse
Yes, +1, feedback is important for the rom cooker
Is this really pure AOSP without any mods?
I mean "stock" android 4.3.1 ?
Just for the record that I am not running this rom anymore and the bugs I noticed and know of are:
Quit hours not working
Clock Widget settings gives a FC
Setting the navigation bar in Insomnia setting will FC the system UI and can't be recovered and need a factory reset
Browser and the Mail-App have a screen glitches.
I saw this InsomniaAOSP purity test!
First of all I want to applaud the integrity of the team working on OmniRom and for standing for software freedom. As the only GPL ROM on the phone, I believe it will reach a certain prominence once critical mass of functionality is achieved. I have some suggestions that I was hoping to get feedback for from the Devs here.
1- What is the possibility for devising an in-place upgrade system that works across future OS version upgrades for major changes in AOSP? (something akin the upgrade systems of current GNU/Linux systems)
2- Incorporating apps from the guardianproject (.info) a privacy and security oriented group that make secure messaging apps and TOR for Android. That will be our anwser to the so called secure chat of CM.
3- Cooperation with the largest FOSS software repo F-Droid and perhaps including it as a default app repo option for OmniRom.
4- Now this is a big one, but as a distro that prizes Software Freedom and the GPL above all else you are in a unique position to be a demo showcase for incorporating the major app frameworks being ported to Android like Qt and Gnome. Arranging with the devs from KDE and Gnome to make this a reality would be a major milestone for the FOSS movement's efforts to bring free software in an environment that is being increasingly closed off like what Google is doing with their absorption of features in proprietary apps and the treachery of the CM turncloaks.
Casual observer here. I don't think it's accurate to call it a GPL ROM given how many non-free drivers are required to get working WiFi and so on. OmniROM encourages GPL as a way of keeping the community honest but I don't think it's set in stone.
1. upgrades on Android don't happen in same way as GNu/Linux: it's always a fresh install. CM already does this, or you can use recovery mode.
2. good idea! more generally, system wide proxy settings which would allow all traffic to go through Tor. Tor is one part of remaining anonymous, the browser needs to be locked down for example. Guardian Project say that their companion browser, Or web, doesn't work on Android 4.4, and they might stop developing it. There are other Android techniques for anonymity e.g. xprivacy.
3. F-Droid builds and signs apps, it's hard to see room for cooperation. It will soon have ability to install apps silently if part of a ROM. They dropped their Android.mk; looks like time to bring it back, maybe with package name change option.
4. Qt was announced on day one at the BBQ!
I'm pretty much a noob when it comes to android development, so please bear with me:silly:. As I understand, stock android is a generic firmware released by Google Inc. and not specific to any particular device. Similarly, CyanogenMod is also a generic firmware. Then what's the difference between the two?
prahladyeri said:
I'm pretty much a noob when it comes to android development, so please bear with me:silly:. As I understand, stock android is a generic firmware released by Google Inc. and not specific to any particular device. Similarly, CyanogenMod is also a generic firmware. Then what's the difference between the two?
Click to expand...
Click to collapse
Hi prahladyeri. This is from the Cyanogenmod Wiki
So what is the difference between Android and CyanogenMod?
About 1-2 times a year, the vanilla Android operating system (known as AOSP, or the Android Open Source Project) is internally developed, then released to the public, by Google. They provide the source code to anyone who wants to download it. The CyanogenMod community, comprised mostly of unpaid volunteers and enthusiasts from around the world, takes this newest Android code and "ports" it to dozens of new and older (aka "legacy") devices. At the same time, other CyanogenMod developers start adding features, fixes, and improvements that Google didn't include to the CyanogenMod code, which benefits all the devices. The CyanogenMod community has a whole infrastructure for people to build and test experimental versions, report bugs, and contribute back to the source code.
Sometimes features that started in CyanogenMod have appeared in newer version of "official" Android. And every time Android does a new "code dump" of their latest version, CyanogenMod benefits from Google's changes.
In this way, CyanogenMod is one (but not the only) community distribution of what started as vanilla AOSP. The Android community is vibrant, with numerous "modders" and "themers" and "performance enhancers" taking the source code and doing incredible things to it. Generally, there is a spirit of sharing knowledge and empowering people to experiment with controlling their devices, often giving old phones new life, and hopefully having fun in the process.
What does it all mean to me?
CyanogenMod is an alternative operating system intended to replace the one pre-installed on your smart phones and tablets. If you've got an older device that isn't getting updates anymore, or if your device seems unusually slow, or maybe you're sick of spyware, adware, and other unwanted garbage on your phone that you can't remove... Maybe your device is missing features or has been otherwise artificially limited in functionality. Perhaps you just could use a boost in performance. Or maybe you'd like to be more confident that your operating system has included some of the latest bug fixes.
If so, CyanogenMod might be for you.
Click to expand...
Click to collapse
I loved to hear about GrapheneOS's Sandboxed Play services that allow running Google Play services as regular sandboxed apps. I don't own a google phone and am using LOS18.1. Unfortunately it seems LineageOS won't integrate the feature (see reddit).
That's why I looked for the corresponding commits in GrapheneOS, adopted them for LineageOS 18.1 (almost everything could be auto-merged) and used LOS4mG's docker CI/CD to build LOS18.1 with GrapheneOS's compatibility layer.
I don't want to release ROMs myself, but am just leaving the project here: https://github.com/sn-00-x/lineage-gmscompat
The docker image is on docker hub so you could build LOS18.1 by simply running the image sn00x/docker-lineage-cicd (set env vars and volumes as explained here). Or grab the patches here and apply yourself.
I'm very very sorry.. I have troubles building.. in fact I never got a build to succeed and didn't need much custom work anyway. But this one from your docker, I tried for two days, and there are always errors as I'm not experienced... You'd be VERY generous to build a 18.1 from your docker with the sandboxed gms patches for Pixel 4 (flame). That would be very kind of yours !! Thanks in advance
aibos said:
I'm very very sorry.. I have troubles building.. in fact I never got a build to succeed and didn't need much custom work anyway. But this one from your docker, I tried for two days, and there are always errors as I'm not experienced... You'd be VERY generous to build a 18.1 from your docker with the sandboxed gms patches for Pixel 4 (flame). That would be very kind of yours !! Thanks in advance
Click to expand...
Click to collapse
You can install GrapheneOS on Pixel 4, why would you want to use LOS 18.1?
To use VPN Tethering.
I'm pretty sure there are issues with some indexes with some of the following patch files, related to "strings.xml".
0005-gmscompat-Keep-GMS-services-alive-by-converting-to-f.patch
0015-gmscompat-Make-notification-channel-more-user-friend.patch
0016-gmscompat-Improve-foreground-service-notification-UX.patch
I get this error:
Code:
"error: invalid file path 'frameworks/base/core/res/res/values/strings.xml.orig'."
I dont know how to troubleshoot this. Any suggestion/fix?
Hello. Trying to do this same thing to lineage 19 for pixel 5....I can just merge this code into my repo and build?
Must you have signature spoofing for SPS?
It's sad when a talented dev disappears.. :'(
I am trying to take up where he left off. I will be attempting to patch this into Lineage 19 when I get off of work tonight.
That's why it's sad when a talented dev disappear...
Because then, nothing happens
Linking previous about GMS_Comapt by @sn00x here: https://forum.xda-developers.com/t/sandboxed-play-services.4341085/
I'd talks with GrapheneOS dev on twitter and reproducing them here for more insights:
> Can gms_compat be made available to use by everyone? I really want that to be implemented on LineageOS but that's not possible as they straight away rejected the request.
Is gms_compat device specific? If not, can it developed as a Magisk moduleso that installing that allows users to install GApps without actually flashing them in the first place?
Thank you.
> it's not device specific at all
> it could be easily ported elsewhere at least once the changes are squashed
> Can you elaborate a bit about these in case of the time permits? Squashing changes? You mean merging of commits?
> https://github.com/GrapheneOS/platform_libcore/commit/8d4383d15f9baed7665dbb459b29567e729b166d
> here's the simplified libcore changes, for example
> will be doing frameworks/base next
> Sandboxed Google Play compatibility layer (gmscompat):
Add support for loading DEX files from "/proc/self/fd" APK paths · GrapheneOS/[email protected]
Needed to load code from the Google Play services' Dynamite APK modules, which are available only by the file descriptor reference.
github.com
gmscompat: linker: Add support for opening zip files by fd paths · GrapheneOS/[email protected]
In some cases, it can be useful to load libraries from zip files that are only available by fd reference. For example, file descriptors of APKs containing native libraries may be sent via Binder IP...
github.com
add GmsCompat app · GrapheneOS/[email protected]
Make Build System (being phased out upstream). Contribute to GrapheneOS/platform_build development by creating an account on GitHub.
github.com
gmscompat: add compatibility layer for unprivileged GMS · GrapheneOS/[email protected]
Originally authored by Danny Lin <[email protected]> for inclusion in GrapheneOS. It has since been substantially extended and rewritten by Dmitry Muhomor <[email protected]> (pr...
github.com
gmscompat: support for Dynamite modules · GrapheneOS/[email protected]
Authored by Danny Lin <[email protected]> and Dmitry Muhomor <[email protected]> for inclusion in GrapheneOS. Commit history: Before June 2022: https://github.com/GrapheneOS/pl...
github.com
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat
https://github.com/GrapheneOS/platf...mmit/550842c62ac693234b38fcaa0ed30692fae1873b
do not allow disabling GmsCompat app · GrapheneOS/[email protected]
Apps will break if it's disabled, handling this case in code increases complexity unnecessarily.
github.com
gmscompat: Add ConnectivityManager hook for baseline compatibility · GrapheneOS/[email protected]
This is part of GmsCompat's baseline compatibility for unprivileged Google Play Services. Change-Id: I3e87706f1f3b87c0af9d00f6ce92144469596f8c
github.com
gmscompat: restart GMS processes when permission gets granted · GrapheneOS/[email protected]
Contribute to GrapheneOS/platform_packages_modules_Permission development by creating an account on GitHub.
github.com
gmscompat: Add WifiManager hooks for baseline compatibility · GrapheneOS/[email protected]
This is part of GmsCompat's baseline compatibility for unprivileged Google Play Services. Change-Id: I2f56a47a6a732d6a73531c7f80aca69065a88c38
github.com
gmscompat: allow harmless COLUMN_NOTIFICATION_CLASS · GrapheneOS/[email protected]
Contribute to GrapheneOS/platform_packages_providers_DownloadProvider development by creating an account on GitHub.
github.com
Pixel eSIM management app integration:
https://github.com/GrapheneOS/platf...mmit/be60cb05013a1fb61675f21c705ddbef296f221a
https://github.com/GrapheneOS/platf...mmit/4c4a2f0df9c53eaf22b7add0305f0bfaac46695c
> this is the list of commits now
> after it has been squashed / cleaned up
> Thank you very much for more detailed info. I'll try my level best analyse and learn from these.
Based on this, I believe that, instead of making GMS_Compat just available for LineageOS, we can make it a module that can be flashed wither with Magisk or Recovery making it available for everyone as it is **NOT** device specific..
@sn00x This is awesome!
Has anyone tried this with lineage 19 ?
Also do OTA updates work?
Hi, I am trying to build a rom and wanted to include the graphene os sandboxed google play. I have never built a rom before, do I need to sync your repo into one of the folders where I have my rom files?
Not sure if this is relevant, but I am trying to build for AOSP for Sony Xperia
GMScompat is a big joke and just a fig leaf: Making Googleapps third party apps does not do much, except for giving user a false sense of security. As long as you install GMS framework and apps, they use intents to interact with AOSP, as well as system processes to do what they were designed to do - to spy on users.. The only way to remove such intents is to modify those application's sources, which is NOT possible, because they are closed source.
optimumpro said:
GMScompat is a big joke and just a fig leaf: Making Googleapps third party apps does not do much, except for giving user a false sense of security. As long as you install GMS framework and apps, they use intents to interact with AOSP, as well as system processes to do what they were designed to do - to spy on users.. The only way to remove such intents is to modify those application's sources, which is NOT possible, because they are closed source.
Click to expand...
Click to collapse
Why is this a joke? You are completely missing the point of what gmscompat is trying to achieve: to make using gms more private and secure. The best example is that with gmscompat google cannot access device identifiers auch as imei for example. Plus, as the name suggests, google cannot escape the app sandbox anymore. it doesn't have any special permissions anymore. speaking of permissions, you can revoke any permission of the google apps thanks to gmscompat.
as i am totally intersted into this subject using and following every rom that implement this feature ( sparkos voltageos yaap os etc)
recently the gmscompat fail to start and from my search thegraphene os team make it more difficult to launch needs frequent update of gmscompat.apk and config which is nesserory to make it work
from the bigining the grahene os team doesnt want to make it to other than thier os and pixel devices
drsanusi said:
as i am totally intersted into this subject using and following every rom that implement this feature ( sparkos voltageos yaap os etc)
recently the gmscompat fail to start and from my search thegraphene os team make it more difficult to launch needs frequent update of gmscompat.apk and config which is nesserory to make it work
from the bigining the grahene os team doesnt want to make it to other than thier os and pixel devices
Click to expand...
Click to collapse
When I was using Poco F3 I had SparkOS installed as a "warmup" for Pixel and GrapheneOS. The ROM is a good replacement for anyone who wants this experience of sandboxed play services, but it lacks a lot of stuff from the GrapheneOS. And also it lacks polished default apps. Thankfully you can disable them and install your own though...
hellcat50 said:
Why is this a joke? You are completely missing the point of what gmscompat is trying to achieve: to make using gms more private and secure. The best example is that with gmscompat google cannot access device identifiers auch as imei for example. Plus, as the name suggests, google cannot escape the app sandbox anymore. it doesn't have any special permissions anymore. speaking of permissions, you can revoke any permission of the google apps thanks to gmscompat.
Click to expand...
Click to collapse
Permissions and intents are contained in app's Manifest, as well as in app's code. Google certificates, which recognize Gapps as native are in AOSP code. So, regardless of where the app is installed, it can go around 'compatibility' layers and do their thing, i.e. collect user data.
The only proper way to get rid of higher level permissions is to modify Gapps' code, which is impossible.
optimumpro said:
Permissions and intents are contained in app's Manifest, as well as in app's code. Google certificates, which recognize Gapps as native are in AOSP code. So, regardless of where the app is installed, it can go around 'compatibility' layers and do their thing, i.e. collect user data.
The only proper way to get rid of higher level permissions is to modify Gapps' code, which is impossible.
Click to expand...
Click to collapse
Sorry but i call bs on that. Do you have any sources to claim that?
hello world
unfortunately one sees more and more so called 'custom roms' including GApps by default
this brings up a question: is this legal?
as an example reading:
Google apps are the proprietary Google-branded applications that come pre-installed with most Android devices, such as the Play Store, Gmail, Maps, etc. Due to licensing restrictions, these apps cannot come pre-installed with LineageOS and must be installed separately. The Google apps are not required to boot or run LineageOS, however many users find them beneficial to take full advantage of the Android ecosystem.
Click to expand...
Click to collapse
SOURCE: https://wiki.lineageos.org/gapps
or something like this:
Take note that Open GApps does not provide you with any license for Google’s APKs included in the package. The Open GApps packages merely provide a convenient way to sideload APKs to your device. It is your own responsibility to obtain the proper permissions by e.g. buying an OHA-licensed device with pre-installed Google Apps and/or acquiring the applications from Google’s Play Store.
The pre-built packages from OpenGApps.org are provided ONLY as courtesy by OpenGApps.org without warranty of ANY kind, under the terms that they can be freely used for personal use only, and are not allowed to be mirrored to the public other than OpenGApps.org.
Click to expand...
Click to collapse
SOURCE: https://opengapps.org/#aboutsection
one can even read:
Custom ROM developers, however, can’t easily bundle these Google apps and services with their builds. As these apps are not using the Apache or GPLv2 license, bundling them within the ROM presents legal challenges.
Click to expand...
Click to collapse
SOURCE: https://www.xda-developers.com/download-google-apps-gapps/
as i am not an expert i hope this post can help to answer the question.
furthermore it will help to create some kind of orientation.
Hmm...
As far as XDA is concerned. We allow gapps in ROM.
The gapps thing was between Cyanogenmod and Google.
It's legal to run those apps on devices whose manufacturers signed up with Google.
On other devices, it was not allowed by Google
CyanogenMod had a device that was not CTS compatible so they received DMCA which prevented them from distributing ROMs with gapps.
So it depends on whom you are asking.
You can argue, "If you have purchased a device and the manufacturer has paid a license to run Gapps then you can run those gapps on your device. "
or you can argue "Google has allowed you to run gapps only on firmware approved by google so you shouldn't run gapps"
Regardless they have systems in place to prevent you from not using apps like Gpay via PlayIntegrity/SafetyNet.
@karandpr
the vast majority of all xda-topics are about:
gpay/safetynet not working help urgent now!!!
so one can asume, it ist prevented by g and so not legal
please be so kind and help me find one so called 'custom-rom-gapps-included'
that can provide a proper licensed gapps
Tom Mix said:
@karandpr
the vast majority of all xda-topics are about:
gpay/safetynet not working help urgent now!!!
so one can asume, it ist prevented by g and so not legal
please be so kind and help me find one so called 'custom-rom-gapps-included'
that can provide a proper licensed gapps
Click to expand...
Click to collapse
You can still access play store to download apps.
You can use apps that don't use SafetyNet.
Just because apps throw attestation failure doesn't mean it is illegal to run gapps.
SafetyNet | PlayIntegrity matches device firmware and root status.
Once you unlock Bootloader ,SafetyNet can flag it as Unsafe.
This is an old article on how safetynet works but the base of how it works is similar.
SafetyNet: Google's tamper detection for Android · Yiannis Kozyrakis ~ blog
thoughts on mobile security
koz.io
Technically SafetyNet is an API that is used by other apps to detect whether phone is rooted/BL unlocked or not.
Let's say you have a BL locked phone which runs Stock Android 13, and then you have a BL Unlocked phone which runs the same firmware.
However, in the later case SafetyNet will throw attestation failure.
Thats how safetynet is supposed to work./
I found a quite old article but it explains why the majority of AOSP ROMs are licensed when flashed onto compatible devices.
There are two kinds of Android forks - 'compatible' and 'non-compatible'. 'Compatible' Android forks are those that are based on the Android Open Source Project (AOSP); comply with the Android Compatibility Definition Document (CDD); and pass the Compatibility Test Suite (CTS).
'Compatible' forks may or may not include Google apps (gApps) or Google Play Services, but, because they're 'compatible', gApps and Play Services can be sideloaded or added later by users, meaning they can participate fully in the Play app ecosystem. Examples include CyanogenMod and the MIUI OS.
Google-certified CyanogenMod phones Oppo N1 and the OnePlus one have passed Google’s CTS and CDD, meaning that they officially run Google's apps and access the Google Play Store out of the box.
'Non-compatible' forks are built on AOSP, but are built to run their own ecosystems. Examples of 'non-compatible' Android devices include the Amazon Fire phone and the Blackphone with PrivatOS.
source: https://deviceatlas.com/blog/android-forks-why-google-can-rest-easy-for-now
As I understand, CyanogenMod haven't lost a lawsuit, they simply stepped back preventive of the power of Google.
My conclusion, if one is able to install GMS/Play Services, the device is compatible - hence legal.
@alecxs
very interesting article at deviceatlas! thanks for the link
the most interesting part is:
Custom ROM-makers like Cyanogen aren’t OEMs, so the same rules don’t apply to them – passing the CTS, compliance with the Android CDD. If the custom ROM is flashed onto a ‘compatible’ phone, then everything is gravy… except for the pesky issue of Google apps, which need to be licensed. Cyanogen found this out the hard way in 2009, when Google slapped lead developer Steve Kondik with a Cease and Desist letter, the gist of which was that he wasn’t licensed to distribute Google apps with CyanogenMod.
Click to expand...
Click to collapse
indeed no lawsuit just:
ingenious solution: users could Google-ify their CyanogenMod installations by backing up the Google parts already on their phones, and reactivating them after installation – without incurring Google’s wrath.
Click to expand...
Click to collapse
so flashing afterwards is okay, but not distributing with custom-rom
All those post sound to me like Liability Notices that if you use Gapps. They are not liable for any of the content given or damage to you. So They don't get sued for content you download from it or basically any liability that could develop. In so many words. You can't sue them if you use the unlicensed apps and the content creators can't sue them and have to sue you the user instead if you obtain from their service paid content. So idk. If you want the answer to this I'd call a lawyer or just don't use Google services and avoid all apps that require the use of Google and you shouldn't have a issue.
Tom Mix said:
so flashing afterwards is okay, but not distributing with custom-rom
Click to expand...
Click to collapse
both is fine on compatible forks.
@alecxs
maybe it is a language-barrier on my side but the article
and the other sources state that it cant be bundeled,
though flashed afterwards
even the g-lawyers said no! and bundled distribution was omitted.
and regarding LOS in particular one can assume that
the distribution of 'LOS-roms' including gapps is not allowed
Tom Mix said:
even the g-lawyers said no! and bundled distribution was omitted.
Click to expand...
Click to collapse
It doesn't matter what google lawyer says. As long as there is no court verdict nothing prohibits you to bundle gapps for compatible devices.
I payed for all my modding software from google. the programers are msging the google is a bumb bussness on playstore. really about playstore its got other investments not everyone 2$ 4$ app people. Ill creep my mods with luck on my shoulder tweaken on my stuff. lol sick