I am working on a location based application. I want to turn on/off GPS through code. I found a solution from this [link]: Turning on and off GPS programmatically in android 4.0 and above? but app is crashing when i run this portion.
Please guide me with proper solution.
I want to turn on/off GPS through code
There is "enabled/disabled", and there is "on/off". "Enabled/disabled" determines whether any app can get GPS fixes. "On/off" determines whether the device is trying to get GPS fixes right now. GPS can only be "on" if it is "enabled".
If you request locations from the GPS_PROVIDER, and GPS is enabled, the GPS radio will turn on. If you stop requesting locations from the GPS_PROVIDER, and no other app is requesting locations from the GPS_PROVIDER, the GPS radio will turn off. Depending on how you configure your request for locations (e.g., once an hour), the GPS radio may turn off and on to save battery life, even while your request is outstanding. Hence, Android developers do not worry much about "on/off" — developers just request locations, and the hardware takes care of powering on and off the GPS radio as needed.
Your link really refers to "enabled/disabled". Android removed the ability for apps to enable and disable GPS back in Android 1.5, for privacy reasons. Malware authors have continued to try to find ways to get around this, because malware authors are not interested in user privacy. The link you cited was an exploit for a flaw in Android that allowed apps to enable and disable GPS. That exploit was fixed years ago. I am not aware of a current exploit that allows apps to enable and disable GPS.
Related
I am making a flash light app. So naturally most devices now a days have a built in flash for the camera but when a flash is not present I want to use the screen as the flash light. To make this functionality work I want to adjust the screen brightness so it can act as the flashlight.
To change the brightness I used code from this post. The code works fine and I can change the brightness without issue. As a side note this code I used works on Physical android 8.1, 10 and 11 devices.
My first question comes from a lint warning I get when adding the <uses-permission android:name="android.permission.WRITE_SETTINGS"/> permission. The warning says
"Permission is only granted to system apps". Now I can obviously just suppress this warning, but my worry is when I upload the app to the app store Google will either reject the AAB or the app will no longer be a "System app" once its downloaded from the app store. Will suppressing the error do anything?
My second question is is this a false positive? Looking at the manifest permission docs WRITE_SETTINGS has no special permission besides for having to get the users consent buuuut WRITE_SECURE_SETTINGS definitely does. As per the docs for WRITE_SECURE_SETTINGS "Allows an application to read or write the secure system settings. Not for use by third-party applications." So could this be lint thinking WRITE_SETTINGS is WRITE_SECURE_SETTINGS?
To my knowledge android (studio) currently only supports wifi detection and GPS detection with a timer that runs, for example, once a minute and checks the location and currently available wifi signals.
I was wondering of there are any more efficient methods to implement this as the app needs to run in the background, for example if I happened to get to a shopping mall and my phone detects/loses a familiar signal it, or when im 50m away from my home.
I'm still rather new to android development so there's much I dont know about it but attempting to search for this information mainly provides examples of detecting wifi state changes rather than detecting new wifi signals without connecting to them
I have a mobile phone with dual sim. If I want to turn on Airplane mode, its happening for both sim.
Is it possible to do for only one sim (user can select the one of the two) programmatically? I saw the posts over here, that they work till API 16. Any other work arounds?
As I can see this in the docs:
Some device settings defined by Settings.System are now read-only. If
your app attempts to write changes to settings defined in
Settings.System that have moved to Settings.Global, the write
operation will silently fail when running on Android 4.2 and higher.
Even if your value for android:targetSdkVersion and
android:minSdkVersion is lower than 17, your app is not able to modify
the settings that have moved to Settings.Global when running on
Android 4.2 and higher.
They say Settings.System are now read-only, but reading these blogs,I don't need your permission!, which explains how to skip the permissions part, by this way we can ask the user to give permission to turn on/off the airplane mode and escape the permission issue mentioned here?
Thanks in advance.
Is it possible to do for only one sim (user can select the one of the two) programmatically? I saw the posts over here, that they work till API 16. Any other work arounds?
There's no official Android API which supports this. Additionally, I'm not aware of any vendor/device specific SDKs which provides such an API.
They say Settings.System are now read-only, but reading these blogs,I don't need your permission!, which explains how to skip the permissions part, by this way we can ask the user to give permission to turn on/off the airplane mode and escape the permission issue mentioned here?
The example in this blog post has nothing to do with airplane mode.
Edit: Please also note that airplane mode isn't related to the SIM cards but to the connectivity hardware, e.g., Wi-Fi, Bluetooth, or cell radio modules. Thus, when enabling airplane mode this hardware is turned off. Depending on the device only one cell radio module might be built-in which would make it impossible to restrict airplane mode to a single SIM card.
I'm writing an Android app that I would like to eventually port to iOS and Windows Mobile (though I know absolutely nothing about them right now). I'd like my app to be able to find other phones within a certain radius (maybe 20-30 feet) that also have the game installed so that the users can interact with others in their current physical space. Is this possible and, if so, how?
I plan on the app requiring an internet connection so my first thought was to use GPS like described at iOS Find Other Nearby Devices (GPS locations), but that would require continually transmitting data to the server to update the user's location using both bandwidth and battery (not to mention the server resources). GPS also seems to take a while to get any sort of accurate fix, and even though I wouldn't store historical data I wouldn't expect users to trust me with that sort of private information (as well they shouldn't!)
I know there are proprietary technologies, such as Sony's NFC, but that's far too narrow a focus to use for an app that I'd like to be device and OS agnostic. What other options are there? Assuming the user is willing to give the app the appropriate permissions, what other methods could allow one device to find another nearby one, within a 10-15 meter range, that is practical for a large (million+) userbase? Is HTML5 Geolocation a better path? Or is GPS my only real option?
I did find Use Android GPS to detect and connect with other phones, but was hoping the past few years have opened up further options.
UPDATE
Thank you for all the responses so far. To answer some questions posed in the comments and answers, I thought I'd describe how I expect the apps/devices to interact.
All users who install this app will have an agent running in the background to update their current geolocation and to listen for pings. Any user may open the full program and send a quick request for all other users nearby. If I go the central server route, then the server responds to that request with a list of nearby usernames. The user can then pick one of those to initiate a connection, in which case the target device makes a sound to notify of a request to connect.
From there it's easy enough to handle the interaction between two devices. Finding those nearby users is the sticking point for me.
Options I can see
Bluetooth (BT). I don't know, if I'm not too skeptical about it, but I see couple of problems. Short range. The biggest energy consumption. Maximum 7 peers connected at the same time (but maybe it's enough...). The big advantage is that a lot of devices support BT.
BT LE (low energy). Ok, it helps energy consumption problem. But, requires Android 4.3.
WiFi Direct (aka P2P). I gave it a shot, I'm a bit disappointed. The problem is that it needs Android 4.0 or higher. Even worse, some devices don't have required hardware. I launched WiFiDirectDemo from Android samples on Samsung Xperia Miro ST23i. Clicked on "search" and the only thing I got was a toast "enable WiFi P2P - in your settings". I clicked on everything in that settings, there is just normal WiFi and other stuff, no mention about Direct or P2P. Xperio Miro just doesn't support WiFi Direct.
WiFi connection with a server through internet + device geolocation. Server keeps positions of users and answers questions like "who is 20 feet in my range?". The problem can be the precision of geolocation. If the walls are thick or you are in a place on earth with few satellites - it can be very inaccurate.
To sum up
There is greater probability that somebody will have WiFi turned on all the time than BT. BT also have some time limits after which it is turned off (they make it this way to probably save battery). So, WiFi seems a better choice than BT.
If WiFi Direct is popular enough for you - I would give it a try. If not, option number 4 seems the best. It's not ideal, I know, but at this point it's hard to come with something better (we still need technology development, WiFi Direct looks promising).
I would use the central server approach. Each phone sends position data to the server. The server notifies the other users when they are in range. To limit used data, only send positions when the device reports movement more then X meters.
Also, consider using a Ping button. The user presses it to send the position when they wish to find someone nearby. Position data would only be sent on this ping. This would use very little power and provide good privacy.
It might be possible to detect details about the connected Wifi access point. If you could get the AP or Gateway's MAC address, you could send that as a kind of position. All the players on the same Gateway would be close by.
I'm happily developing GPS aware apps using LocationManager and NmeaListener, so I am not asking about how to use the Android SDK, but how the Android SDK talks to the internal GPS SDK
I'm trying to understand how Android interacts with the GPS SDK to deliver, for example, the speed and direction values in the GPRMC sentence. Do they come directly from the chip SDK or are they calculatedd by Android?
I'm looking at Android source in LocationManager.java, but I can't find where it interacts with the GPS SDK.
Can anyone point me in the right direction please?
I expect the GPS is a separate sub system which reports data to the system over a serial NMEA connection. If so then the GPS module will calculate Speed (SOG) and Course (COG) using internal methods. For low cost GPS modules they typically have a filtered position difference method. Higher end GPS receivers use carrier phase measurements to get instant results.
I'm guessing that you are noticing a lag in the COG and SOG values and hoping that knowing more about how they are derived will help you correct the lag...