That’s fantastic. Does this help with the issue of Google releasing AOSP security updates at a slower cadence? Maybe working directly with an OEM resolves this?
I don’t really know how this works, but if they have the cooperation of an OEM they should have the same access to AOSP security updates the OEM has, and access to hardware drivers from a company that’s not trying to thwart them. I can see how this would be preferable to a basically antagonistic relationship with Google, who are making things difficult because they want all Pixel phones to run their stock OS. The thing I wonder is what motivates the OEM to continue a cooperative relationship with Graphene OS.
That’s exactly my understanding/ thought process as well. I was wondering the same in terms of why an OEM would cooperate, and my first thought was the increase in hardware sales. I’m not sure how big the market is, but I know the security crowd will flock to them if they’re partnering with GOS when that market share would have previously been Googles. I’m not sure how big that market is or if the ‘juice would be worth the squeeze’.
I wonder whether there’s some shared development agreement too. Perhaps the OEM stands to gain some software improvements for its own non-Graphene devices, or perhaps Graphene OS will become its mainstream offering. There has to be more to it than picking up the small percentage of customers who shop for privacy.
Because people want to use apps, which unfortunately don’t exist on the Linux mobile projects. Banking apps are the biggest issue in fact. Obviously for a lot of other things, anyone can create alternatives.
And the whole issue of not being able to use most modern hardware with mainline Linux kernel because the drivers are closed source binary blobs. You have to use a device-specific kernels.
That’s fantastic. Does this help with the issue of Google releasing AOSP security updates at a slower cadence? Maybe working directly with an OEM resolves this?
I don’t really know how this works, but if they have the cooperation of an OEM they should have the same access to AOSP security updates the OEM has, and access to hardware drivers from a company that’s not trying to thwart them. I can see how this would be preferable to a basically antagonistic relationship with Google, who are making things difficult because they want all Pixel phones to run their stock OS. The thing I wonder is what motivates the OEM to continue a cooperative relationship with Graphene OS.
That’s exactly my understanding/ thought process as well. I was wondering the same in terms of why an OEM would cooperate, and my first thought was the increase in hardware sales. I’m not sure how big the market is, but I know the security crowd will flock to them if they’re partnering with GOS when that market share would have previously been Googles. I’m not sure how big that market is or if the ‘juice would be worth the squeeze’.
I wonder whether there’s some shared development agreement too. Perhaps the OEM stands to gain some software improvements for its own non-Graphene devices, or perhaps Graphene OS will become its mainstream offering. There has to be more to it than picking up the small percentage of customers who shop for privacy.
They’re extremely talented in the security/mobile/os arena, why not contribute to one of the Linux mobile projects and kill two birds?
Because people want to use apps, which unfortunately don’t exist on the Linux mobile projects. Banking apps are the biggest issue in fact. Obviously for a lot of other things, anyone can create alternatives.
And the whole issue of not being able to use most modern hardware with mainline Linux kernel because the drivers are closed source binary blobs. You have to use a device-specific kernels.
Waydroid exists but agreed, shouldn’t be a permanent fix, but it’s a valid step
That solves apps, but partially - I don’t think WayDroid passes Google Play integrity?
Still leaves us the driver issue, for which I blame Qualcomm mostly.