This doesn’t work anymore because since android 9 or so, there is an api feature that allows any app to query if mock location is enabled. You need to be rooted to disable that “feature.”
I use it to gamify (not games or such -) a lot of things, but it’s also used for “fraud” or such, one thing when I was researching was that Pokémon go users do this. I just do it for geoarbritage pricing - without a play account on google phones. IMO I don’t think google play follows geographic pricing like apple does with their store (address/credit card in other geographic region)
Coincidentally it’s harder to do the above on an iPhone.
I've done it for Pokemon Go. There are (were, it's been a while) pretty specific setup steps required, and it changed over the course of a couple of years as Android changed things up.
One of the older methods worked, but semi-required the back of the phone to have aluminium foil on it so that the real GPS signal wouldn't get through and "rubberband" you back to your actual location, earning a soft-ban. I had more than one phone with a couple of layers of alfoil between the phone and the case.
There was another method that required a specific version of Google Play Services, so that root wasn't necessary. I think.
Also had to rename the FakeGPS app, and use Magisk Hide
Good times. I enjoyed "seeing if I could" more than the actual fruits of the labour.
Afaik nearby wifi networks are also used to determine location. As long as you have wifi activated Google can use this to determine where you are. I don't know if they use this as a hard check.
The only way I can think of to prevent this is to build a faraday cage with a wired vpn router and your phone inside.
This looks to use the dev options to fake it, which I believe bypasses the geolocation apps (as I assume the mock location is used for testing apps if they are in certain locations).
That being said, I have tried this for banking apps, and they aren't fooled by it, so I am guessing Android passes on that this is a "mock" location, not a real one.
Like you said, if you really want to fake it, probably a faraday cage/fake GPS would be necessary.
Having a smartphone provide a hard to fake location is a pretty valuable feature. A lot of businesses depend on the fact that location data is hard to fake.
Consider caller ID - legislators around the world are working on making it harder to spoof your identity, because there's so much fraud going on with fake caller IDs.
It's the same with location. Being able to easily fake location would open the door to so many frauds...
You're basically arguing for https://en.wikipedia.org/wiki/Trusted_Computing . You're saying that the manufacturer should have more power than the consumer, that the consumer cannot run arbitrary code, that the consumer cannot examine and disassemble the manufacturer's code.
We basically already have that on smartphones. Both Android and iOS have remote attestation, and a significant number of apps use it to refuse to run on devices with anything but an unmodified first-party OS.
I was surprised there wasn't a bigger outcry over it in the tech world.
As someone who habitually roots my Android phones, I'm always somewhat annoyed when I can't use features like tap-to-pay, but I'm really annoyed when apps refuse to start, especially when they are for things like McDonalds. I shouldn't need to have a known-trusted operating system to buy a burger.
I've found that the Play Integrity Fix module for Magisk usually solves it, though there are a couple exceptions. They still earn a negative review for the attempt.
It's a recent change that app developers have the ability to know, and represents a massive transfer of power away from users to app developers and OS vendors.
Well in a purely laissez-faire sense, of course. They can legally decide to refuse service to anyone for any reason, with a few narrowly protected exceptions like race. But that doesn't mean they _should_. They could choose to refuse service to anyone who isn't wearing a tux, or anyone who refuses to sing the national anthem, but they shouldn't do that either, and not just for the obvious capitalist reason that those actions would cost them business.
I guess what I'm saying is that I see some degree of reasonableness in a bank or a mobile game enforcing some Trusted Computing paradigms, even if I don't like it. Banks have to worry about real money fraud, and games worry about cheating. In my opinion, the privacy and user agency tradeoffs are not worth it, but I see why they do it. For someone like McDonald's though, I just do not see any reason that they'd need this level of trust in their customers.
Buying fast food is historically a very low trust, transactional deal. Why does McD need to be able to ensure my device integrity to offer this? Starbucks doesn't need to do so, and they have a loyalty program with stored value and payment reload in the app.
I doubt it (if McDonalds' saves credentials, it's likely some sort of token on their servers, rather than in plaintext on the app), but that wouldn't change anything, as I am okay with running an app which saves payment credentials, on my rooted phone.
Indeed, I'm okay with doing whatever I want, within standards of human decency, with my owned device and my owned bits therein. I don't see where McDonalds' desires factor into what I do with either.
Their technical capability of imposing control over how people use their own devices isn't self-justified, or justified at all.
Just saying that if they do, maybe not you, but someone will eventually go "I saved my cards into the McD app and got a surprise $LARGE_AMOUNT bill" because of their mobile platform not enforcing the isolation.
I doubt it (if McDonalds' saves credentials, it's likely some sort of token on their servers, rather than in plaintext on the app),
But even in that remote possibility, I think it's even less likely that many folks sophisticated enough to root their phone would ever have that complaint.
I'm happy to be proven wrong with a sufficient amount of such complaints about the McDonald's app.
> They can legally decide to refuse service to anyone for any reason, with a few narrowly protected exceptions like race.
and because an online store is not able to discriminate on race, these protections are voided, because they could refuse based on proxies of race (for example, they could be using location to determine if you're likely going to cheat the delivery, or reverse credit charge, or fraud etc). it might sound reasonable to try prevent the fraud before it happens, but it is an abuse of a position/power they should not have.
The balance of power between a user and a service provider on the digital realm is swining towards the service provider. This needs to be addressed.
There is also the base band processor, which is completely locked away from user access. Running a wireless network would be much harder, if users could access it. So I guess freedom and working tech are trade-offs in this case.
That the client isn't trustworthy is a pretty fundamental rule of network security. Attempts to circumvent that rule are making it so users can't trust their own devices, and that's a dark path to go down.
Do I care? Like not to be glib but as an end user buying a phone for my personal uses, I dont care about their businesses and I loathe the idea that their business model requires such an anti feature to be widely deployed in personal devices such as smart phones.
Tell you what. I have a business model that requires your personal location data. Be a dear and send it to me.
And again, why do I care about caller ID. It's been trash for years. I just never answer calls and use diffetent platforms such as Signal to communicate with my friends.
It may open the door to so many frauds, but it opens the door to so many more abuses.
People will talk about these 'features' differently the first time a large genocidal action takes place that makes use of this data.
Ride hailing apps rely on the fact that both customers and drivers phones don't lie about their location.
Mapping companies rely on the fact that their crowdsourced data is reliable.
Emergency services rely on the fact that phones share accurate locations.
Delivery companies require authentic location data from their agents.
Apps that allow people to rent scooters or bicycles rely on non-fake location data.
If you made it easy to provide fake location data, a lot of apps would suddenly have to deal with a whole new class of fraud. I just don't see how this would be a net beneficial change.
You can separate all of those examples into one of two categories: one in which the owner of the phone has a vested interest in providing accurate location and an easy means to enforce consequences for undesired behaviour (I want my ride to find me, I want emergency services to help me, I want to find a bike near me), and another in which a company hopes to use someone else's information for free for their own benefit: delivery companies with a "bring your own phone" policy, or crowdsourcing companies hoovering up free data to build their value.
Since I paid for my phone, I really don't see why it's incumbent on me to help the latter case out. A delivery company is free to supply a managed device or fit a device to their trucks. A crowdsourcing company should in any case already be assuming all client data is suspect and ensuring it's properly correlated with other sources of information.
There's no fraud here. The worst case outcome in your list is perhaps a delivery agent just having their phone say they've done a particular route when they just sat in the movie theatre or whatever, but the fact that none of their packages got delivered is enough to out them even if the shipping company is trying to get location data for free from a device the shipping company doesn't even own.
If I hire a bike I'm nowhere near I still pay for it. Denial of service attacks in which the perpetrator is fully responsible for the cost of resources consumed just aren't a thing that happens.
The only group involved in these scenarios that's taking adverse action against another party for their own gain is the entitled companies demanding users' phones be locked down so they can continue to get material gain from them without compensation. The net benefit here is that these companies' profits should definitely be taking a back seat to users' rights.
I think you are stuck in an "us vs. them" mindset. It's not all consumers vs corporations.
Consumers actually want to use services offered by companies, and willingly accept what you consider drawbacks. We want accurate traffic data in maps, and crowd-sourced key finders, and all the other conveniences afforded by unspoofable location data, and we give up a little bit of control in exchange for that.
Companies don't compensate us with money for crowdsourced data; they compensate us by offering services they couldn't offer otherwise.
Crowdsourced data is not individually reliable and is already accounting for invalid and incorrect submissions. We can have our cake and eat it too.
The ‘us vs them’ mindset comes from ‘then’ determining what is acceptable for ‘us’ to do purely because it’s good for ‘them’.
If I want to set my location to somewhere I am not, and the only reason I can’t is corporate interests, then a battleground has been drawn up by those interests, not me.
> Apps that allow people to rent scooters or bicycles rely on non-fake location data.
There's a way to fix this. Each bicycle can store a private key, and your phone needs to talk to the bike nearby to do a live challenge-response before you can rent it out.
I'm pretty sure they already do that. As always, the standard network security advice is "don't trust the client", and yeah, it'd be nice to be able to trust the client, but it would also mean the total abandonment of any meaningful user control over their own devices, so it's not worth it IMO.
I fully agree with where you're coming from, but you kind of veered off with that last sentence. In general I think the threats from fine-grained surveillance databases are a lot more nuanced and pernicious than genocide.
There are a lot of legitimate use cases that require reliable location data. I mentioned a few that I could think of in a sibling comment, but I'm sure there are more. Maybe you can come up with a use case for accurate location data yourself?
Anyway, spammers and data brokers probably wouldn't care at all if say 10% of people spoofed their location. They don't really have a lot to lose if some of their data is incorrect.
Users also need other users to be honest about their location. Consider a dating app; you want to meet real people who live in your area, not a fraudster pretending to live just a few blocks away.
Or a delivery driver: You want them to actually drive up to your house and ring your bell, rather than just pretend to drive there and drop your package somewhere else.
Location data is worth a lot more if it is reliable.
The user should be in control of sharing their location. But you shouldn't be able to just provide a fake location.
> Consider a dating app; you want to meet real people who live in your area, not a fraudster pretending to live just a few blocks away.
So you shouldn't be able to use the dating app to set up a date for when you're back home while on a business trip or holiday?
Maybe you should just upload proof of residence to the dating app instead. But I'm sure you'd consider THAT a violation of privacy, while 24/7 location tracking of your phone isn't because ... it's electronic?
By the way, do you want to give your exact location to a profile on a dating app? Even if they're local, maybe they're serial killers.
> Or a delivery driver: You want them to actually drive up to your house and ring your bell, rather than just pretend to drive there and drop your package somewhere else.
This other case is legitimate but it can be solved by issuing the driver a work device that has tracking.
Unfortunately the other 10000 cases are unneeded violations of privacy.
For the same reason that every movie ends up ripped on piracy sites, but you still can't watch Netflix in 4k on Firefox on Linux.
DRM doesn't work because it only takes one person to bypass it to make a copy, and caller ID verification doesn't work because it only takes one janky provider that doesn't implement SHAKEN/STIR correctly and yet is worth too much money to totally block.
FWIW I can still generate calls with arbitrary caller ID from a handful of my (legacy) ITSP providers, but if I get a new account today with any of them, they will require me to either verify each caller ID by receiving an inbound call or provide a "valid business justification" for why I can't do that. They are working on tightening up the pathways to generating fake caller IDs but in the telephony world, nothing moves fast and uptime is more important than anything, except maybe revenue, of which spam calls account for a ton.
Well, if legislators are trying to fix it, I suppose I feel better about the user hostility. Good luck to the legislators, and thank god we have people like them!
Also: screenshots. Firefox won't allow me to screenshot a private window. It's my damn phone and I should be able to screenshot or record whatever the hell I want.
I think it might be a legal requirement for emergency services. I used to work a lot with VoIP and each line was required to have an address associated with it.
I'm fine with that, provided that there's sufficient oversight to prevent abuse.
What I'm not fine with is one large corporation who makes phones baking this feature in so that other companies that make apps can profit off it. That's two parties conspiring to fuck over their customers.
> The only way I can think of to prevent this is to build a faraday cage with a wired vpn router and your phone inside.
Another option is to not be running an operating system that betrays your interests. Google can only determine your location using nearby wifi networks if that list of nearby wifi networks has been given to Google through Android/Play backdoors. In fact most privacy issues with phones boil down to running a malevolent OS - protecting against malicious application code is still a difficult problem, but it is at least tractable if you can trust the system code.
(Personally I think the functionality of the OP should be included by default as part of the OS permission system, and configurable on a per-application basis)
Sure, that's a related but different problem - cataloging the location of wifi APs versus inferring your personal location based on what APs your phone can see.
Running user-representing software on your phone doesn't fix all problems everywhere, it just gives you a platform with which you can address them to the fullest extent possible.
Fair, I took your original comment to mean that Google was mapping WiFI AP locations using people's phones (which could still be true). However, after re-reading it I see you meant that Google is pin-pointing your own location based on which AP's are visible.
I would think they are certainly using phones to collect Wifi AP locations. In fact if they've stopped doing so with the mapping cars, then it's probably because the phone backhaul is good enough.
The ways of preventing this are much less straightforward though. Stopping your phone collecting them will only remove some datapoints (perhaps significant for some people, but not for most). Disabling AP beacons or continually rotating ssid/bssid can mitigate it for your own APs, but at the cost of some UX.
Please note! Modern versions of Android will passively scan for Wi-Fi networks and use them for location tracking even if Wi-Fi is turned off* by the user.
I don't know if turning off location tracking also stops the passive Wi-Fi scanning, let alone whether anything related to this is phoned home to the Google mothership, or whether Android devices are now part of a giant botnet tasked with improving Google's location services.
*Turning off Wi-Fi in Android now only has the effect of disconnecting any active wireless network connection, the radio stays on and the lower level of the wireless network stack remains running to facilitate the passive network scanning.
nearby wifi networks, nearby cell phones, and also bluetooth devices. Even in airplane mode your phone is looking for beacons and keeping track of your location. Even when you turn your phone off entirely it doesn't give up (https://www.androidpolice.com/android-15-powered-off-finding...)
They want accelerometer, temperature and other sensor data too where possible. Not just information on the strength of the wifi/cellular signal (and your estimated location). SIM cards can do the most on qualcomm devices.
Poking into both of these systems outside of a lab is definitely a violation of the law ordinarily and it's pretty hard to test this in a lab.
I just saw this yesterday about losing Authy for 2FA on non-official Android devices w/o play services. I'm curious how phones like this are handling that.
Google isn't banning hardware killswitches in their compatibility definition, so a phone with such switches can still ship Play Services.
The main stumbling block here is that Google wants to tie users' hands in certain aspects, and many of these OSes are specifically designed to undo that control. GrapheneOS does a bunch of stuff to improve security that absolutely could be incorporated into a Play Integrity authorized build. But it also does a bunch of stuff in the name of user privacy that Google would never sign off on.
For example, there are apps[1] that refuse to work without a GPS lock, for a variety of reasons ranging from "I save money on streaming rights by only letting you watch in a specific country" to "I need to know if you're a criminal trying to stuff our banking app with stolen credentials in a foreign country we can't prosecute you in". Some of these reasons are pro-user, some are user-hostile[0], but all of them require handcuffing the user, so Android cooperates with app developers instead of you.
All the permitted ways for a user to manipulate their location are transparent to the application. That is, if you mock your location, the application is told it's fake and can refuse it. Likewise, if you turn off location, the application is told it didn't get a fix. Hardware killswitches are just a more powerful / legible way to turn off location. If the phone instead had a hardware GPS signal spoofer in it, Google would absolutely ban it from Play Integrity.
[0] And, for the user-hostile reasons, those are the terms of sale, so Google cooperating with the user would just get the app taken away because the entertainment conglomerates are big enough to oppose Google's market power.
[1] Client and server inclusive, i.e. "an app is just a website with enough IP to make it a felony to block ads in it". Play Integrity exists specifically to frustrate attempts to modify the client. If you modify the client or the OS it lives in, Play Integrity's signed data will have the wrong hashes in them, and the server will refuse service to you.
> But it also does a bunch of stuff in the name of user privacy that Google would never sign off on.
I don't think that's necessarily true. It's actually kind of confusing to me that Google doesn't whitelist GrapheneOS. According to their website [1]:
> GrapheneOS not only upholds the app security model but substantially reinforces it, so it cannot be justified with reasoning based on security, anti-fraud, etc.
Ever since I discovered this article, as a GrapheneOS user, I've felt sort of conflicted about it. On one hand, it would be good to see more apps support GrapheneOS. On the other hand, as a FOSS advocate, it irks me that I can't make arbitrary changes to my OS without taking the risk that certain apps might stop working for no reason [2].
It also places GrapheneOS in a bit of an awkward position as a open source project, where it's possible that they might be forced not to include certain features because they made this promise to banking apps. For example, they would probably not accept a location spoofing feature that can't be detected by app developers, because banking apps could no longer trust the OS-provided APIs.
But again on the other hand, this policy means it's not off the table that Google might whitelist GrapheneOS in Play Integrity one day, which I think would be a good thing (of course there's business interests at play here, but there's no valid non-business reason for them not to).
Overall, the entire mobile phone ecosystem depresses me. I just try to avoid using my phone as much as possible, and keep the number of installed apps to a minimum. I'll probably give the iPhone a try if they ever start allowing sideloading (wishful thinking). Unfortunately it seems like it may become unsustainable to avoid placing full trust in your phone's manufacturer, and I'd only be comfortable giving that to Apple, not Google or Samsung.
[2] It should be noted that, as of today, I don't think any banking app has added explicit compatibility for GrapheneOS. AFAIK all the banking apps that work with GrapheneOS also work with any (non-rooted) open-source Android alternative. As a sidenote, I currently work around this issue entirely by simply using my bank's website instead of their silly app, and this will continue to work as long as hackers continue to fight against Google's dystopian plan for the web: https://en.wikipedia.org/wiki/Web_Environment_Integrity
In a world where the iPhone exists and there's no effective regulations against their obvious anti-competive behavior (even the EU's DMA hardly did anything), I doubt any U.S. court will take them seriously, but I guess we'll see.
iPhone isn't a great comparable because their crime is one of bundling copyrighted property in a way we hate. And the law is extremely deferential to the interests of monied copyright owners. Android explicitly licensed their work as FOSS and invited others to build on their work, so bundling stuff this way is a lot more obvious an antitrust violation, and remedying the antitrust violation does not imperil any copyright.
To wit: the EU already got rid of the whole "Android phone vendors must not ship incompatible forks" rule. They did this so long ago that all the comments on the news articles about it have aged like milk. Most of us were still complaining that the EU was unfairly targeting US tech companies, rather than cheering on the EU for unfairly targeting US tech companies. And in the US, Google has already lost in court, against Epic, on a lot of antitrust issues. It would not be that far of a stretch to go to a court and say Google not whitelisting Graphene[0] is anticompetitive, and the main reason why that hasn't happened is primarily because Graphene is a small project run by a developer that harassed Louis Rossmann over something stupidly petty.
[0] assuming there's a CDD-compliant version floating around out there
You can run Android apps with Waydroid, but you can't overcome the DRM. You have to complain that you run an alternative OS, which has a right to exist.
Your phone is easily located in moment you put SIM card and turn phone on. GSM signal reach closer tower and try connect to other near by. By making approximation of those signals, you can locate position of phone on ~10m.
This app registers a location provider. Probably the phone wouldn't resort to using wi-fi networks if there is a location provider present. Probably, maybe.
With all the beamforming shit Wi-Fi has these days it's actually surprisingly hard to make a good faraday cage for a phone. Even a very tiny amount of signal and it still works.
My office elevator is stainless steel on all sides and yet somehow Wi-Fi works inside. A miniscule amount of signal must be getting through a crack somewhere.
When I was a teenager and wanted to go do boyish teenager things, like hang out at $ABANDONED_BUILDING, I used such apps to mock my location to the library, as my parents were tracking it using Life360.
According to my over-50 year old boss in regard to their grown kids, they still do. But it is symmetric nowadays, and has something to do with their faith.
Me and my loved ones all location share, but we are all also well adjusted and capable of minding our own buisness. It does make life easy though when picking someone up from the airport, being worried about someone taking longer than expected to get to your house when a visit is planned (quick check can see theyre moving, or stopped at gas station or something) and can put concerns of an accident to rest. It really does rely on everyone involved being well adjusted though. Final point is, temporarily disabling the sharing is dead simple and no one bats an eye or brings it up if it happens, and happened to notice.
All of that can be quite healthy and I have zero issue with it. The part that threw me off was the family in question doing it for faith reasons. I wonder what that entails and genuinely hope it’s not some kind of megachurch scam imposed by a fraudulent faith-healer.
Is your boss the current Speaker of the House of Representatives who uses such parent-ware on his children's phones and claims that his child does the same so they can monitor each others (avoidance of) porn habits?
Reminds me of the old FakeOperator for iOS from back in the day, where instead of it saying Sprint or Verizon you could make it say "CIA", "FBI", or even "Hacker" the joys of smartphone hacking.
I chose a location, opened maps.app and it seems to 'think' the phone is at the new location.
But
Why does doordash still know PRECISELY where the phone is? I turned off location permission for it, 'force stop'd it and then relaunched and reenabled precise, always ON Location sharing.
A basic mock location app like this labels its output locations as fake to the operating system. https://developer.android.com/reference/android/location/Loc...() will return true. Apps can choose to ignore the fake locations and use a last known location instead.
So maybe it's just displaying the last known location, rather than somehow getting your current location?
I’m working on something similar for IOS by running MITM & spoofing the response from wloc (API used to determine location based on Wii routers and cell towers). I was surprised that GPS is rarely ever used and almost always substituted by APIs that expose your location to Apple/Google even if VPN is on
Always though that's the stupidest way to play the Pokemon Go. Maybe it made a little bit of sense in the beginning when small villages had almost no content but even than you just missing most aspects which make this game interesting. I guess that's the time we live in.
It's true that playing in-the-flesh with a crew was the best way to play, but spoofing enabled both levelling up faster (which in turn helps the "with crew" outings) and bypassing impossible restrictions like increasing number of geo-locked critters.
It does say "gotta collect 'em all" pretty clearly...
However, I still remember the wave of people coming towards me when a Gyarados spawned right near me. I had some family with me who weren't playing (and therefore didn't know what was going on) and were quite intimidated by the sight of the approaching, stampeding crowd.
It was a lot of fun to spoof my location to Central Park and actually be able to take on gyms while I lived in the sticks. Naturally I also turned off spoofing when I'd have the chance to visit a metro area.
Android tells apps if the location fix they get is spoofed, and this tool cannot fix that. I assume Niantic checks for that and has been doing so for years now, so you'd need root, plus a Play Integrity bypass, to do this.
I built a small ESP based device which collected Wifi data (mac addresses) enough to use the Google API and plot its course on a map after the event.
It struck me it wouldn't be too hard to use the same device to replay the WiFi data back to the phone to make it think you were on that journey. It would also require shielding to avoid access to GPS and to the real WiFi access points around. Eminently doable though I would think.
As someone who has had to trick Google Play store country, it's a bit more complicated than that.
You can only change the Google Play country setting once a year. You can only change it if Google determine you to be located physically in that country. Based on my testing, the only combination I could use to trick them was:
* no SIM in the phone
* Wi-Fi connected to another phone's hotspot which is VPNing to the desired country
* GPS off
* payment method in the desired country
That way Google have no way of knowing you're not actually in the desired country. Just certain parts (even including a SIM card in roaming originally from desired country didn't work) weren't enough.
Apart from what the sibling comment mentions (certain apps not being available in the country you're in as far as Google Play is concerned), there's also family sharing app plans that are sometimes geofenced (everyone on the same family plan needs to live in the same country which is not how my family works so it doesn't work for me).
From a conversation with a Google employee, they also know what floor of a building you're in from the accelerometer and barometric pressure sensor. Probably even which direction you're facing from the compass.
The easiest way is to just have multiple accounts, ideally with payment methods/phone numbers for the relevant country. My primary account is locked to Belgium because of family sharing, but I have a separate US one with a US CC I made when I lived there. And a separate Swedish one with a Swedish CC because I live in Sweden now. I can just switch between the accounts in the Play Store and have apps from all three installed and auto-updating at all times.
There's a bunch of commercial apps to do the same for iPhone, but they all feel incredibly scammy (though I've tested a few, and they work fine). I'd love to find an open source option, or even a pointer to the requisite APIs.
GPS based games watch for this stuff as table stakes. They don't want you getting more "free" currency or items than you are normally expected to get because that screws with their profits
There are tens, if not hundreds of mock location provider apps available on Google Play and that feature has been supported on Android since Android 1.5 from 16 years ago. Just curious, why is this app, specifically, any different?
The android development world is new to me, but I failed to find a good location mocker when I needed one recently. I tried a few of the popular ones. They were either filled to the brim with spam or broken in different ways (un-scrollable UI, generating then immediately swallowing their own permission prompts, and/or broken travel simulation).
I would pay for an app that works properly, if only I could find one. Next time, I'll probably give this one a try.
You can use the android emulators. There you can define a fixed point or also a route which it will follow (and give you location updates). But maybe this project is interesting for real devices.
The problem with all of them is that Android lets apps check if location is being mocked via the mock location API.
A good mocking API should not let the things being mocked know that they are being mocked at.
You can modify a fork of Android to do this at the OS level, I suppose.
But I wonder if I could make a phone case that emits GPS signals that make my phone think it is in an arbitrary location but without interfering with anyone standing a reasonable distance away from me.
It's very very simple too. I made one that that just randomly changed the location within a specified area years ago. To learn the API. It didn't work very well. I wanted to grab the users actual location and offset it randomly. So a user could choose to degrade the accuracy of apps tracking their location.
But once you've set it as at THE mock app you can't get your actual location to offset (maybe this has changed since.)
despite my attempts to make sure it ran correctly in the background it would always stop working after a while. That was the hard part at the time , making anything run in the background without the phone killing the process or eating the battery.
I use it to gamify (not games or such -) a lot of things, but it’s also used for “fraud” or such, one thing when I was researching was that Pokémon go users do this. I just do it for geoarbritage pricing - without a play account on google phones. IMO I don’t think google play follows geographic pricing like apple does with their store (address/credit card in other geographic region)
Coincidentally it’s harder to do the above on an iPhone.