I would like to replace the default GPS location provider on android phones with my own coordinate source.
Is there any layer/API/library/provider that would allow to be replaced with my signal provider instead of the built-in hardware GPS, or read from an external plugin? It should allow all apps that rely on the GPS service to receive my signal instead of GPS.
Ideally, the replacement should still be able to access the GPS signal (for comparison/correction or to toggle between the two providers).
I am thinking for example of implementing my own LocationManager, and registering it in the system (as optional or default), if that is possible. But at this stage, I am still trying to find out what is possible and suitable.
Thank you for any pointers.
Replacing the "default" is not allowed at this time and the only work around is to create a mock provider. First you must set the security permission:
<uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" />
Second, set your code to use the mock provider which you will create. There is some excellent information about how to accomplish this here: http://diffract.me/2009/11/android-location-provider-mock/
I'm only in the process of reading about the android SDK at the moment. However my understanding is that you would provide an implementation of a GPS_PROVIDER intent.
Any application can then divert to using the user preferred GPS_PROVIDER intent.
See:
http://developer.android.com/guide/topics/intents/intents-filters.html
I'm pretty sure the default location providers for fine location are baked into Android.
Given that Google are becoming more conscious about potential misuse and abuse of system resources by applications, i'd say that's a good thing. Otherwise people would be able to trick the user into thinking they're somewhere else, using the trustworthy sounding 'Use GPS satellites' setting.
The only way I can see that you can add a location provider is via android.location.LocationManager.addTestProvider(......), which requires the permission ACCESS_MOCK_LOCATION. Now, this method and permission are both documented as being for "testing" purposes. I can't find a source that specifically says that that permission is not granted for market release apps, but I strongly suspect that to be the case.
Related
Using Xamarin Android, I need to be able to access location updates from within a service.
I have tried the native Android.LocationManager, Plugin.Geolocator, and Xamarin.Essentials.Geolocation, but none of them seem to provide location updates.
If I do it inside an activity, it works fine, but I have a requirement to post location updates from a service which launches at boot time.
Yeah, I know it's a "privacy violation" or whatever, but the app is only used on company devices for a specific internal use.
I saw somewhere that requesting permissions from a service "is tricky," so I know it's possible, but the guy didn't elaborate on how to do it.
I'm trying to figure out which android API calls need these permissions:
android.permission.HARDWARE_TEST
android.permission.DEVICE_POWER
android.permission.DIAGNOSTIC
android.permission.GET_TOP_ACTIVITY_INFO
I read the descriptions on the Android developer website, but I found no way to perform the operations that these permissions allow.
EDIT after HexAndBugs answer: I know these permission are not intended for third-party application, but I'd like to use them in a experimental environment, playing the role of the manufacturer.
These aren't intended to be used in your apps (unless you are a device manufacturer), so you won't find things that need them in the API. Note that they all say Not for use by third-party applications. See, for example, DEVICE_POWER
Although these settings are not for usual app but if you have a rooted device and you need to control, lets say hardware test then you would have to add it to your apps permisson and override the ususal CET testing pannel
But FYI it can brick the phone or device if you tweaksomething wrong so beaware;
i personally have used couple of these permisson for e.g getTop Activity info to monitor that my app is always on foreground
I work in QA for an company that helps market applications. Currently I have been tasked to ensure location dependent apps function if correctly (ie if im in russia the app displays the russian content and if i change to us the app updates to the us content)
I have tried numerous items to accomplish this but get no where.
What i have tried:
Proxy. Setting this up via wifi to several locations. Both the app and the device still show my current location.
Apps: I have tried all of the following apps and they all give the same result as above.
Fake Location
AutoProxy
Fake GPS
I have enabled developer mode on the devices, and have ensured that "Mock Locations" is checked.
Use case 1:
A developer whats us to test his app which is only available in england. Google Play still sees me in US
Use case 2:
A developer releases a game where the background changes based on your location if i cant force the location change I cant verify this feature works.
Im guessing the fails so far are due to the fact that the location being called in our test apps is network location not GPS?
Any help would be awesome. Even if you could just point me in a direction.
Thank you Greatly
J
Update:
Ok, Thanks to the answers about google play and mock locations. So with those in mind lets think about it from another perspective. If the app is not calling for mock location, Is there anyway to force a mock location override? im trying to cover all the bases here, One app for sure does not use this method, so I still need to find a way around.
depending on how they are calling for the location, I would think (remember im knew here) that using a proxy would work, however as stated above, i'm not getting anywhere there either. Did try a few free proxy's from hidemyass but even the browser wouldn't work with them.
Yes, network location does not get faked by mock location providers. I don't know why not, but it only fakes GPS. In addition, your app has to request the MOCK permission to get it. If it doesn't have this permission, setting a mock location will not actually fake anything to the app. This is for security purposes, so a malicious app can't start broadcasting the wrong location to the phone.
I have some code that detects when there is new voicemail. It's based on a PhoneStateListener.onMessageWaitingIndicatorChanged() implementation (so technically it fires only when the MWI indicator changes, not necessarily for every new voicemail).
It has been working perfectly for many months until 4.x.x updates to the devices.
Now, this works when the device is rebooted, otherwise its very unreliable. I can see the voicemail icon appear in the notification bar, but the debug logs in onMWIChanged stay silent.
I know that with 4.x.x there is a voicemail provider API. Thinking that this may have a connection, I added the android.intent.action.NEW_VOICEMAIL and android.intent.action.PROVIDER_CHANGED intents to my receiver, but they don't fire (in my BroadcastReceiver onReceive) either (my app's minSdkVersion is 8).
This is a post from Android Developers about the Android 4.0 APIs.
http://developer.android.com/about/versions/android-4.0.html
If you scroll down there is a section about Voicemail Providers where it explains:
Because the APIs currently do not allow third-party apps to read all the voicemails from the system, the only third-party apps that should use the voicemail APIs are those that have voicemail to deliver to the user.
However, I assume if you are trying to receive voicemails from a third party and not from your service then this still may be possible. Check out this link about VoicemailContracts where I believe it says you need the permission ADD_VOICEMAIL in your manifest to use the actions you are using above.
http://developer.android.com/reference/android/provider/VoicemailContract.html
There are also samples that I did not get a chance to look at called Voicemail Provider Demo in your SDK. I hope this helps.
It does require the READ_PHONE_STATE permission. Although, if it worked before you must of had it set.
See LISTEN_MESSAGE_WAITING_INDICATOR.
Let's say I have taken over development of an Android app, and my boss asks me why our app requires certain permissions to be displayed to users who buy the app on the Android Market.
Are there any tools or tricks I can use to determine what code triggers each permission, so I can figure out why our app functionally needs those permissions? In particular, I am interested in these permissions:
Phone Calls - Read phone status and identity
System Tools - Retrieve running applications - Allows app to retrieve information about currently and recently running tasks, May allow malicious apps to discover private information about other apps.
The app is a GPS tracking app, and it's not obvious why this permission might be needed.
It would also be helpful to get any tips on why this permission might be needed, even if you can't tell me how to directly analyze the code to find out.
Here is how I would track these down.
Step 1 - Find the manifest permissions declared in your AndroidManifest.xml
Basically everything inside the <uses-permission /> tags e.g.:
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
Step 2 - Search developer.android.com for classes that use these permissions
Let's take the case of READ_PHONE_STATE, the goal is to find which packages require this permission. A simple search on the dev portal for "READ_PHONE_STATE" starts our search, we are looking for classes here, in the top 5 search results I see the following classes:
TelephonyManager
PhoneStateListener
Click on the classes and get their package names:
android.telephony.TelephonyManager
android.telephony.PhoneStateListener
Step 3 Find classes in your project that import these packages
A simple grep will do, or a Ctrl-H in eclipse, File Search -> Containing text
Step 4 Comment out the import and see what breaks
These are likely candidates for why the permission is required. Confirm the methods in question by looking at the dev portal to validate that the permission is indeed required by that method.
Finally you should be able to tell your boss, READ_PHONE_STATE is required because we call function XYZ which gives us UVW.
Remove a permission and see where the app fails. The answer will be in the logcat output.
That's not an ideal solution though, since you might not know what you need to do in the app to trigger that permission.
I suspect "Read phone status and identity" means that the app is using the device IMEI or similar identifying information to uniquely identify the device to ensure that the app is only being run on a registered device. Or it might just be used as a sort of cookie to track the owner. Look for that code. And remove it, because that's the wrong way to do it. If you need to identify a specific android device, use ANDROID_ID from the Settings.Secure class. http://developer.android.com/reference/android/provider/Settings.Secure.html
As for "Retrieve running applications", I find that one somewhat suspicious. A very common way to implement GPS tracking is to launch a separate service in its own process. This way, if the app should crash, the service will keep going and can be re-attached. In this case, it's possible that the app is using the "Retrieve running applications" to identify and kill the service process. But if so, it's a clumsy way to do it.
With the latest build tools, you can run lint check which will highlight for you all the android SDK method calls which are requiring permissions.
See announcement here http://android-developers.blogspot.com/2015/07/get-your-hands-on-android-studio-13.html and documentation here https://developer.android.com/tools/debugging/annotations.html#permissions .
This is based on android annotations and after some adoption time 3rd party libraries can integrate permission annotations also
The answer for your boss is "because certain API features/calls/methods we use in our app require calee to hold certain permissions. It is for security reasons, and that's the way Android works". As for mentioned permissions - you have to check the code to see if these permissions are really required. Read phone status and identity may indicate your app try to get IMEI or something like this to uniquely identify device. Retrieve running applications - see no reason for GPS tracking app to hold this. But maybe you use 3rd party lib/code that uses this.