As described by @JeroenH already: The blobs are for drivers and other functionality and has nothing to do with Google.
This is only “half” true, but hard to track down. If you compare the software licences … (something that is not debated here a lot) … the bin blobs even for the “non-Google” FP2 have the same “Google” licences as other Google phones, wording-wise. So I think in the background, Google with their CTS program … is still “pulling” the strings and making such a licence mandatory. Such as the “Mobile Application Distribution Agreement”.
But this is just a guess based on how all the licenses are written. Just check yourself.
Else, I agree with you. Google should not care about the bin bobs. But funny enough all Google roms and bin blobs are “protected” by the same license.
I guess as a vendor you can either open source your driver … or go under the “Google” umbrella. This makes it easier for multiples vendor to agree on the same (=most strict) licence so Google is able to pack the roms at all, I guess.
@fp1_wo_sw_updates, I don’t quite understand your post. You might have some key parts of the release process wrong.
Google doesn’t pack the ROMs. The manufacturers pack and release ROMs. Google is only involved in releasing Android source code and maybe testing whether the ROM complies with their license if the ROM includes their services.
I’m sure I do. Thanks for helping me. The problem is, that this process is not described anywhere. I think it works like this:
- There is a ODM that has a contract with a SoC manufacturer.
- This ODM designs a device together with the client based on the SoC manufacturer he works with and the clients ideas
- The ODM agrees to NDAs with other hardware vendors to add non-SoC manufacturer hardware.
- The ODM builds a roughly working Android version and ships it to the client (and Google if wanted for their services)
- The client again modifies the code again if needed (and shipped to Google for testing if it comes with their services)
- The phone and the ‘Google-tested’ code/rom is shipped.
The funny thing is, if you compare licences (for the bin blobs, even for the non-Google code) all the Android/bin blob licences look the same. This text comes from Google. Without this text and licences, you will not get a “powered by Android” device.
But you are right … all this stuff I’m just assuming because not a lot about it is published.
Google is not really my problem. It’s the license and that nobody really knows anything about the bin blobs. What I dislike in the end is:
- There is no Changelog for the bin blobs (Who “packs” those? Is it the ODM, FP?)
- There is no way to switch to more stuff from the mainline kernel, even if features are supported because the ODM prefers an older version that works better for them and the other vendors (as far as I understand the whole thing)
- You cannot offer fixed roms for ‘free’ to others or experiment with different setups, build roms is a big waste energy.
- The OpenOS rom build is left behind, but in reality, it is the “better” rom. It could also be much easy to debug (if the code/debug settings would be shared).
I don’t know the details of the process either (and we are getting off-topic in any case).
The parts I (think I) do know are:
- Google releases Androide source
- SoC manufacturer adds SoC specific changes (this is Qualcomm in our case)
- ODM* (this is Hi-Pi and/or Fairphone in our case) gets source and license from SoC manufacturer to adapt this to a device.
- The source includes open parts (e.g. AOSP code) and proprietary binaries (e.g. device firmware).
- A working Android ROM can get built from this (e.g. Fairphone Open OS).
- CTS tests are part of AOSP and this ROM can be tested against CTS.
- ODM agrees with Google to license Google Services.
- ODM packs Google Services with ROM (e.g. Fairphone OS).
- This ROM gets sent to someone to run a separate set of tests to verify that the build complies with the license Google gave to include Google Services.
- ODM releases ROM as an update.
*I guess this means original device manufacturer. I use it as if it means this
Regarding the license: I wouldn’t read to much into that. Just because someone releases code under an Apache license does not mean that the code is owned by Apache. Just because someone releases code under a MIT license does not mean they are researchers at MIT. Just because someone releases code under a Mozilla license … you get it.
(and you keep on updating your post while I’m answering it )
It doesn’t matter who packs those. Apparently Fairphone cannot or must not look into them.
There is a way. Only, it is a lot of work to rebase the code.
I’ve always argued on the forum that community members that build should just share their stuff. If someone really has something against it, those parties will let us know. I deem this very unlikely.
Why is it left behind. Doesn’t it get all the bug fixes and releases as the other ROM?
Thanks, that looks pretty good. I agree I’m sorry for the updates, I tried to make myself more clear.
For Qualcomm? I think QC and Sony have already done this for the Snapdragon line. Or are you talking about FP (the software from Portugal/launcher) or the other bin blob vendors?
This would mean they wouldn’t be able to debug issues without the ODM.
I’m not going to test this, not under this licence. The code builds here for me. And it’s easy enough for me to fix the small “different versions of software” glitches that occur.
I hope so. I’m talking about the release of the OpenOS rom. It’s published later, but it is the “easier” part (no google tests needed) and the code is already “there”.
Update for the on-topic-context: Just to get back to “convergence” … I think a lot of the “thin client” code for smart phones is proprietary and if at all … lives somewhere at the SoC/Graphics level with some DRM. The best solution for a working “laptop-phone” would be a open graphics unit that is able could exchange data quickly through an unrestricted interface. This is something most content sellers will not like.