http://penguindreams.org/blog/android-fragmentation/
The TLDR is that it'd be nice if Android was more like Windows/Intel: install the OS (i.e. AOSP), drivers (or binary driver package format and an SDK to auto-build it) and boom you're done. Clean, stock, standard. Same with many Linux distros on x86/64.
I need to write an update to the article though. Lately I've been struggling with a Clearfog ARM board, and coupled with Torvald's recent comments on Intel vs ARM, I wonder if a huge chunk of the problem is ARM itself.
I've noticed for every distro there are really specific images, not just for each ARM chipset, but for individual boards, even when those manufacture patches make it into the mainline kernel.
I haven't looked closely at Android and I'm really curious at the build system/workflow used by things like Cyanogen and Omnirom. Are kernels really specialized per device? Does the ARM architecture itself make it difficult to have general purpose kernels that will boot on all of them like in the x86/64 world?
Any ARM hardware people care to chime in?
It's not really about the CPU architecture, but the peripherals of the devices. In the x86 world, the peripherals are governed by the "PC" standard, which these days is implemented by the chipset on your motherboard. They all have similar functionality, although you still do need some chipset-specific drivers in your kernel.
In the ARM world, the landscape is different. There has never been a de facto standard configuration of an ARM computer like the PC was/is for x86. There are ARM computers that are more like a micro controller and there are tablet/mobile devices based on ARM that have a system on chip (SoC) that's got all the peripherals, including GPUs, network adapters, etc. Every SoC is pretty different, there's a bunch of devices connected with i2c, spi and other buses. These are required to control the power and clock management and all the I/O devices.
ARM (the company) doesn't really design these, they just license ARM (the architecture) to a SoC manufacturer and call it a day. This leads to a very diverse and fragmented landscape.
The ARM world has been making strides to reduce the amount of chip-specific code. One good example is the device-tree configuration which, in theory, allows running the same kernel binary on different devices. With device-tree, you pass a config file from the bootloader to the kernel, which contains configuration (i/o memory maps, etc) of the peripherals (which you'd query from the hw/firmware in a x86 machine). This is a huge improvement over what was before it, but there's still a long way to go. And there's still plenty of older ARM SoCs out there that don't support this.
But yes, it's pretty much a mess. There's a lot of duplicate work that every ARM SoC manufacturer has to go through. Given that the mobile world is financed by a planned obsolescence cycle where they expect customers to upgrade every few years, I find it unlikely that this issue will be solved any time soon.
We had Z80, 6509, 68000 and so so, but everything else that was plugged into their pins was different.
So it doesn't matter if the Assembly is the same, the kernel also needs to talk to the hardware.
Also ARM just resells the base designs, each company usually adds they own set of Assembly instructions or fine tunes the designs in some other way.
The IBM PC clones were the only ones that had some kind of standardization going on, and even that seems to be gone now, with OEMs going to the same kind of hardware designs we used to have (everything bolted on the board).
https://wiki.debian.org/DebianKernel/ARMMP
Unfortunately most mobile devices are not supported by mainline Linux (N900 is best supported, but not fully), usually only server/desktop/laptop vendors have any incentive to mainline their drivers.
So it really makes sense for them to go this way IMO.
That said, proper protection against cheating would involve using markers (other phones?) in vicinity, so it should be possible too.
I don't condone Niantic's behavior, but I understand it.
Niantic is not actually making any attempt to look for GPS spoofing software. They simply invoke Android's SafetyNet which doesn't care about GPS at all but does care about other things which happen to coincide with what's on some cheater's phones. It will never be anything like an effective measure against GPS spoofing.
I just bought a Nexus 5x and loaded CopperheadOS on it, and to my dismay I see Ad-Away from F-Droid requires root to function (plus a couple other apps I really like). How much of a hassle is it really, because I absolutely want system wide ad blocking and I worry that I will be defeating the purpose of using a hardened OS in the first place?
Do you rebuild and flash each OS update as a new ROM? Is all your data on the phone persistent or backed up & restored each time?
Ad-away works by using a host file to block. The hosts file is generally not writable by the user without root as it lives on a read only partition (/system).
Another way to block ads is to connect to a VPN that blocks thoses hosts for you, however that is more cumbersome to setup.
While hosts blocking is not perfect... my thought on this was to expose a limited API that allows apps to update the hosts file without having root. This could be sketchy and a security risk on its own tho, because you're essentially hijacking DNS... In addition, I don't think the community is interested in this because they all love root..
> Do you rebuild and flash each OS update as a new ROM?
Every month, immediately after the security bulletin and a resync.
> Is all your data on the phone persistent or backed up & restored each time?
So android has a /system partition and a /data partition. When you reflash your system, the data partition (where all your apps, settings, what not are stored) is left untouched. Android will detect this and perform an upgrade operation on the /data partition, if applicable.
It is also possible to block ads in other apps on Android. One way is to use a custom hosts file that blackholes ad-serving domains. The hosts file is stored on a read-only partition for security purposes on most builds of Android, so overwriting it requires root. Another option is to point your phone to a DNS server that does the same thing. This does not require root and works across multiple platforms. Another Android-specific option is to use the VpnService API to implement filtering in an app that does not use root but gets to see all other apps' Internet traffic. There are several apps that do this.
Can someone point me to a ROM like this if one already exists?
That's not only about UI. Most people want customizations / features that enable things like 4G radio, wifi and graphics. What would be the point otherwise?
The point isn't that there are no vanilla AOSP ROMs for most devices. The point is that they usually suck, and a reputable well-supported one that actually worked properly would be a massive innovation.
When people say "Google's phones" it is generally understood to mean the unlocked line of Nexus devices that they sell directly and provide updates/firmware images for directly.
It's not like this was the first solution they jumped to to stop cheaters.
Maybe this was the 80/20 solution over more advanced location anomaly detection methods against their database.
edit: And Wikipedia says "GPS spoofing attacks had been predicted and discussed in the GPS community previously, but no known example of a malicious spoofing attack has yet been confirmed"
http://www.rtl-sdr.com/cheating-at-pokemon-go-with-a-hackrf-...
The thing is, nobody cares if you send a signal too weak to go beyond a meter of your pocket. That's why it's totally legal to send FM on registered frequencies as long as your output is under a certain amount. Same with WiFi even.
I heard about someone looking into GPS spoofing once in the context of catching drones, even nearby ones (e.g. fly near to it). It takes a lot of energy to do that and was basically not practical outside of military settings.
Interesting to learn that it wasn't legal in the UK though. I wouldn't know of the legality in the Netherlands, but I know they're in use and nobody's complaining.
Niantic uses the same techniques they used for Ingress to deal with GPS spoofers, and they're not that advanced. Play for an unrealistically long period of time without stopping and you might get a tempban and flagged for careful examination. Appear to travel at jet plane speeds by performing non-idempotent actions without stopping by an airport first, or doing this too many times in a short period, and you'll also get flagged for possible banning. Beyond that, they're really not doing much and it doesn't really qualify as "advanced localtion anomaly detection". You're giving Niantic far too much credit.
You can simply rename your su binaries through the recovery environment to disable them, which neatly disables "root access" and makes the SafetyNet check Niantic is invoking pass with flying colors. Should you need them again, they're only a reboot and couple of mv invocations away.
For me personally, this is not the reason for me to build CyanogenMod. I will occasionally modify certain things inside android to suit my needs and there are enough of these things that are not merged upstream that it's more convenient for me to just build my own version every month/week/whenever.
> Also, I'd like to remind you that SEAndroid (i.e., SELinux) doesn't give a fig about "root" so your statements about that are quite wrong.
This is an area i'm not quite informed, so maybe you can elaborate further.
The core issue that I wanted to express is that barely any community ROMs are CTS compliant, which is ultimately what SafetyNet checks.
> You can simply rename your su binaries through the recovery environment to disable them, which neatly disables "root access" and makes the SafetyNet check Niantic is invoking pass with flying colors. Should you need them again, they're only a reboot and couple of mv invocations away.
Doing a bunch of mv's is a hassle (esp over multiple devices) as I rarely ever need root on my phone. The only times when I need it nowadays is host based ad blocking, which I just integrated into my ROM. So this way I can just get rid of root all together, which is one more step towards CTS compliance.
SEAndroid/SELinux is a mandatory labeling system, which simply doesn't believe in special UIDs at all. It gives us pretty incredible granularity of control over things as well. Deny/grant access any number of users to each and every object and facility of the system, in any combination you like. Just understand that there's a steep and somewhat unforgiving learning curve and the documentation on what labels have been put into play on any given deployment has a strong and nearly universal tendency to suck until you're looking directly at the source code that sets up those rules.
root is not used by the mass majority of users.
One thing that I observed is that no one seems to be interested in producing a ROM that is both stable, has a variety of features, do not rely on root, and supports the device for a long time.
This is a shame really, because root itself breaks the security mechanism for android and users probably are not fully aware what it means when they grant applications root.
I personally got around this problem by compiling a build of CyanogenMod without root enabled, but with things like FDroid (with PrivilegeExtension) and adblock built-in to the ROM itself (albeit the update mechanism is to update the ROM it self). This is not a solution for the mass majority of users.
This problem is pretty difficult to solve and it is pretty deep, much deeper than what I'm willing to type in a single comment, so I'll stop here.