Related
I have no idea where this needs to be posted. There are a number of different threads regarding this topic, and I know at least one of them are locked. So mods, feel free to move, delete or merge this as you see fit.
Google, via the Android Developers Blog, issued a statement a short while back. Here it is ...
A Note on Google Apps for Android
Posted by Dan Morrill on 25 September 2009 at 2:31 PM
Lately we've been busy bees in Mountain View, as you can see from the recent release of Android 1.6 to the open-source tree, not to mention some devices we're working on with partners that we think you'll really like. Of course, the community isn't sitting around either, and we've been seeing some really cool and impressive things, such as the custom Android builds that are popular with many enthusiasts. Recently there's been some discussion about an exchange we had with the developer of one of those builds, and I've noticed some confusion around what is and isn't part of Android's open source code. I want to take a few moments to clear up some of those misconceptions, and explain how Google's apps for Android fit in.
Everyone knows that mobile is a big deal, but for a long time it was hard to be a mobile app developer. Competing interests and the slow pace of platform innovation made it hard to create innovative apps. For our part, Google offers a lot of services — such as Google Search, Google Maps, and so on — and we found delivering those services to users' phones to be a very frustrating experience. But we also found that we weren't alone, so we formed the Open Handset Alliance, a group of like-minded partners, and created Android to be the platform that we all wished we had. To encourage broad adoption, we arranged for Android to be open-source. Google also created and operates Android Market as a service for developers to distribute their apps to Android users. In other words, we created Android because the industry needed an injection of openness. Today, we're thrilled to see all the enthusiasm that developers, users, and others in the mobile industry have shown toward Android.
With a high-quality open platform in hand, we then returned to our goal of making our services available on users' phones. That's why we developed Android apps for many of our services like YouTube, Gmail, Google Voice, and so on. These apps are Google's way of benefiting from Android in the same way that any other developer can, but the apps are not part of the Android platform itself. We make some of these apps available to users of any Android-powered device via Android Market, and others are pre-installed on some phones through business deals. Either way, these apps aren't open source, and that's why they aren't included in the Android source code repository. Unauthorized distribution of this software harms us just like it would any other business, even if it's done with the best of intentions.
I hope that clears up some of the confusion around Google's apps for Android. We always love seeing novel uses of Android, including custom Android builds from developers who see a need. I look forward to seeing what comes next!
Click to expand...
Click to collapse
Source:
http://android-developers.blogspot.com/2009/09/note-on-google-apps-for-android.html
Yep, it's over.
We're still asking for community access to these applications that are almost essential to the current Android experience. I really doubt it's hurting their bottom line substantially enough to justify the killing of their distribution.
In other words, Mr. Morrill's post was pretty much a sugarcoated attempt to gain some of the PR they lost.
We always love seeing novel uses of Android, including custom Android builds from developers who see a need.
Click to expand...
Click to collapse
A "novel" use from a developer who "sees a need" is quite a way to describe a substantially improved version of your OS.
So what is the conclusion? A lot of the things could be replaced, but as mentioned before, the sync tools and so forth are tricky to get around. What is the next step from here?
cyanogen said:
Yep, it's over.
Click to expand...
Click to collapse
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
cyanogen said:
Yep, it's over.
Click to expand...
Click to collapse
So no more ROMs? Or no more ROMs with close-source apps?
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
It's still illegal. A clever trick to walk around the legal fine print. But in essence, it's illegal...
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
Without the basic function to sign into the device using your Google credentials, the ROM is useless. You can't just grab them from another build (as far as I know) because of the way they are tied in at compiling to the framework. So you would have to pull the ROM, grab the proprietary pieces from somewhere else, and compile the source yourself.
Right?
To touch on this in another way, what would it take for Cyanogen to become a licensed distributor of Google's Apps for Android? If there are really 30,000 users, couldn't legal fees be gathered from them? And, couldn't the business license be set up as a Not-For-Profit? Like the Association of Cyanogen Followers? If it were, wouldn't the required fees to license the distribution rights of the software be tax-free and operating expenses for the association? Meaning, any costs for running the business could be taken out of membership dues and donations? With the rest being tax write-offs?
Just a thought, as I would love to see this made legit, 4.0.4 is great, but I don't want this to stop here.... selfish I know, but it's the truth.
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
I guees thats no way. What if you have a wipe? No APNs or anything else? You cant dowmload "Market" als a single-app directly from google (as i know).
daveid said:
Without the basic function to sign into the device using your Google credentials, the ROM is useless. You can't just grab them from another build (as far as I know) because of the way they are tied in at compiling to the framework. So you would have to pull the ROM, grab the proprietary pieces from somewhere else, and compile the source yourself.
Right?
Click to expand...
Click to collapse
Then what the hell is google talking about "encouraging other ROM releases"? If that isn't possible without some pieces of Google software, then is it literally impossible to develop a custom ROM for android?
Thoughts, Cyanogen?
As soon as my contract is I am Too! I can predict a mass exit from android and google!
daveid said:
Without the basic function to sign into the device using your Google credentials, the ROM is useless. You can't just grab them from another build (as far as I know) because of the way they are tied in at compiling to the framework. So you would have to pull the ROM, grab the proprietary pieces from somewhere else, and compile the source yourself.
Right?
Click to expand...
Click to collapse
Is this true? If its proprietary how did CY compile them in the first place? In order to compile don't you need access to the source?
So just come up with replacements for those apps that are closed source and not available on the market...
Devs WILL find a way... I guarantee you
But yeah, Google SUCKS on this...They could have just given him limited licensing...
Without a doubt the most foolish decision I've seen Google make in terms of Android so far. This puts a major damper on a community that was helping make Android better in very real ways.
The only explanation I can come up with is that the closed apps use 3rd party licensed code that Google can't redistribute. Otherwise this is just completely boneheaded.
Google said:
With a high-quality open platform in hand, we then returned to our goal of making our services available on users' phones. That's why we developed Android apps for many of our services like YouTube, Gmail, Google Voice, and so on. These apps are Google's way of benefiting from Android in the same way that any other developer can, but the apps are not part of the Android platform itself. We make some of these apps available to users of any Android-powered device via Android Market, and others are pre-installed on some phones through business deals. Either way, these apps aren't open source, and that's why they aren't included in the Android source code repository. Unauthorized distribution of this software harms us just like it would any other business, even if it's done with the best of intentions.
Click to expand...
Click to collapse
They claim these apps (YouTube, Gmail, etc) are Googles way to benefiting from Android, but they are not distributed with all android phones? I understand that companies license these applications from Google, but how does it hurt them if they are installed on a device that would already have them?
Then they say "We make some of these apps available to users of any Android-powered device via Android Market", yet this entire thing came about because the Android Market is being distributed? How can any device get these if the market is one thing that can not be distributed?
I paid for the ADP1, which came with Gmail, YouTube and the other applications. The ADP1 feature was that I could flash any ROM I wanted to on the device, but now they are telling me that I can't put one on there if it contains their applications that my device had in the first place.
Hello Google, welcome to the the Dark side, so much for "Don't be evil"
I will help with anything I can on a project to replace the Google Products.
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
ya i was thinking the same .i mean if not ,how do we get gmail ,youtube,ect?do we have to download from market ? some are not in market like youtube.i use gmail all the time .
Do the current Roms have to pulled?
That shiny device with an Apple on it is looking mighty delicious
CyanogenMod officially done now:
http://twitter.com/cyanogen
"Sorry everyone, CyanogenMod in it's current state is done. I am violating Google's license by redistributing their applications."
dwang said:
Is this true? If its proprietary how did CY compile them in the first place? In order to compile don't you need access to the source?
Click to expand...
Click to collapse
I had assumed that they were "reverse-engineered" using something like baksmali, to gain access to the source.... I could be wrong.
【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!
Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
ZuEma said:
Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
Click to expand...
Click to collapse
In case you might want to give it a try, you could start with rooting according to this thread:
http://forum.xda-developers.com/showthread.php?t=2573743
NOTE:- Archos 45 Platinum too has similar device specifications. The same CWM version worked for @best98 who is using an Archos 45 Platinum.
Click to expand...
Click to collapse
I guess there is a need now to step up to KitKat or newer, if the Webos security hole is not hashed out by other ways on devices running JB 4.3 or lower
Tod Beardsley
Google No Longer Provides Patches for WebView Jelly Bean and Prior
Gepostet von Tod Beardsley in Metasploit auf 12.01.2015 00:19:38
Over the past year, independent researcher Rafay Baloch (of "Rafay's Hacking Articles") and Rapid7's Joe Vennix have been knocking out Android WebView exploits somewhat routinely, based both on published research and original findings. Today, Metasploit ships with 11 such exploits, thanks to Rafay, Joe, and the rest of the open source security community. Generally speaking, these exploits affect "only" Android 4.3 and prior -- either native Android 4.3, or apps built with 4.3 WebView compatibility. sadjellybeans_t.png
WebView is the core component used to render web pages on an Android device. It was replaced in Android KitKat (4.4) with a more recent Chromium-based version of WebView, used by the popular Chrome browser.
Despite this change, though, it’s likely there will be no slow-down of these Android security bugs, and they will probably last a long time due to a new and under-reported policy from Google's Android security team: Google will no longer be providing security patches for vulnerabilities reported to affect only versions of Android's native WebView prior to 4.4. In other words, Google is now only supporting the current named version of Android (Lollipop, or 5.0) and the prior named version (KitKat, or 4.4). Jelly Bean (versions 4.0 through 4.3) and earlier will no longer see security patches for WebView from Google, according to incident handlers at [email protected].
Up until recently, when there's a newly discovered vulnerability with Android 4.3, the folks at Google were pretty quick with a fix. After all, most people were on the "Jelly Bean" version of Android until December of 2013. Jelly Bean's final release was just over a year ago in October of 2013. This is why this universal cross-site scripting bug was fixed, as seen in the Android changelog and Rafay's blog, Rafay Hacking Articles.
Google on Patching pre-KitKat
However, after receiving a report of a new vulnerability in pre-4.4 WebView, the incident handlers at [email protected] responded with this:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.
So, Google is no longer going to be providing patches for 4.3. This is some eyebrow-raising news.
I've never seen a vulnerability response program that was gated on the reporter providing his own patch, yet that seems to be Google's position. This change in security policy seemed so bizarre, in fact, that I couldn't believe that it was actually official Google policy. So, I followed up and asked for confirmation on what was told to the vulnerability reporter. In response, I got a nearly identical statement from [email protected]:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.
When asked for further clarification, the Android security team did confirm that other pre-KitKat components, such as the multi-media players, will continue to receive back-ported patches.
Sorry, Jelly Bean, You're Too Old
Google's reasoning for this policy shift is that they "no longer certify 3rd party devices that include the Android Browser," and "the best way to ensure that Android devices are secure is to update them to the latest version of Android." To put it another way, Google's position is that Jelly Bean devices are too old to support -- after all, they are two versions back from the current release, Lollipop.
On its face, this seems like a reasonable decision. Maintaining support for a software product that is two versions behind would be fairly unusual in both the proprietary and open source software worlds; heck, many vendors drop support once the next version is released, and many others don't have a clear End-Of-Life (EOL) policy at all. (An interesting side note: neither Google nor Apple have a published EOL policy for Android or iOS, but Microsoft and BlackBerry provide clear end of life and end of sales dates for their products).
Most Android Devices Are Vulnerable
While this may be a normal industry standard, what's the situation on the ground? Turns out, the idea that "pre-KitKat" represents a legacy minority of devices is easily shown false by looking at Google's own monthly statistics of version distribution:
As of January 5, 2015, the current release, Lollipop, is less than 0.1% of the installed market, according to Google's Android Developer Dashboard. It's not even on the board yet.
The next most recent release, KitKat, represents about two fifths of the Android ecosystem. This leaves the remaining 60% or so as "legacy" and out of support for security patches from Google. In terms of solid numbers, it would appear that over 930 million Android phones are now out of official Google security patch support, given the published Gartner and WSJ numbers on smartphone distribution).
The Economics of Upgrading
Beside the installed bases, I posit that the people who are currently exposed to pre-KitKat, pre-Chromium WebView vulnerabilities are exactly those users who are most likely to not be able to "update to the latest version of Android" to get security patches. The latest Google Nexus retails for about USD$660, while the first hit for an "Android Phone" on Amazon retails for under $70. This is a nearly ten-fold price difference, which implies two very different user bases; one market that doesn't mind dropping a few hundred dollars on a phone, and one which will not or cannot spend much more than $100.
Taken together -- the two-thirds majority install base of now-unsupported devices and the practical inability of that base to upgrade by replacing hardware -- means that any new bug discovered in "legacy" Android is going to last as a mass-market exploit vector for a long, long time.
Here Come the Mass-Market Exploits
This is great news for penetration testers, of course; picking company data off of Android phones is going to be drop-dead easy in many, many cases, and I fully expect that handsets will be increasingly in-scope for penetration testing engagements. Unfortunately, this is great news for criminals for the simple reason that, for real bad guys, pretty much everything is in scope.
Open source security researchers routinely publish vulnerability details and working exploits with the expectation that this kind of public discussion and disclosure can get both vendors and users to take notice of techniques employed by bad guys. By "burning" these vulnerabilities, users come to expect that vendors will step up and provide reasonable defenses. Unfortunately, when the upstream vendor is unwilling to patch, even in the face of public disclosure, regular users remain permanently vulnerable.
Roll Your Own Patches?
It's important to stress that Android is, in fact, open source. Therefore, it's not impossible for downstream handset manufacturers, service providers, retailers, or even enthusiastic users to come up with their own patches. This does seem to happen today; a 4.3 vulnerability may affect, say, a Kyocera handset, but not a Samsung device with the "same" operating system.
While this is one of the core promises of open source in general, and Android in particular, it's impossible to say how often this downstream patching actually happens, how often it will happen, and how effective these non-Google-sourced patches will be against future "old" vulnerabilities.
The update chain for Android already requires the handset manufacturers and service carriers to sign off on updates that are originated from Google, and I cannot imagine this process will be improved once Google itself has opted out of the patching business. After all, is AT&T or Motorola really more likely to incorporate a patch that comes from some guy on the Internet?
No Patches == No Acknowledgement
To complicate matters, Google generally does not publish or provide public comment on Android vulnerabilities, even when reported under reasonable disclosure procedures. Instead, Android developers and consumers rely on third party notifications to explain vulnerabilities and their impact, and are expected to watch the open source repositories to learn of a fix.
For example, Google's only public acknowledgement of CVE-2014-8609, a recent SYSTEM-level information disclosure vulnerability was a patch commit message on the Lollipop source code repository. Presumably, now that Google has decided not to provide patches for "legacy" Android WebView, they will also not be providing any public acknowledgement of vulnerabilities for pre-KitKat devices at all.
Please Reconsider, Google
Google's engineering teams are often the best around at many things, including Android OS development, so to see them walk away from the security game in this area is greatly concerning.
As a software developer, I know that supporting old versions of my software is a huge hassle. I empathize with their decision to cut legacy software loose. However, a billion people don't rely on old versions of my software to manage and safeguard the most personal details of their lives. In that light, I'm hoping Google reconsiders if (when) the next privacy-busting vulnerability becomes public knowledge.
Click to expand...
Click to collapse
Hi,
I just want you all to vote for your favourite custom ROM for Redmi Note 5 / Redmi Note 5 Pro. This will help the developer community to better understand the general public demand.
Here is a short description f each type of custom ROM given above(may not be in same order!)
1. LineageOS
We start off with the biggest name in the custom ROM scene – LineageOS. While many of you might not be familiar with the name, LineageOS is actually the same custom ROM that started as CyanogenMod. Back in the fall of 2016, Cyanogen Inc. announced that it was discontinuing development and shut down the infrastructure behind the project. Since then, the developer community has kept the project alive, but under the name of LineageOS. Built on top of Google’s AOSP code and adding their own custom code to it, LineageOS works as a standalone ROM as well as the source code for many other custom ROMs out there. It has the biggest developer team under its name and officially has support for over 190 devices. The ROM includes basic but useful features that include but are not limited to customizing the status bar, changing the overall theme, editing the navbar and much more. While Google’s AOSP is barebones, LineageOS gives it a sense of customizability while maintaining stability.
The ROM offers builds for Android Marshmallow (6.x) and Nougat (7.x), with support for Oreo (8.0) coming soon. Also, the list of officially supported devices includes offerings from Samsung, HTC, Motorola, LG, Xiaomi, OnePlus and more.
2. SlimRoms
If minimalism is what you’re looking for, SlimRoms is right up your alley. Possibly the lightest and most functional custom ROM out there, the SlimRoms project is based on the AOSP code while adding useful tweaks to it. The most notable features of the SlimRoms project is the inclusion of the Slim Recents and the Slim PIE. The recents alternative is used to display the recent apps in a sidebar, as opposed to occupying the entire screen. The PIE, on the other hand, comes as a navbar replacement, that proves to be highly useful when using your device in Immersive mode. Other SlimRoms features include a custom dialer, custom Quick Settings tiles, lock screen shortcuts, Privacy Guard, and more. The SlimRoms project offers simple and minimalistic transitions that end up resulting in a clean and neat interface, that can further be customized should the user choose to.
SlimRoms have been around for a while and is available on all major OEMs such as Google, LG, HTC, Moto, Samsung, Xiaomi, OnePlus and more. The latest supported version is Android Nougat 7.1.2, and a build for Android Oreo (8.0) is expected to be released soon.
3. Paranoid Android
Another great ROM that doubles up as a source for many other custom ROMs out there, Paranoid Android is one of the most acclaimed custom ROMs of all times. The development team focuses on bringing a polished and refined experience while using minimum resources. While it may not boast of the plethora of features and customizations that other ROMs offer, Paranoid Android or PA, does promise a soothing user experience overall. It comes with its own unique features such as Hover mode, which allows the user to view and interact with their notifications from any screen, (which was then integrated into AOSP as part of Heads-up notifications). It also offers its own version of the PIE menu, as well as a fully immersive mode for Android. Paranoid Android has long been regarded as the main project from which Google has brought over a lot of features, one biggest feature being the Ambient Mode, which was present in PA as Peek.
While PA did experience a few bumps lately, causing the development scene to slow down a bit, it is now back and is better than ever, with officially supporting Android Nougat 7.1.2, and support for Android Oreo 8.0 to be released soon. It’s available for devices from Nexus, Pixel, OnePlus, Sony, Oppo and more.
4. Resurrection Remix
For all those users who like to boast about the tons of features that their device has, you can’t do better than Resurrection Remix. Probably one of the most famous custom ROMs out there, Resurrection Remix (RR) has been around for a long time now and is preferred by a huge number of people. RR’s ideology has been to offer the maximum number of features available to the user, and it delivers it in a great fashion. It uses AOSP, LineageOS, SlimRoms, and Paranoid Android; all as its main source code, and then adds extra features to it. While most ROMs cherry pick selected features and add them to their code, RR adds just about anything and everything there is to offer. This does, of course, come at a cost. The ROM itself is quite hefty and seems to be a bit heavier on system resources. Also, having tons of features all mixed up in the code do end up making the ROM unstable at times.
RR currently supports all major devices from manufacturers like Samsung, HTC, LG, Moto, Lenovo, Huawei, OnePlus,and more. Also, it is one of the fastest ROMs to be delivered, so expect Android Oreo 8.0 anytime soon.
5. Dirty Unicorns
If I were to describe Dirty Unicorns in my own words, I’d have to say it is the stable version of Resurrection Remix. This is because of the plethora of customization features it offers is great, and it does so without any loss in the stability of the ROM. This is because the major difference between DU and RR is that while RR simply merges the various codes into one main project, RR’s team actually rewrites the entire code from scratch to ensure system stability. While this does mean that updates come a little slower, they are still able to deliver fortnightly updates. Also, DU has its own DU-SmartBar as well as FlingBar, that are both navigation bar replacements. While the former one functions to add more buttons to the normal navigation bar, the latter one replaces the navbar with a gesture-enabled panel that you can customize. Lately, the development team behind DU decided to remove certain features from the ROM, but those features were simply the ones users like to have on their device but never use it in real life. As a result, the latest versions are stable than ever and goes easier on the system’s resources.
DU currently supports Android Nougat 7.1.2 , and Oreo 8.0 is expected to be released in a couple of weeks for all major devices from Samsung, Moto, LG, OnePlus, Nexus, Pixel, and more.
6. AOSP Extended
As the name suggests, AOSP Extended is built directly from the AOSP source code and adds various cherry-picked commits from multiple other projects. Like all custom ROMs out there that are based on AOSP, AOSP Extended provides a smooth and lag-free experience out of the box. The AOSP Extended is also not short on features (or as the dev team likes to call it – Extensions), boasting of multiple customizability options available to modify the status bar, lock screen, and other Android settings. It also exhibits DU’s navbar/Flingbar, as well as other carefully selected features that mix well with Google’s imagination of Android. The development team behind AOSP Extended is also highly active, rolling out timely updates at the start of each month. AOSP Extended is in most ways, one of the most dependable custom ROMs out there that can be used as a daily driver.
It’s currently available for many devices including the likes of LG, Xiaomi, Lenovo, HTC, Samsung, OnePlus and more, and currently runs on Android Nougat 7.1.2.
7. Pure Nexus
Imagine being on your device’s stock ROM, but with slight tweaks here and there that allow you to customize your device to your choice without losing out on the stock stability. Well, if you own a Nexus or a Pixel device, this is easily possible for you. The Pure Nexus project has been around ever since Nexus 4 and has grown on to support all the Nexus and Pixel devices, with active development on all of them. It offers the same AOSP experience that’s exclusive to Google’s lineup, along with truly tested features and minimal or no bugs. In my experience with this ROM, the battery life was just the same as the stock ROM, but I was able to customize a few things here and there. To put it into better words, think of Pure Nexus as custom ROM that delivers the same experience that you’d get if you had installed Xposed and Gravity Box on the stock AOSP ROM.
The Pure Nexus project is only officially available for the Pixel and Nexus lineup, though it has been ported to other devices as well. It already has support for Android Oreo 8.0.
8. Carbon ROM
To define Carbon ROM would take up more than a couple of words. In your first run of this ROM, you’d find it similar to just about every other custom ROM out there. Use it for a couple of days, and you literally start experiencing the true beauty of Carbon ROM. One of the first ROMs to successfully implement Substratum (initially RRO and Layers), Carbon ROM is regarded as one of the most stable ROMs out there. The added functionalities in the form of CarbonFibers include tons of mods for the System, Status bar, buttons, lights, gestures and other various options. While it still lacks behind RR in the race for maximum customizability features, Carbon ROM still manages to hold its ground. Longtime users find it really hard to switch to any other ROM, for even though the features may be present on other ROMs as well, the smoothness and stability is unmatched. CarbonROM is available on a plethora of devices, thanks to its long-running development, and officially supports major offerings from Samsung, HTC, LG, OnePlus and more. It currently runs on Android Nougat 7.1.2, with support for Android Oreo 8.0 coming soon.
9. ViperOS
Another ROM based on the AOSP Gerrit but having its own custom mods is the ViperOS. You might not have heard of its name, considering its a rather new project, having surfaced around the launch of Android Nougat 7.1 only. Despite being a relatively new project, the ROM has quickly evolved into becoming a very stable and reliable ROM and gives plenty of other competitors a run for their money. A simple and neat ROM, ViperOS does not feature multiple customizability options but instead offers a great balance between battery and performance. The ROM recently even updated their source code for the latest in Android, that is, Android Oreo 8.0. Personally, I feel ViperOS is a near perfect mixture of stock ROM with several customizability features and amazing battery life. Since it is a growing project, it doesn’t have a long list of supported devices, yet, but is soon expected to grow to support all the major devices, with support for Android Oreo 8.0 already been announced.
10. FlymeOS
Okay, so if you’re located just about anywhere outside of China, chances are that you haven’t heard of FlymeOS. Well, FlymeOS is the official OS that powers up Meizu’s range of devices, and it does it amazingly. Originally developed by and for Meizu, the custom ROM project has since then been ported to support other OEM devices as well. FlymeOS stands as a direct competitor to MIUI, having more or less the same interface, combined with a great mixture of colors and details. Some unique features of FlymeOS include an in-built Toolbox that offers a compass, a leveler, a ruler, and toggles for various Android settings right from the corner of your screen. Then, it features its own Security Center as well as support for FlymeOS themes. Lastly, the ROM also comes with mBack key and gestures, that allow you to navigate through the entire UI using just the home key and a couple of gestures. If you’re bored of the stock Android look and MIUI looks a little too cliche for you, FlymeOS might just be what you’re looking for. While Flyme officially supports Android Marshmallow, with its beta announced for Nougat just a couple of weeks ago, the ROM’s features more than makeup for the slow development.
Thanks for voting!
DU, AOSPA and Pure Nexus...aint coming officially for sure....other will definitly
and wrong sub forum for post
LineageOS.
Sent from my MotoG3 using XDA Labs
Viper os
Slim ROM!
why you even started this thread @ap6709
LOS is a must for me
RR, AOSPE
I voted LOS because that is the one that I used the most. I haven't used Slim or AOSP extended. Are they open source and not based on LOS?
So if I don't flash GAPPS there is no proprietary code?
Lineage OS
Resurrection remix , AOSPE.
methuselah said:
why you even started this thread @ap6709
Click to expand...
Click to collapse
Just to get a public opinion on the most sought after custom ROMs and also to make the custom ROM developers aware of the demand. That is all. Am I doing something wrong? Please tell frankly.
:angel:
What is the code name of this device?
jilx said:
What is the code name of this device?
Click to expand...
Click to collapse
AFAIk Vassace
Nitrogen os
I don't know why this thread is made....but it should be removed.
It all depends on developers whether and which rom they will build. @MikeChannon please look after this and close this thread
This is the official Telegram Group for Redmi Note 5 Pro:
********************************************************************
Telegram Group Link - https://telegram.me/redminote5proofficial
********************************************************************
Guys please join!
Aosp extended, Resurrection remix ?
A couple of days back, a dev made Project Treble possible in a RN4 by using the MIUI partition for device and component firmware as required for Treble. I personally don't own a RN4 so didn't get to test it, neither am I am following that thread. But if it's possible to do so, then the ROMs with 8.1 and above should be a lot more stable ( talking about you RR ) . And if I'm not mistaken many devs already know about this and some devs of RN4 we'll move into RN5P. So as for custom ROMs are concerned, let's wait it out. The devs understand the device a lot better than us end users. Let the devs figure out a standard for the OS/ROMs. Till then MIUI isn't bad. Personally I dislike the bloat and lack of an App Drawer, contradicts the minimal approach which I prefer. But that's just me, but I think in general is not unusable.
The phone was up for sale first time 2 days ago and so I think instead of drooling for ROMs, give the devs their own time. They are doing it for free for us. Let's respect that and not be greedy.
Nitrogen os
Loving in kenzo now i want on rn5 pro
This may be stupid, but I couldn't find any resources regarding this. We have custom recoveries for android devices but why isn't there custom bootloaders like there is for PCs ? Like in the PC space we have the likes of reFind and gnu grub.
Thanks
There are some instances of alternate bootloader projects. Just that they are not popular,
[Bootloader] LK for Xperia T
LK for Xperia T LT30p Only - Unlocked Bootloader Required WARNING 1: This modification makes changes to the devices partition table. I (lilstevie) am not responsible for any damage to your device or data loss that may occur. WARNING 2: ICS...
forum.xda-developers.com
EFIDroid
EFIDroid is a easy to use, powerful 2ndstage-bootloader based on EDKII(UEFI). It can be installed one-click with the EFIDroidManager app. You can add/remove/edit multiboot ROM's. There's no special support needed by ROM's or RecoveryTools(no...
forum.xda-developers.com
The developer of EFIdroid stopped developing in 2019.
efidroid on Android 9 and 10 devices ? · Issue #152 · efidroid/projectmanagement
Hi, I just want to know if efidroid supports devices with 6 GB RAM and 64/128 GB Storage devices running Android 9 and Android 10 ? thanks.
github.com
Not to mention you would need OEM's to cooperate....
Thanks @karandpr for that github comment a lot of info there. Thanks @galaxys too. So a quick summary would be that the reason is that for the bootloader to work smoothly there has to be support from the kernel too, which the OEMs should do and probably would not. But I didn't think about the support in the kernel was an issue. That does seem to be a lot of work and I see the reason now.
al_l_en said:
Thanks @karandpr for that github comment a lot of info there. Thanks @galaxys too. So a quick summary would be that the reason is that for the bootloader to work smoothly there has to be support from the kernel too, which the OEMs should do and probably would not. But I didn't think about the support in the kernel was an issue. That does seem to be a lot of work and I see the reason now.
Click to expand...
Click to collapse
I don't think Google intends to open up android anymore. They want restrictions like iOS but pretend to be open source for the "goodwill". What's the use of AOSP if you cant effectively install it on a device or your important apps don't work?
I believe PinePhones are the ones that can have truly open-source compatible hardware. The specs are underwhelming but the community is really good.
You can get spares easily and the battery is removable.
Only thing is they are mostly out of stock.
karandpr said:
I don't think Google intends to open up android anymore. They want restrictions like iOS but pretend to be open source for the "goodwill". What's the use of AOSP if you cant effectively install it on a device or your important apps don't work?
I believe PinePhones are the ones that can have truly open-source compatible hardware. The specs are underwhelming but the community is really good.
You can get spares easily and the battery is removable.
Only thing is they are mostly out of stock.
Click to expand...
Click to collapse
Yeah those are great but the problem is that they are not usable for "normies" which will prevent mass adoption and hence cannot have a sustainable business model.
But I think google is not the only one to blame, like couldn't the OEMs actually provide bootloaders that can boot signed os images. Or is there any technical or security difficuties in doing that.
al_l_en said:
Yeah those are great but the problem is that they are not usable for "normies" which will prevent mass adoption and hence cannot have a sustainable business model.
But I think google is not the only one to blame, like couldn't the OEMs actually provide bootloaders that can boot signed os images. Or is there any technical or security difficuties in doing that.
Click to expand...
Click to collapse
Normies are afraid to change the default browser, so bootloader is really out of their leagues.
Phone tinkering is a hobby, not a necessity. Phone tinkering itself is not a sustainable model.
Google is to blame primarily. Because they have a stringent list of requirements for devices to pass CTS. You can read the bootloader requirement and judge yourself.
Android 11 Compatibility Definition | Android Open Source Project
source.android.com
Without passing CTS, devices cannot use Google apps, they cannot get push notifications and they cannot pass SafetyNet checks used by most banking apps.
At the end of the day do I want to spend 100s of hours to bring a feature to an android phone which will probably be used by 10 users and deprecated by the time I finish doing it?
or do I want to buy a phone which will allow me to tinker freely in a community and ecosystem which allows modification?
For our tinkering pleasures, Pinephone is the way to go for now. They have support from Manjaro, Debian and KDE. Which is a big thing IMO.
Or else there you can roll your thing in RaspberryPi?
While going through related details I found an article about google probably switching to hardware based safetynet checks which could be ending google play compatibility on custom roms.
It really seems like google is using security as an excuse to make sure that there are no competitors in their business space.
Maybe this is because I have been only doing web development and only started learning app dev, but the reasons google use for CTS like for enforcing DRM, is also handled on websites while allowing openness and being neutral (or maybe the web is not as secure as something like this, so forgive me if I am wrong). Android could really take pages off the web ecosystem for being a neutral platform.
I really appreciate the patience for hearing out and also the references(and the rabbit holes that it was followed by) really taught me a lot about general android architecture.
al_l_en said:
While going through related details I found an article about google probably switching to hardware based safetynet checks which could be ending google play compatibility on custom roms.
It really seems like google is using security as an excuse to make sure that there are no competitors in their business space.
Maybe this is because I have been only doing web development and only started learning app dev, but the reasons google use for CTS like for enforcing DRM, is also handled on websites while allowing openness and being neutral (or maybe the web is not as secure as something like this, so forgive me if I am wrong). Android could really take pages off the web ecosystem for being a neutral platform.
I really appreciate the patience for hearing out and also the references(and the rabbit holes that it was followed by) really taught me a lot about general android architecture.
Click to expand...
Click to collapse
Theoretically, Google can end GPlay compatibility on Custom ROMs anytime they wish. It's just that lot of App Developers don't use SafetyNet the way it is intended and Google doesn't roll out its strict check. They do it once in a while.
They don't have any competitors in their business space. It's a very well-thought monopoly.
CTS restricts Google Play API access to vendor operating systems. So vendors like Samsung, OnePlus and others have to play by their rules. IIRC, the cost of Play API is around 15$ per device but it is subsidized for large quantities.
End users don't really care about Play API. But App Developers do.
Without Play services, there is no easy way to integrate push notifications, ads, maps, analytics, metrics, and so on. Rolling your own thing will take years to develop and won't work as seamlessly as the play service counterparts.
I don't think Google will ever cede their monetary interests for open collaboration.
karandpr said:
I don't think Google will ever cede their monetary interests for open collaboration.
Click to expand...
Click to collapse
Yeah that's for sure. The only way this monopoly can break is when an opensource alternative to google play services and other apis exist and while doing that it must be compatible with the existing google apis. And that is probably not going to happen in a long time. Although microg does solve this to some extent, but still it is a second citizen.
Some of the functionality is already there, like most of the google apps like docs and drive could replaced by nextcloud and then maps could be replaced by osmand. If some company, preferably an OEM, comes and integrates all of these into a package maybe there's hope. I think /e/ os tries to do this to some extent.
You might find this resource useful. As they have gone over a comprehensive set of bootloader software and tried to outline their primary features in detail. Hopefully, you’ll be able to determine the best one for your use case. https://www.ubuntupit.com/best-linux-bootloader-for-home-and-embedded-systems/