Earlier quoted context omitted.
Only if apps don't matter to that target user base. Most people will probably not want to go without Facebook, Instagram, Snapchat, Pandora, Netflix, etc., and devs won't build for a small user base (just ask Microsoft or Blackberry). A Google-stripped Android phone would at least be able to run Android apps.
How many of those apps actually run without Google integration, though, and how many will continue to in the future? Google's moving more and more core functionality into their proprietary components.
Android without the mothership
81–90 of 167 posts
Re: Android without the mothership
#82I 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
#83Android is a lost cause, all the man power being donated to the project is just going to line google's pockets and lock us further into closed hardware and barely opensource phones. The only future is a real linux phone, debian or ubuntu mobile, where one day there will be effortless desktop/tablet/mobile unified development. Why push for developers to waste time porting between c++ and java?
Re: Android without the mothership
#84If this is something Hacker News users value, please consider contributing development time (or money) to the Replicant Project http://www.replicant.us/
Re: Android without the mothership
#85Earlier quoted context omitted.
What would be really nice would be seeing a language-agnostic device. Based on linux, with the same APIs available to everyone, so that as on desktop linux, a thousand languages can bloom, and everyone can use the development language of their choice (including yet to be invented languages). GUI bindings would be the issue here of course, but it is not insurmountable. It's a shame that the software landscape is so do…
Great idea! It would make sense to define a high level yet minimalist type system, a large standard library, and a CPU independent bytecode format that many languages and compilers could target. They could then add to that basic type system as they wished whilst still retaining interoperability. We could call the infrastructure that makes this possible ... a virtual machine: http://en.wikipedia.org/wiki/List_of_JVM_l…
Re: Android without the mothership
#86Earlier quoted context omitted.
It seems to me only a matter of time before the incentive to create this gets high enough that someone actually does it. Yes, but it might be just another big company which does it, and in an 'all or nothing' fashion. In that case you would have a choice (Google or XBigCorp), but I'm guessing you really want to be able to mix and match, and have different parts of the Play APIs served by different apps/daemons/compan…
People have done this stuff for free. GNU/Whatever/Linux itself is a clone of some existing APIs. Wine, reactos, while being far from complete, attacked a far larger API and also a big moving target. It's doable. By amateurs and professionals with passion and spare time.
Re: Android without the mothership
#87Earlier quoted context omitted.
I keep looking for a lighterweight alternative to OwnCloud for Calendar/Contacts. I really want to switchover to a proper CardDav/CalDav setup that actually supports "Tasks" in my calendar, exactly how Google doesn't and continually fails to.
I'm also eager to drop ownCloud ('pwnCloud', I keep hearing), but I think I'll replace it with Seafile + Fastmail's CardDav/CalDav. CardDav is not yet available but promised soon. I wish there were a trustworthy source of prebuilt pure AOSP ROMS, like the source images Google release. Compiling them is no small feat and I'm worried I'll brick my device. With a stock AOSP ROM + Fastmail contacts & calendaring, I think…
What's wrong with Cyanogenmod? They even provide a dead easy installer which unlocks the bootloader, changes the recovery and then flashes the ROM. And they support a good number of devices out there.
Re: Android without the mothership
#88I 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…
> [...] 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. From http://en.wikipedia.org/wiki/Replicant_(operating_system) : > Replicant is a free and open source operating system based on the Android mobile platform, which aims to replace all proprietary Android components with their free software counterparts. So I…
NOGAPPS on the other hand, is an attempt to replace Google Play Services while keeping API compatibility so that apps continue to run.
Re: Android without the mothership
#89Earlier quoted context omitted.
Google is moving more and more core functionality into their proprietary services . A different more open operating system is quite irrelevant if google services are needed for the phone to be...you know...useful.
The 240000+ applications in the Amazon App Store that work without Play Services show that this is not a problem. Both Microsoft's Nokia X line and Amazon's Fire Phone are useful phones running Android without Play Services. Those are just examples in the west - many devices sold in China run Android without any Google stuff on them.
Re: Android without the mothership
#90Earlier quoted context omitted.
Any reference in Java can be null, as is the case in most languages. So developers only check the ones they know "could" be null, in normal operation. If you only distribute your app via the Play Store, attempting to access it will never fail, thus there's no more point in checking for null pointers than there is in checking the result of String.split: it will never fail, short of something wacky and unexpected like…
> So developers only check the ones they know "could" be null, in normal operation. Not the good ones. Normal operation isn't when you're dealing with a mobile device, there could be any number of reasons why your app can't reach a certain service delivered by some API so better to be prepared for that eventuality.
You have to balance the tradeoffs of bloated code and pointless error checking with adding features and improving the program. The more error checking code one writes the more one must maintain and the higher the potential for bugs.