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.
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 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.
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?
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.
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.
root is not used by the mass majority of users.
I live by a park where there are 3 Pokestops and a Gym and it used to be mildly crowded, now it's empty. It's obvious that the game has died down and it all can be traced back to when Niantic broke the tracking system and proceeded to go after Maps.
Every "anti-cheat" measure they introduced (Detecting movement speed and root) netted a large number of false positives and they refuse to listen to their active and vocal community.
Not to mention the inherently broken Gym battle system where anyone can take over a Gym even if you were the one to beat the Gym owners. That was the one aspect I found too frustrating.
+ Disabled footpad tracking made it less fun.
+ Some update made it sluggish on my 10-month-old phone.
+ They don't let you play with Root (I have a workaround, but it's a pain).
+ Gameplay is highly repetitive past lvl 20
I just feel constantly trampled on. I'll waste my time with someone who treats me like an adult.
The problem is that Niantic recreated Ingress instead of creating Pokemon. So, the Pokemon players are leaving after the initial hype. The worst part is that Niantic has scads of data as to what game the players want to play and has failed to implement it.
The other piece to this is that it really seems like Niantic don't have a stake in whether Pokemon Go continues to succeed. I suspect Niantic was desperate, Nintendo beat them up in negotiations, gave them a fixed payment, and then flogged them mercilessly. The terribly slow pace of reaction reeks of:
"<American side> We don't automatically get a percentage of success, so we're not going to implement that without more money."
"<Japanese side> Well, let me discuss that with my manager. But we expect you to be honorable and fix this anyway."
"<American side> Uh, yeah. Sure. We'll work real hard on the promise that we might get paid when we're already having to do WAY more than we expected in terms of support given what you paid us. Yeah. We'll get right on that." Rolls eyes, and goes back to team "Do the MINIMUM you need to keep it from burning down and NOTHING else".
There’s an app in the Play Store that runs the tests the Google library that Niantic is using to check whether a phone is rooted or not (it’s the same tests used by the Google Pay infrastructure IIRC).
Also I was under the impression that SafetyNet would only pass on stock ROMs (to include official CyanogenMod builds lacking root). Is that not true? Will it also pass on any custom ROM lacking root?
Edit: According to http://androiding.how/use-android-pay-cm14-cm13/, SafetyNet (the tamper detection API in use by Android Pay and Pokemon Go) will only pass on official stable (non-nightly) releases of CM13/CM14 that have root disabled in the Developer options. It will not pass on debug releases of firmwares/ROMs, including Android 7.0 Nougat based CM14 and Android 6.0 Marshmallow based CM13 ROMs.
SafetyNet is completely fine with a nightly of CM13 (on Samsung Galaxy S5) after the su binary and it's accompanying symlink are renamed to get them out of sight (and effectively disabled). You don't have to touch the settings in developer options at all because SafetyNet isn't going on some extended search to look for the setting. It's just looking for the presence of an su binary in the filesystem in a few places during that phase of its checks.
Haven’t tried any other Android custom roms.
Niantic is not beholden to anyone to release anything, add any features, or do anything.
Its their game.
If you don't like it, either a) don't play, or b) make something better.
It's a testament to the compellingness of the AR game genre, and the brand recognition that Pokemon has they so many people are willing to put so much time and effort into the game despite how primitive it is.
People calling for an open API are fooling themselves. Why on earth would they give away the keys to the kingdom?
Hacking the protocol and the cheaters created this situation.
They have only themselves to blame for it. Cry. Me. A. River.
You might say that serious cheaters can bypass the restrictions / measures, but clearly from the fuss (and that fastpokemap is still down), its doing the intended job pretty much spot on.
Realistically, nothing is going to change, unless someone starts offering a compelling alternative to drive innovation.
> They have only themselves to blame for it. Cry. Me. A. River.
What does this have to do with the article, written by someone who didn’t cheat?
> If you don't like it, either a) don't play, or b) make something better.
Yes, everyone affected by this is rather forced to pick (a). Occasionally, they may write articles. If you don’t like them, a) don’t read them.
The choice between running the software you want, like Pokemon Go, and the quick road
to obsolete devices in the Android ecosystem, at best forces users to make a choice
between security and functionality.
I think it's pretty obvious from the comments in here that there's plenty of blame being poured on Niantic for whats happening.I'm just pointing out that the root cause and people who should be shouldering the blame here aren't necessarily Niantic... but more importantly, whinging about it won't change anything.
I disagree. Some people with rooted devices paid money for this game and now they can no longer play it. In any other industry, this would give rise to a series of lawsuits and the company doing it would be in big trouble. Somehow, though, for games, it's acceptable to just take away the thing you paid for.
Bear in mind, bots have little to no effects on the game itself because you have little to no virtual interactions with other players. It's not like you were able to trade Pokémons you caught with someone else.
I attempted to remove root however this has now forced the phone to be stuck on Edge network (he can play but now only on WiFi :/) I have attempted to re-flash the physical ROM's (as well as the recovery matching those ROMs) from ASUS (successfully) and it still is stuck on edge. I've contacted his phone company (T-mobile) - insured the proper bands were being requested, 5x checked the APN settings and yet the phone still doesn't want to connect past edge. Here is the kicker, I scan for nearby cellular networks and T-Mobile (LTE) shows up, the phone registers, yet still won't obtain the connection.
Honestly that issue is probably due to some other restriction but it shows the frustration some users have had to deal with because of this move.
I even tried re-rooting the phone just to get his network back because he'd rather have his phone than Pokemon GO yet the phone had something special done to it to allow the network to work under root.
No one should have to go to those extremes especially when they aren't cheating and they are a paying customer.
In all honesty I don't believe the ban on root was done to deter hacking - my belief is that it was done because on average users only root because they want paid apps for free (a lot claim it's to tweak the UI and remove bloatware, but as more and more phone's get released we are starting to see this less and less of a requirement). While many rooted players (due to pre-rooting) are actually paying customers it still doesn't outweigh the paying customers who are not rooted and therefore it was more then likely a move to remove users who are less likely to put money into the game.
Every move they have done really reflects that they only want more money with the least amount of work and that is why I only keep the game installed to keep my 1 star reviewed from being weighted down due to being a review for an older version.
One of the big guys who is involved in creating a usable tracking system via a third-party map has made a wonderful statement about the many failures of Niantic [1]. From unnecessary obfuscation that only slows down older models, to banning the devices that aren't the reason cheating is happening, to not creating a good way to achieve feedback (apart from "critical errors" which is built into the app - maybe I should start complaining about the critical "Niantic" bug and that it needs to be fixed ASAP, but complaining won't really get anywhere if the company isn't listening to those problems) Niantic truly is on a path to destruction and I hope Nintendo doesn't let this amazing idea die if Niantic falls.
It really doesn't make sense to why they are making these decisions. The developers should know that banning rooted devices won't deter hackers - in fact I would have to say it's grown a few hackers/cheaters due to the frustration of dealing with lack of communication and oddly made decisions.
"A strange game. The only winning move is not to play. How about a nice game of chess?"
The real value is knowledge gained. And I've seen some pretty crafty solutions created.
This practice needs to be stopped. There needs to be a simple app that can be installed that completely shields from, blocks and stumps this fascist SDK that detects root. And every custom ROM should have it installed by default. The problem is obviously bigger than Niantic. The problem is that people think we shouldn't fully own our phones and that such a mindset is acceptable.
The problem? SafetyNet does not care about game spoofers/cheaters. That's literally not what it was designed to do. Pokemon Go does not represent "planned obsolescence". It represents Niantic being too damn lazy to search an array result for "Xposed" and instead invoking something that will make it look like they expended some effort.
It takes about five minutes to make a stock CyanogenMod device "compatible" with SafetyNet. All you have to do is rename two files, specifically /system/xbin/su and /system/bin/su. Boot into recovery (TWRP or whatever you have), and start a terminal from there (where you are as "root" as root gets, and this will always be so) and type `mount /system` to start. Next, rename those two files. Lastly unmount /system and boot normally. SafetyNet will be happy, which means Pokemon Go and Android Pay will also be happy. If you want "root access" back on your phone, all you have to do is go back into recovery and rename those two files back to what they were.
[0]: http://forum.xda-developers.com/apps/magisk/official-magisk-...