Develop Reference

Enable Bluetooth without auto-connecting to devices ("quietly") in Android

I found out there's a system function called IBluetoothManager.enableNoAutoConnect(), which by the name, seems to do exactly what I've been searching for hours: enable Bluetooth without auto-connecting to devices.
I can call the function, but...
java.lang.SecurityException: no permission to enable Bluetooth quietly
Because...
if (callingAppId != Process.NFC_UID) {
throw new SecurityException("no permission to enable Bluetooth quietly");
}
So, is there any other way of calling this function? Like some ADB command? Or through another class? I also found a function that does the same here, in AdapterService.java. But I don't know how to get to it (doesn't even appear on Android Studio).
Note: I have root and system-privileged permissions (just not signature ones), and I'm using the internal/hidden SDK, so I have access to the classes and everything without needing reflection (and still, AdapterService doesn't show up - unless there's a problem with the "SDK" and it's not showing all it should?).
(PS: I say "quietly" in the title because in the source, the variable that tells if it's auto-connect or not is called quietMode.)
EDIT: actually the function is directly in BluetoothAdapter, without needing to go for the interface. Not sure how I didn't notice it. But anyway, same problem.
EDIT 2: more specifically for Android Oreo and below (or Pie and below), as I just found a function called setSilenceMode() on BluetoothDevice, and it might do what I'm wanting (not tested), but still, missing on older APIs.
Thank you

Android NFC enableReaderMode stopped working; needed to delete and reinstall app?

We have an app utilizing NFC and recently migrated from enableForegroundDispatch to enableReaderMode. Since then, we have been receiving bug reports where the user intermittently has trouble scanning tags.
I was troubleshooting remotely with a customer today who was unable to scan any tags (the app was working through yesterday). Sometimes they would receive an "NFC read error. Try again" message.
When we had them install the older version of our app which uses enableForegroundDispatch, NFC scans worked as intended. Scanning using the NFC Tools app was also working during this time, as was scanning with no app open. We tried rebooting the device and also toggling NFC on / off with no luck. It was just our app.
After much debugging, what appears to have resolved it was to fully delete our app from the device and then reinstall it. The device is a Google Pixel 2 running Android 11.
I have read countless threads about enableReaderMode and am also aware of this bug affecting kiosk apps in Android 11 (but our app isn't a kiosk). I also read about how there is a bug where Android might think our app is not in the foreground.
Is there any credence to the theory that deleting our app (vs. updating the same installed package with different builds) is what resolved this, and if so then what exactly is happening that is causing this?
Edit: I just found the threads about "NFC service dead" and am guessing this is what happened.

I have read the public code for NFC service, I cannot remember it having anything that would be affected differently by update vs uninstall/install other than possibly the Manifest(PackageManager?) permission to use NFC.
I have not looked in to details about how an app update updates the Manifest permissions, but guess an update might not update the permissions if it thinks they are not changed whereas remove/install would probably delete the whole entry and re-add it thus if there was corruption in the permission list a remove/install would likely fix it.
Also if the NFC Service is dead then other App's would not scan as well. I do seem to remember there is something in there to restart the NFC service if it had died.

What happens in Android if you run code that requires a permission but fail to have it?

I am talking about the quality issue (bug) that an Android app needs a permission that is declared in the Manifest, but fails to request it from the user at the appropriate time and executes the code without the necessary permission. This was not possible in older Android versions (user accepts all permissions in bulk), but seems to be possible when using newer versions that copy Apple in most regards.
At least during testing one can start background services and use bluetooth without any alert by Google popping up. Is that different for apps in production?
Does the app crash with an Exception?
Does the code get executed?
Does the app get rejected in review? (Always?)
Does the app get delisted from the store?
Does it depend on Android's Version?
I deal with an age old app that has bluetooth discovery code to find and connect to dedicated hardware, that is rarely used via a cordova plugin triggered by content. There is old altbeacon code potentially activated that may even need access background location (https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions). It will take some time to get this dead code up to quality. Definitely more time than the week we have.

Does the app crash with an Exception?
yes if you try to have operations depends on returned date witch is null
Does the code get executed?
code will execute with exceptions because data access denied you can check if permission granted or not and add scenario for each state
Does the app get rejected in review? (Always?) not sure but with crashes there is high potential to get rejected
Does the app get delisted from the store?
depends on why and how you are using data
Does it depend on Android's Version?
yes access data and permissions changing point is android oreo

My tests with Bluetooth permissions revealed the following: Required permissions are BLUETOOTH_ADMIN, BLUETOOTH and for VERSION_CODES.Q additionally Manifest.permission.ACCESS_BACKGROUND_LOCATION (see: https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions).
BLUETOOTH_ADMIN, BLUETOOTH do not show any system alert-dialogue to the user. In Android Q+ if you fail to check for the required ACCESS_BACKGROUND_LOCATION permission, nothing happens and your code executes without exception (mine did execute an UART command on hardware with Samsung tablet). The app passed review although the check is missing (of course I will fix that ASAP).
Note: the doc is ambiguous and states: "Services running on Android 10 and higher cannot discover Bluetooth devices unless they have the ACCESS_BACKGROUND_LOCATION permission." Probably general scanning while the app is active could be allowed. In that case missing exception would be explained.

Voice recognition not working as a service when Google Search version > 2.2.10.573038

Some friends and I have been working in an app that requires to have a service running listening for voice commands. We have successfully implemented the listener. However, after we started having problems because the operating system killed the service after a while (I suppose to reclaim some resources). We (apparently) fixed this problem by making the service a foreground process (calling startForeground).
We have been testing the app in a range of devices and we found out that the app was still being killed by the OS in some devices. Having a close look at this issue we found out that the devices where the app is being killed have Google Search version greater or equal to 2.3... (for instance 2.4.10.626027) If we uninstall the updates and downgrade to version 2.2.10.573038 then it works like a charm.
By the way, I have mentioned Google Search here because when we start the voice listener, a package named com.google.android.googlequicksearchbox is started.
Does anyone have an idea of why this might be? or what main differences exist between the versions 2.2.10.573038 (and older) and those after? Of course the solution would be to downgrade the version but we would like it to be compatible with the newer versions too...

How to check if some service on android is unavailable?

I discovered, that on some devices VPNService is unavailable even if they has proper android version (4.0 or grater). Is there a way to check is some serivce is realy available on device?
The tricky part is, that on some devices exception is thrown after calling establish() method, but on other devices this methods works fine, but app crashes after trying to open confirmation window. So resolution can not relay on check whether establish() throws an exception.

I am the author of the OpenVPN for Android app. I had to deal with these bugs too. The first one is easy. It will throw a ActivityNotFoundException. If you want to check this before you probably can check if the Activity mentioned in the intent exists.
http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/LaunchVPN.java?name=v0.5.28#380
The establish() problem is much harder to get. I use a catch all exception. In almost all cases the /dev/tun device does not exist or has the wrong rights. Checking for this will work but the implementation can change and headset vendor can theoretically roll their own implementation. It is like asking the OS: "Are you buggy?" and expecting a right answer ...
http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java?name=v0.5.28#351