Android without the mothership
1–10 of 167 posts
Re: Android without the mothership
#2Many apps are open source (e.g., github, wordpress, coinbase, 2FA apps compatible with many services) and so are available through f-droid. Others, like TextSecure are really easy to build from source and install.
I have occasionally downloaded apps through one of the APK downloader services mentioned in the article comments -- I've had mixed luck. Some work flawlessly, others don't work at all without the google apps.
It would be awesome to see Mozilla's location service [0] integrated into Cyanogen to replace the google location services (which are of course disabled if you don't install google apps).
Re: Android without the mothership
#3Re: Android without the mothership
#4Re: Android without the mothership
#5Like seriously, no swyping in aosp keyboard? so i install google keyboard, then i might as well have everything. one piece of proprietary software from google, might as well go all the way.
Though i still get most of my apps from f-droid and will use an open source alternative if its as good or better. example: i prefer cyanogenmod gallery to google+ and vlc to google music, poweramp
Re: Android without the mothership
#6Re: Android without the mothership
#7I used to run without any google play services and running pure aosp. I stopped because Android is just so much better with google and fuck it, who cares about me any ways. Not to mention compiling aosp is a pain. Like seriously, no swyping in aosp keyboard? so i install google keyboard, then i might as well have everything. one piece of proprietary software from google, might as well go all the way. Though i still g…
Re: Android without the mothership
#8Re: Android without the mothership
#9Also, the article glossed over an important issue; the need to use closed-source proprietary binary blob drivers to make the hardware usable. With drivers running in kernel space, the potential damage of an intentionally or unintentionally bad driver is pretty much unlimited.
The most problematic drivers are usually the graphics drivers due to complexity and their impact on both system and battery performance. Since the companies making the graphics chips (well, they're often just graphics cores within the main processor IC rather than separate chips) like nVidia, Qualcomm, Arm Inc (mali), and Broadcom (to a lesser degree lately) refuse to release the documentation necessary for open source hackers to write drivers, tons of unnecessary effort is wasted in attempts to reverse engineer the binary blob drivers so open source drivers can be written.
There are quite a few efforts under way to produce open source drivers for various graphics "chips" on various types of ARM systems. Here are a few links I've collected:
http://bloggingthemonkey.blogspot.com/
https://github.com/grate-driver/grate/wiki
https://github.com/laanwj/etna_viv/wiki
http://www.raspberrypi.org/a-birthday-present-from-broadcom/
https://news.ycombinator.com/item?id=7320828
I haven't seen anyone succeed in making a fully open source blob-free phone yet, but people are working towards that goal.
Unfortunately, even if open source devs eventually solve all of the blob driver (and chip documentation!) problems, there will still be an unknown, untested, and unaudited chunk of code running on phones that cannot be legally altered; it's the baseband processor.
http://en.wikipedia.org/wiki/Baseband_processor
Since the baseband processor controls the radio(s), it's actually against the law (FCC in the US) to modify the broadcast/receive power levels or frequencies. As such, each baseband processor has to be tested and certified by the FCC, and any change means it has to be tested and recertified again.
Re: Android without the mothership
#10I am wondering how long it is before we see an effort to do to Google Play Services what Google did to Java - copy all the APIs and create an independent alternative that lets you build apps that use features from Play Services, without tying your app to Google. Ideally one can then choose what to do from just stubbing them out, filling them with 3rd party alternatives, or providing custom implementations. I would th…