Long-term (1-2 years or so), keep an eye on Fuchsia. Nobody yet knows what Google's intentions are with this project relative to Android (which has a staggering installed base, btw, and is going to stubbornly stick around like a slightly less terrible Windows Mobile 6); right now it's just a research project. But it can apparently scale from tiny IoT sensors to ARM phones to x86 PCs.
Also, downvoted to 0 is one downvote. Hardly worth getting upset over, there are plenty of people who downvote everything to try to move their post further up, and you're not going to get an explanation from them. All complaining will do is invite further down votes from people who don't like to see complaining.
The thing is that fixing security bugs in old Androids just isn't that hard. I'm not talking about making Samsung upgrade their Galaxy S3 (a five year old phone) to Nougat (which also isn't that hard, Cyanogenmod (before it was LineageOS) did it, and the hardest part (back porting kernel features) is done by a very small team IIRC), but fixing bugs shouldn't be so much work.
The issue is that there is almost zero benefit for Samsung to bother.
So how will Fuchsia help?
Maybe now Google will contractually obligate companies using Play services to upgrade for X years?
How long will X be?
Based on Google's own history, I doubt it's going to be longer than 2 years since "flagship release".
Now this made sense when you got free phones every two years, so must people just upgraded then (why not?) But now that you actually lay out $800 on a flagship phone, people are holding on too their phones for much longer (and there's not much of a reason to upgrade, unless you're playing heavy games, SGS3 is perfect).
But we may actually lose something: If Samsung/Qualcomm can close source their kernel, it's going to be tough to build your own "Fuchsia." So even if you're an expert and shop smartly, you'll still be at the mercy of your phone manufacturer (see Motorola and their promise).
I read a linked article on here recentlyish that made an interesting note about the impact of Google being an advertising company: Android is Google's effort to create a defense moat by blasting a 100-mile crater around their ad properties. They can't turn Android into Broadway or a popup factory, but they can carefully court the DoJ (who fired the antitrust case at Microsoft in the 90s) and creatively push the boundaries.
Looking at it that way, Google have little incentive to rock their own boat.
There's also some interesting ponderation to be had considering why Android BSP propagation/vendor branding works the way it does in light of the above. Absolute device control (aka a flagship device) is likely only an option for Google (and Microsoft, thinking about it!) because of the competition; in fact now I wonder how fine the line is that Apple's skating (although I imagine the competition is what keeps them going as well).
In any case, I see Fuchsia as Google's equivalent of Microsoft Singularity. I'm trying to figure out what kind of point they're making by developing it in the open; they've likely gone through a hundred similar initiatives internally, as did/have Microsoft. Although now I think about it, Google do seem to have some practical business/real-world targets to hit with this (IoT is the likeliest actual hit) so maybe they're just publicizing it for that reason.
Regarding the openness of the kernel, all I can do is hope like mad that the kernel generally stays open on production devices (in "end-user" mode), or that there's some sort of developer option (and hardware, if necessary) available. And I can only hope like mad that Google figured out and appreciate the massive value of an open device, and don't do anything monumentally stupid. Fuchsia has an open repository, at least, which is a very nice start.
Maybe not directly - my guess is that they want to get rid of the Linux kernel: the Linux driver model leaves Android upgrades held hostage by OEMs and SoC manufacturers who are incentivized against old phones getting OS upgrades (planned obsolescence).
With Fuchsia, Google has a clean slate and can choose to have 'write-once' drivers with a stable driver interface across kernel/version upgrades.
Writing once-off proprietary drivers for Linux is equally easy, no more, no less. Proprietary Linux drivers have the added downside of not supporting later kernel versions.
With mobile, as things are, you're guaranteed to have a bunch of proprietary drivers. With the Linux kernel, all the modules need to be the same version of the kernel because you can't guarantee that the interface hasn't changed. Contrast that with Windows, where the same driver file will install and work with a wide range of actual Windows kernel versions.
If Fuschia provides a stable driver interface, then it would mean that my 5-year-old phone doesn't need to also use a 5-year-old kernel to interface with its closed-source drivers. It'd be a big win, overall.
That seems like perfect being the enemy of better. The realistic options aren't "stick with current model of closed drivers locked to specific version of open kernel" and "force hardware manufacturers to produce open drivers". That second one isn't going to happen. The best you'll get is an open shim and a closed blob.
It's a retreat. It could have happened. The ground was ceded when closed source drivers were allowed to be willy-nilly linked into the kernel with impunity, a clear GPL violation.
The Free Software initiative requires bravery and confidence. The idea is that if you establish a large enough base of viral software, people will eventually have no choice but to become a part, or be put at great disadvantage. And it worked. Linux is everywhere. The only places it didn't work, are the places we were too cowardly to press the advantage.
Stallman was right. You cannot compromise. Once you start paying the Dane-geld, you'll never get rid of the Dane.
I'd agree if it wasn't Google we are talking about. With the Open Handset Alliance they certainly would have the power to force hardware manufactures to produce open drivers.
I agree that they'd have the power to do it. I don't think they have the motivation, though. It's a clear win for the customers, but a lot of work on their part that I don't think would translate directly to numbers on earnings reports.
> Nobody yet knows what Google's intentions are with this project relative to Android
Pretty sure one of the effects will be total inability to port Linux drivers to the platform in order to install different operating systems. Not saying that this is easy today, but still some degree of compatibility allows the creation of jailrooted environments.
A 100% OSS alternative to iOS and Android sadly won't be here anytime soon, surely not from the big players.
Fuchsia is not an answer to this question. It's exactly the same as Android. Android is technically open source as well.
Also, Fuchsia will never be an distribution or branded OS on it's own. It might replace the Linux kernel is some bigger operating systems. Could replace Linux in android or chrome but I doubt it'll be fully new standalone OS.
because quite frankly it's a change of kernel from linux god kernel to a mach type kernel, the android api on top does not change and in fact is the same android api
Am I the only one who has decided that I'm more comfortable with iOS and an AppleID than I am with something like LineageOS and still having to have a Google account - even though I prefer Android?
I'm operating under the assumption that Apple is more privacy friendly than Google under pretty much any circumstance.
I've done the Cyanogen + F-Droid thing and it's just miserably inconvenient, and none of the "proprietary" alternative app stores have any sort of catalog to write home about.
Biggest annoyance of Android are the millions of permissions which every app asks for and which allow perfect fingerpinting. Phone number, all device accounts, wifi access names, mac adress are some examples. I know that one can switch off those permissions with newer Android versions but thia is too much hassle for me.
And my second gripe with Android is the slow browser: Android's Chrome is much slower than iOS' Safari. Safari is as fast as Chrome on my Macbook.
Yes, same here. I'd use iMessage over WhatsApp or Duo (or whatever Google's chat du jour is called) any time. They do have glitches (like the recently exposed iCloud bug where private browsing histories were stored indefinitely), but I don't attribute them to monetizability.
I fully agree, but I still cynically wonder if there are no insolent companies out there who know that people believe in this sentiment and will make you play PLUS sell your info to 3rd parties.
I'm actually a user of LineageOS and I do not run the Play Store nor the Google Services.
I prefer to install everything with F-Droid failing that I use a Play viewer called Yalp that downloads apk's from the Play Store. The only app I ran into that fails to load is Hangouts (I use that for work). While Facebook Messenger shows an error when loading it doesn't crash when using it. Yalp will ask for your Google credentials, but I also saw that it also has a fake account mechanism.
My only other complaint is that by default the ROM comes with a couple non-free apps like Br0Zip that is quite obnoxious and you can't uninstall. I could re-flash my device and remove the app, but that's just annoying. If anyone from LineageOS is reading this please remove this ridiculous app.
Honestly though I'm just happy that I'm running an OS that's open source at it's core and that I have access to an app store that exclusively hosts open source applications. It even warns when apps promote non-free software (like Yalp).
PS: I'm not saying you're wrong, but that I've had quite a pleasant experience.
No, same here. Tried the Cyano-Fdroid route as well and came to the same conclusion. Even tried not using a Google account but even free apps are often dependent on the Google servers.
We need hardware that doesn't need to get upgraded every two years. AOSP doesn't cut it since Google inevitably stops building isos for their hardware and the community can't support a million devices. The whole market is sorely in need of generic drivers. The fact that I can pick up a PC from the nineties and install an up to date Linux proves that we're not there yet in the mobile world.
Is there a way currently to install baremetal Linux on a phone without emulating it? A small Linux, usb microphone and VoIP would get me 90% there.
If anything the open source community is a lot better in supporting large numbers of devices than closed source has ever been. Witness the incredible hardware support in your average linux kernel. The only reason they're a bit behind the times is because hardware manufacturers are loath to open up their specifications to open source implementers.
> The fact that I can pick up a PC from the nineties and install an up to date Linux
As someone who still has an HP Touchpad, the unfortunate pattern of AOSP / Cyanogenmod / LineageOS support is the following:
1) One volunteer spearheads the development effort towards keeping phone/tablet/device X supported.
2) Various other people draw on the 90% base work already done by Lead #1, add their own wrappers, tweaks, etc, such that the community on the whole appears to be vibrant and bustling around development for device X.
3) Lead #1 eventually stops supporting the project because he gets a newer device.
4) None of the developer's behind Lead #1's forks have sufficient technical knowledge to continue the base development without him, and all of their forks stop updating as well.
5) Community on the whole for Device X fizzles out.
I've seen it happen multiple times on XDA-developers forums. That dozens/hundreds/thousands of people are using an AOSP-based ROM on a device does not mean that the community necessarily has the technical knowledge to continue it without someone to steward the project. The volunteer leads do an incredible job, but at the end of the day, they usually only last as long as the device is the lead's daily driver--after that, they usually stop.
> The only reason they're a bit behind the times is because hardware manufacturers are loath to open up their specifications to open source implementers.
Not entirely true. The mobile hardware ecosystem is vastly more diverse than the PC ecosystem.
For starters, there was never any cloneable, de facto standard (a la IBM) thus everyone started from divergent designs.
Add in the limitations that PCs never had to deal with (miniaturization, power, cellular radio integration) and you rapidly get each company integrating things as quickly as possible so they can get a product to market.
And honestly, there's not much reason support clean code underneath the hood. 99% of your customers will never flash a custom ROM, much less change the OS. If your stuff works, and you've got the time for a rewrite for the next model, full steam ahead with business as usual.
> Is there a way currently to install baremetal Linux on a phone without emulating it? A small Linux, usb microphone and VoIP would get me 90% there.
Unless the SoC drivers are mainlined, you won't be able to upgrade your kernel on such a device. This is precisely the same issue with Android where people mistakenly blame Google instead of Qualcomm (driver authors) for the lack of Android upgrades.
> This is precisely the same issue with Android where people mistakenly blame Google instead of Qualcomm (driver authors) for the lack of Android upgrades.
The same principle technically applies, but when the SoC developers, kernel developers, and OS developers are all in the same company they don't really have the same problem.
With Android you have the Linux kernel team providing the mainline kernel, the SoC team providing the drivers, and Google providing the rest of the OS.
If the SoC team don't care about mainlining their drivers then those devices will only ever support the kernels that the SoC vendor releases packages for.
If Google wants to move Android along to a newer kernel and the SoC vendor isn't playing ball it comes down to hacks that may be acceptable in a community ROM but I wouldn't want to support in a commercial device.
Drivers, couldn't have said it better, someone needs to shake up how drivers are being handled right now by phone makers.
Great point about how PC hardware can always be expected to be generic enoughthat we can just install Linux on it and not have too much trouble, yet there is no equivalent for phones, but there really needs to be.
When IBM did that it made Microsoft rich instead of IBM. I bet phone manufacturers aren't eager to repeat the blunder. In other words it seems like there needs to be an open source hardware effort too.
I'm personally using LinageOS together with microG and F-Droid. MicroG is necessary if you don't have Google apps installed, to get push notifications. Unfortunately, it is still rather complicated to install.
I use lineage, but not microg. Things like Conversations poll effectively enough and it keeps me off the Google.
I feel like this isn't a solution for the planned obsolescence inherent in mobile devices though. Every release after Google officially drops support (and provides their own image) gets exponentially harder. The amount of things moving out of AOSP and into Play services grows every month too.
Conversations keeps open a TCP connection and the server pushes new messages. The only kind of polling is a ping to keep the connection alive which can be scaled based on how often it proves to be necessary on that connection. It works the same way as GCM. GCM isn't inherently more efficient than an app doing it, but with GCM it's one connection across all apps using it for push vs. each app doing it on their own. Conversations is also one of the few doing it very well without GCM. Most have a much lazier implementation of push or worse they don't do push at all and really do poll.
Thanks for the update and sorry for the misinformation. The performance is much better than the few apps I've seen advertise "non-GCM" so I definitely believe it.
I wouldn't say its complicated. Just have to patch with https://github.com/ale5000-git/tingle after every update to keep the fake google signature working.
Just install F-droid using the apk from the official site, add the repo [1], refresh the package list if this was not done automatically by F-droid, and install GmsCore along with GsfProxy in F-droid.
The alternative is Android. Unfortunately the "alternative android" ecosystem isn't very good.
My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device". WOuld work more like a linux distribution (packages and updating) and is generic over a variety of phones. Challenge is probably how to handle drivers.
> My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device".
LinageOS is the successor of CyanogenMod, they just started a few months ago.
The website and everything else is still new and very much work in progress. I guess their main focus was getting up the core infrastructure before making a cute website.
At the same time, saying "This is who we are, this is what we're doing" is pretty important. It's not part of a "cute" website; it's part of a functional and informative one.
With what? Typing up a paragraph on the homepage that says "HEY CHECK THIS SHIT OUT. HEARD OF CYANOGEN? JUST LIKE THAT."
The lineage site is pretty garbage. It tells you nothing about it, and had I not been following the Cyanogen news, I'd have no idea what it is. It's literally impossible to figure out what it is from any page of the website.
No. Just no. This is not one of those, "You're welcome to contribute" things. This is one of the most basic things to have, and for them not to have it reflects extremely poorly on them. This is like not having the build scripts. So do not try to spin it. They very rightly should be criticized for not having that.
This is why (just like for any other OS) you buy a device with explicit support. You don't buy a random laptop and then complain why macOS doesn't run on it... do you?
It's not exactly the same, though. You can buy a random laptop and throw Windows on it, even if it's not the version it shipped with. You can throw Linux on it, and it will almost certainly be usable; sound may not work, it may not resume from suspend, and graphics may be unaccelerated, but if will basically work.
If you're buying a new device, then yes, certainly you should shop for one that's supported on LineageOS or OmniROM, or whatever. But one of the uses of custom ROMs has been extending the life of older devices, and that ecosystem is very spotty.
"Sound may not work" and "but it will basically work" being in the same sentence is more-or-less why Linux is still not yet ready to take on Windows and OSX in the desktop space.
What you're describing is similar to the situation with mobile devices, only to a lesser degree. Turns out, making an OS run on hardware is challenging and under-appreciated work, and continuing to gloss over the complexity of it doesn't do solving the problem of open-source OSes any favors.
The problem you are describing is at once intractable and a solved problem. Most oems are at best ambivalent about Linux support. If you are lucky they provide enough documentation for volunteer labor to support their hardware otherwise someone has to for free spend their time reverse engineering their pile o' hacks.
Since there isn't an inexhaustible well of free labor to throw at other peoples hardware there will always be some hardware that either doesn't work right or doesn't work right out of the box because it requires fix foo that is only available in version bar that is the very latest that hasn't made its way into the stable version yet. If you run a bleeding edge distro you may find that you have the needed version of bar but they broke something else!
The solution is to buy hardware with the OS you intend to run in mind. If you are just curious about whether linux might be useful to you the easiest thing in the world to do is try it out either via live usb or virtual machine. If indeed you would like to run linux and it doesn't work with your existing hardware just buy with Linux in mind when you get your next machine.
Instead of asking whether linux can meet the impossible standard of running flawlessly on any pos you happen to throw at it ask whether there exists a reasonable range of hardware that meets your needs and expectations.
If you approach it that way you will most likely be satisfied.
That's basically my approach; when I want to run Linux (because the applications that run in Linux are useful for a wide range of things, and I'm very used to the command line), I tend to run it in a VM alongside / atop the Windows or OSX install that the hardware I'm using boots to.
The exception I regularly hit is raspberry pi, but in that specific case I (a) don't actually expect anything to really "just work" out of the box (the whole point of the platform is to hack around on it) and (b) I'm not trying to use it as my primary development / work / games / day-to-day environment.
If that sounds bad, then wait 'til you hear about Apple's situation - they don't support custom hardware, at all. Not only does sound not work, nothing works. Linux is a step above macOS in that it not only does it work very well when it ships with a computer, it also still works ok when you load it on any other computer. And yet, macOS has more users than linux does... Perhaps support on random computers is a bad metric for the readiness of an OS?
It is exactly the same. I put Windows 10 on an older Dell laptop. It mostly works, but it's not "supported" and I get blue-screens once in a while. There's just no practical way to keep supporting arbitrarily old devices, even for a company like Microsoft.
If it's exactly the same, I will hand you an unbranded phone with no OS and see if you can get Android running on it. The only machines you can't get Windows running on right now are Chromebooks, so 99% of personal computers will let you pretty easily install Windows in exactly the same fashion you would on any other computer. It might not run well, but it will certainly install. If it's exactly the same, do that with Android on any random phone.
Generic drivers have made explicit support mostly unnecessary in the desktop space. This doesn't exist on mobile. I've installed Linux effectively on many many pieces of junk whose designers never intended their hardware to be used that way.
I recently tinkered around with putting LineageOS onto a Samsung Galaxy S3. It was super easy to do, and is a really clean, fast, and efficient operating system. I personally enjoy it. I had previous experience with Cyanogenmod, and LineageOS is way better.
Unfortunately, I've got an S6 as my daily user phone, and there is currently no stable version of LineageOS that supports the S6 (as far as I'm aware).
Isnt Google's Fuchsia the project to tackle this very problem?
On the other hand it has potential for even more 'closed source'-ness on the handset manufacturer side of Android. And maybe even for other industries, once its market share rises.
Right, the monolithic images make sense for the phone manufacturers who want to update a lot of identical devices. Much less for the individual, who wants to install a distribution on their device (which e.g. might no longer be supported by the vendor).
I always found it wierd that people talk about "flashing" "ROMs", like it's firmware. It's not, it is under the hood not too different from installing a desktop OS on a hard disk (except you can't pop in a USB drive, you have to use a cable and ADB).
The (e.g. CyanogenMod) ROMs for different phones are not too different. In principle, you could wrap something around ADB that "flashes" (well, copies) a base OS, and then the needed drivers / radio / apps per model.
Also wierd that you can't easily replace individual components. If I want to make a change to a base package or the kernel, I have to reflash everything, instead of replacing one file (well, you can yourself, but nobody in the scene offers that).
For me, a very interesting option at the moment is Sony's official AOSP builds for a number of Xperia devices[1].
You're able to build an image yourself from their source if you'd like slightly more comfort, and can run it without gapps if you're privacy or software freedom conscious.
> My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device".
While drivers are supplied as binary blobs, this will be impossible.
And kernels, and random software the drivers require, and special snowflake bootloaders, ...
I'd love to see it, but considering how long it took desktop Linux distibutions to run semi-reliably on most PCs which have far fewer hardware differences and important components without even partially reverse engineered specifications, I'm very suspicious this is a feasible way forward.
However, the base it runs on - Mer - is open source, and there is an alternative open UI (Glacier UI). Unfortunately this further limits the applications that can run on it.
By the way, the phone runs a real Linux distro. There's Wayland, OpenSSH, bash, systemd (ugh...), RPM's, and a ton of good old commandline software like htop, tmux, python, - heck, even gcc if you feel like rebuilding the kernel :) Native apps are built with Qt & QML. There's very little NIH.
There's also support for Android apps. Many of the apps from F-Droid run OK, and even lots of commercial stuff.
Oh, and the phone is pretty fantastic for all the normal everyday things, like being an actual phone.
It's somewhere on my TODO list :) I make a "f*ck you Krzysztof" app for every new phone OS I get: there's one for J2ME, Android, now gotta learn myself some QML... Krzysztof is not very amused.
Willingness and ability are different things. Samsung never tried to push Tizen on mobile phones.
Samsung put itself in a position where the company simply cannot walk away from Google, at least in the mobile space (Tizen is actually pretty "mainstream" in smart TVs and wearables). Market shares are pretty much set at this point, and no alternative mobile OS based on linux has a chance to become mainstream, no matter the size of the company backing it. That doesn't stop a small company like Jolla from delivering viable products though, since they don't need to keep Google happy.
IMHO, with Russians being paranoic about western "spying" and Russians committing their code to upstream, it's likely that there will be something to see in a couple of years.
It looks to me that all Sailfish devices that have ever been available are not compatible with 3G/4G US carriers (but some are compatible with 2G).
It seems that if anyone in the US wants to seriously use Sailfish, they need to flash a community port of Sailfish to a US-sold Android device. Not a huge deal - it looks like a few manufacturers are actively supporting this ports (e.g. for the Fairphone 2): https://www.fairphone.com/en/2015/10/22/jolla-community-work...
The problem is that most of the hardware is not open. It is hard to get fully open software running in proprietary environments like mobile phones and networks. The fairphone might be worth a look though: https://www.fairphone.com/en/
"I've wondered lately what exactly "not open" means in the hardware context, and why so many manufacturers do not make "open" hardware."
What you need to understand is that your mobile phone is not a single computer. There are at least three computers inside your phone that have their own CPU, memory and ability to run code.
First, there is your SIM chip. Your SIM chip is a fully functional, standalone computer with its own CPU and memory. Your SIM card can (and does) run arbitrary java applets that can be forced onto it by your carrier without your knowledge. Yes, that is indeed as terrible and horrifying as it sounds.
Second, there is the baseband processor which handles all of the tricky real-time radio comms with the cell towers and which could not be preempted by your browser or other apps you would be running on the AP (see below). The baseband processor is not controlled by you, can be controlled by your carrier, and in many cases has DMA control over the memory in your application processor (what you think of as your "phone"). Yes, you read that right - many, many mobile phones can have their physical memory directly manipulated by a baseband processor that they do not control. Remember that next time some cute "secure" messaging/encryption/marlinspikey/secretive communications app gets released.
Finally, there is the application processor which is the "actual" CPU and memory that you think of as "my phone" which runs things like the uber app and chrome and facebook.
We are sort of, kind of, getting closer to having a free/open stack on the application processor only. There are two other very powerful agents in your telephone that we have made almost zero progress in opening up. There are very powerful financial interests that stand in the way of opening those up.
You could get rid of two of those three computers, could you not, if you went for say an iPod Touch, as opposed to an iPhone. And then separately you got a dedicated WiFi hotspot. At least this decouples those functions into two devices and breaks the DMA link that you referred to.
I've heard long ago that the government (or whatever agency is responsible for this) won't license you to produce a phone if you don't put a baseband chip in your device. Don't take my word for it, I'm only sharing a vague memory.
Sounds pretty logical though. As @rsync said, there are very powerful financial interests behind the hardware backdoors in phones.
>what exactly "not open" means in the hardware context
As natch said, lack of documentation. This lack of documentation prevents others from developing their own drivers etc.
>why so many manufacturers do not make "open" hardware
Multiple reasons. The first four of which I am confident that often play a large role, and the two last of which are more speculation.
1. Companies might feel that open hardware would put them at a disadvantage because others could copy them.
2. Company might have licensed portions of the hardware from other companies and therefore must adhere to agreements about not sharing information about the licensed hardware with others.
3. Maintaining an open project is a lot of work for a company. Everything from ensuring that the whole process is repeatable, to having a team of lawyers approve everything for release.
4. There is no incentive. Users buy their phones either way, even if everything is closed and proprietary.
6. Company might be using software tools in the hardware development process that they can't share freely so even if they did share the files others still wouldn't be able to use the files for anything?
7. Everyone's hardware infringes tons of patents that they didn't license or even probably know about. Open source drivers and documentation will expose that fact and invite lawsuits.
Fairphone might be interesting, but it does not solve the problem of blobs, the open source part must come from the chipset providers and they are not that willing.
Exactly. iPhones are completely locked down, and with Android devices that best case is you can install Cyanogenmod or Lineage. They still package a giant binary blob from the manufacturer. You cannot install something like Ubuntu or FirefoxOS, so of course those died.
F-Droid is cool but will lack lots of applications, even open source ones. I recently checked what it would require to publish my app there -- alas, can't do that since my app includes an API key that can't be published (according to the rules of the service in question), and F-Droid would need that[1].
I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short:
If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information.
There are actually only two solutions:
1) Provide a way for the user (!) to enter API key or account information at runtime.
2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.
That's a very technical viewpoint. The API agreement tells not to share the key, which obviously does not mean you can't include it in the app binary. I interpret that as not being allowed to publish the key with the source code though.
That's pretty weird and questionable interpretation, since if I have a binary — I have the key, even if in some obfuscated form (even that isn't usually true with APKs though), but whatever, if it works for you — fine, then I have a solution to your problem.
Don't include API_KEY in the published source, include rot13(API_KEY).
You have to consider the intention of the service provider, which in this case is more geared towards mobile clients than web services. It's perfectly clear that binaries will include the API key, no interpretation needed on that part.
It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
I never developed an app so I dont know, but if you cant include in the APK because people can decode it, how do you distribute keys and secret strings?
You distribute user-specific secrets after a user has logged in over a secure channel.
You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
Yeah, BTW the good thing about these stores is that they install apps normally, by launching the system APK install dialog, instead of the rootkit-style thing Google Play does.
It uses special privileges to run the installation in the background. Google Play Services is frequently called a "rootkit" because of stuff like that.
You can build the app, and to make it functional you could request your own API key, so I think it satisfies the label. Requesting API keys as a regular end user isn't anywhere near being realistic though, so that's not an option for distribution.
From pawadu's response above it sounds like your app would satisfy the requirements if you have a build parameter or similar that lets them specify the key.
There's another discussion thread [1] which takes a strict stance more explicitly: "I don’t see how something that contains a ‘secret’ key [...] can be Free Software. So we just don’t publish such applications."
F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key.
LineageOS user here: This is the best Android distribution I've used, by far. I've used Paranoid Android, Slim8, Dirty Unicorns,... But none get to the level of featured and stability of LineageOS.
Extended per-app privacy settings, built-in root manager, lots of customization options... And the best of all: enormous community. There are builds for crazy amounts of devices.
The main problem with FOSS Android seems to be that your device has to be actually supported due to the myriad of cpu, graphics etc. combinations. I looked shortly for a tablet of mine which is completely workable but hangs at Android 4.2 - unfortunately there doesn't seem to be a CyanogenMod variant for it (so, probably no Lineageos either). The update story of Android devices is really sad ..
Thanks for the hint, will look into it. My current tablet is an old Huawei (Mediapad T1 10/T1-A21L). It was part of a promo action and does what I want (I mainly use it was PDF reader), but Android 4.2 gets old and security doesn't get better, so maybe time for an upgrade and this time something LineageOS supports.
This doesn't solve the problem, when asking for an alternative to Android. My issue with Android isn't just Google and privacy, but the fact that Android is pretty notoriously insecure at this point.
I've been carrying Windows but Microsoft just effectively announced end of life for the last two phones on my carrier.
Experience, incredible numbers of CVEs, arrogant yet meaningless statements from their security team over time which has convinced me they do not care. Lack of commitment to update distribution.
Heck, Fuchsia is built with a reasonable security model, most work on Android goes into making excuses for theirs.
At least if I'm carrying something obscure the likelihood of being targeted is low.
I don't have the time or desire to do what's required to securely operate on the Android platform.
Someone linked to two daily wtf on hn the other day and that to me shows tizen under the current management is not simply useless but actively harmful.
Code quality seems to be a large issue for Samsung in general (no sources, but some first-hand experience). My gut feeling is that it's caused by the extremely bureaucratic Korean corporate culture. Though I'm sure someone who has actually worked there could shed some light to this phenomenon.
What I found out only recently is that Tizen's UI uses Enlightenment's foundation libraries (EFL), which made me kind of interested in getting a device running it.
Samsung has a range of smartwatches and wearables that run full Tizen (Gear S2, Gear S3, Gear Fit 2).
You can install custom software on these devices, and even SSH in over Wi-fi (which sounds like a crazy thing to do on a watch!).
I made a native EFL app for the Gear S2/S3 that did ship (the client was an European airline). The tools are kind of retro (compared to e.g. Xcode), but they work.
The http://puri.sm people are trying to make an open source phone running their distro PureOS (based on debian). They even said on a podcast that they have removed or mitigated the binary blob issues. Apparently they are already working with Gnome developers to make Gnome work on a small screen and build the specialized phone software like a dialer.
Sadly, it will fail. I spoke to the founder about the project and in my opinion he's underestimated the challenge. He said something to me like "all we need to do is solve the battery life issue". That's like saying, to get to space all we need to do is build the space shuttle. As far as efficiency is concerned, android is the only show in town. Debian won't cut it. What he does works for stuff you plug in, not for battery operated gadgets.
Sony put everything you need to run your OS on some of their Xperia phones on GitHub as part of their Open Device Program. Jolla which is going to become open source sometime has been successfully (in feburary 2017) run on one of the devices.
So in the near future, there is hope in that direction.
I second this, I'm pretty happy with my 1st gen Jolla, though it desperately needs an hardware update. To be able to get a terminal either on the device or by logging in with SSH to fix things or make changes is great.
Not all the UI components are open source (yet?) though it's pretty close to stock Qt; at least the base system is open-source, and that's more important to me – I think they want to prevent full rip-offs rather than lock down the system from their own users.
I've been critical of these computer-in-your-pocket claims a few years ago, but I can see now that if the hardware keeps improving at the rate it does, having a full Linux system based on something like Sailfish or Ubuntu Phone with a keyboard and screen attached could work out for a lot of scenarios.
My best bet would be to restart/re-instantiate a community around CyanogenMod/Lineage OS, Android being F/OSS after all. Though maybe the community around CM is still strong (I honestly don't know).
Question is, are you willing to spend money (or testing/integration efforts) on a community O/S for your phone in exchange for knowing that you're not being spied on all the time?
I could imagine a model where you pay a reasonable price for a tested/supported third-party O/S, but maybe CM has shown this isn't economically feasible.
I don't remember android being floss since google bought it. My exprience of cyanogenMod is bad: support for the devices I owned was shaky to inconsistent through time. Then it turned into a commercial attempt at maximizing profit.
IMHO the effort put into cyanogenmod would have been better used if put into building an actual OS. Though this is a mostly unreachable moving target as devices get obsolete faster than one can add support for at best manufacturers do not help.
Right now I'm considering jolla/sailfish for the next time I buy a phone which hopefully will not happen before 4 or 5 years.
The project has transitioned to a non-commercial license (https://creativecommons.org/licenses/by-nc-sa/4.0/) until sustainable funding has been acquired. The code is still open source, but apparently asking to be compensated for work that improves the security of the entire Android ecosystem is too much for FOSS fanatics.
I performed numerous security reviews of WebOS and frankly it was a bit of a problem. I never actually made it to the point of doing kernel exploitation since the numerous XSS vuln discoveries kept me pretty busy. What was unfortunate at the time is that the WebOS team didn't seem to take the XSS situation seriously even though XSS on that platform effectively compromised the entire UX. I made at least one POC which emulated WebOS trust dialogs. There's no need to break out of an application sandbox when you can make the application look like WebOS, complete with authentic looking authentication dialogs. I've not looked at it in several years, however. Maybe LuneOS has solved some of the core issues but I'd be skeptical as the whole OS was pretty well designed if your intention was to introduce XSS vulnerabilities.
In mobile FOSS computing, Pyra is The Handheld PC, and GTA04 is The Smartphone. Both being developed partially by same people. Both working with generic recent ARM Debian Linux and recent kernels. Kernels have some non-mainlined parts due to scarcity of engineering resources, but all features are forward-ported on each release and even RC of mainline Linux.
I still have my openpandora from the first preorder batch, it delivered almost all expectations I had for it and sometimes even went beyond battery life got pushed further than 10+hours and had a memory upgrade.
Ok, so Android is open-source as mentioned already by other comments.
Now the thing with Android is that, it is just a framework, so saying Android is Open Source is missing big points
There are two major limits:
1. What about apps?
2. What about drivers?
Today, if you get an Android phone with Google Apps, especially Google Play Store, you have access to many tools that can be considered useful for everyday use, which you won't have with FOSS Android. Here are some examples:
With Play Store, you can have (mostly?) any IM, as long as you install the app going with it. The only possibility I know to do that with FOSS Android, is to use matrix or IRC, and have server-side libpuprle connectors.
With FOSS Android You don't have factorized push socket: Most apps pushing notifications on Android require GCM. But even if it doesn't require GCM, there is nothing fully open-source an app developer can use. All they can do, is open a socket to their own server, and deal with it, which is a huge battery-killer.
Many people are mentioning f-droid as an alternative to Play Store. I'm sorry, but I consider this a joke. I highly respect the work done on f-droid, but this is not a usable alternative.
For instance, you want to save your SMS. We call that backup, but not every knows that.
Well you search for "save sms" on f-droid. No result.
You search for "save sms" on Google Play Store, the second result is SMS Backup+ which is open-source! You search for SMS, the result is on the first page.
Same thing happen if you just search for "sms", QKSMS (an opensource SMS application) is much easier to find with Google Play Store than f-droid.
Even to look for open-source apps, you're better off with Google Play Store!
Again, I totally respect F-Droid devs, this is this way because of their choice of not tracking or saving any user information at all, which is legit.
But then, some people might want something intermediary. Just counting the number of installations of an app can be really useful to better sort apps (SMS Backup+ and QKSMS really deserve to be among the top in the results for SMS).
Now, about the drivers. Yes Android is open-source, but good luck running a phone with a FOSS Android!
At the moment, you have the choice with either replicant, which is old and missing gpu acceleration, or running a mainline Linux kernel with Mesa & stuff, but then you have no radio.
Though I have to mention that on the drivers side, Sailfish OS and Ubuntu phone have also those problems.
> Ok, so Android is open-source as mentioned already by other comments.
Is it ? I thought that only the AOSP part of Android was actually open source and not that useful by itself. I might be wrong here but my understanding is that the opensource in Android is mostly for show/marketing and is getting worse with time.
It would be nice if there were a 100% free-software version of Android available, or a way to remove all of the proprietary blobs from an Android phone.
As the OP is looking for an alternative to Ubuntu Phone, one has to bear in mind that Ubuntu Phone wasn't 100% free-software either (it used the same proprietary drivers and blobs as Android).
$50. Calling, SMS.
Alarm clock, calendar, calculator, phonebook, file browser, web browser and music player. I expect these will be very simple given the screen.
LinageOS + OpenGapps for a minimal Google Play Services installation (the "nano" flavour). Just make sure to buy a device that has a large userbase and good LinageOS community support [1]. I am using a $170 Xiaomi Redmi Note 3 with LineageOS and could not be happier with it.
[1] check out https://stats.lineageos.org/ for popular devices and also check the devices subforum on the XDA forums
I've been using OmniROM (https://omnirom.org/); it was a fork of Cyanogenmod when they went commercial initially. Not sure what the difference is between it and LineageoOS or why the lineage people didn't just start developing for omnirom; maybe they still have political differences or something. Regardless, it seems to work well.
You are at the point of 2002-2004 of Desktop OS - if you want to use a mobile OSS OS, you're just have to deal with lots of inconveniences. It depends on what are you looking for and what you find tolerable. I have been annoyed with the current paradigms of modern mobile OSes where I'm constantly bombarded with notifications and things that I need to keep up with. So for me, an usable OSS can have lots of drawback that I'm willing to sacrifice - I don't need any of the notifications or apps.
If you don't care about the aesthetic, your best bet is Lineage. It is Android without Google and you can still get lots of stuff done.
Personally, I came back to a cheap WebOS phone with a cheap plan and after I installed WebOS 2, it has been really usable. LuneOS is supposed to be the continuation of WebOS, but it's just not that usable yet - I see no way to sync with my Google account (which syncs fine with the 10 year old WebOS instance via Exchange). So I would keep an eye on the LuneOS development. For such a niche and small dev team, they have been continuing making improvements. Totally impressed by that.
I've faced the same dilemma and ended up stuck in Android bc of one single app: Whatsapp. A phone is (still) mostly a communications tool and 99,99% of my contacts use Whatsapp as the primary tool to chat/call/share. So, unless I want to be an e-hermit I need a phone that runs Whatsapp.
(For a little while, there was an unofficial Whatsapp API which I used to bridge chats to my Firefox OS ZTE)
I read comments like yours and wonder what the other side looks like. I have never, ever installed WhatsApp on my phone. My life hasn't disintegrated, or even degraded - but that's exactly why I wonder.
I guess it depends on your cultural background. We latinos tend to be a lot more connected with family and friends. It is also the economic incentive. In a poor country, a Whatsapp over wifi call is basically free. Furthermore, a key selling point for most carriers down here is: unlimited Whatsapp and Facebook.
Thought experiment: Say that I have a raspberry pi or similar. What hardware do I need to plug a sim card in and connect to a mobile network? Can I order it from a commodity supplier?
Was there an official announcement on the killing of Ubuntu Phone? There was an official pause announcement, and it might as well be dead - is there an official status update?
The next big OS is going to be Google Fuchsia, which runs on the Magenta kernel (not Linux) and runs apps built with Flutter.
Inb4 nay-sayers, but if you have followed Fuchsia for a few months and have seen the speed of development and just how many people and new technologies are involved, you will see why this isn't even a question.
Given Google's current track record for AOSP with bringing active development into Google Play and deprecating open source components, I am skeptical that it will be good for openness.
The problem isn't software. Let's say I have a dozen engineers to develop a mobile UI on top of BSD. What do we use? Nothing, Nada, rien. There is no real hardware. Even Linus can make a kernel, if there is hardware to develop it on! So software isn't the problem.
There's AOSP admire android. AOSP is open source which is some components of the Android system - however a lot of Android is not just AOSP. A lot of it is Google web services and other proprietary stuff.
https://lwn.net/Articles/718267/ / https://news.ycombinator.com/item?id=14002386
EDIT: This just got downvoted to 0, unsure why...