Android permissions with Bluetooth LE and Location not recognized immediately

[Rollo62 536]

Hi there,

 

I see some strange behaviour here when using Bluetooth with Android in the background.

I'm using the permissions

BLUETOOTH , BLUETOOTH_ADMIN,  ACCESS_COARSE_LOCATION , ACCESS_FINE_LOCATION

 

and there is the new permission
ACCESS_BACKGROUND_LOCATION

 

Currently I do not really use lcation at all, only in combination with Bluetooth LE, which requires that.

Since I want to use Bluetooth in the background, it seems that I have to set the ACCESS_BACKGROUND_LOCATIONas well.

 

Usually all works well, but I can see a strange effect after first install:

 

Only when the app is first time installled,
- I see the first permission alert popping up, and
- usually I set location permission to ALWAYS

- If I check the system permission dialog, I can see that location ALWAYS is perfectly set in the Android system

- ! But Bluetooth LE its NOT working.

 

Only after that I do,
- close the app (closing not really needed, also good enough to change the system permission dialog to "WHEN IN USE")
 

- change the location permission to "WHEN IN USE"
 

- open or start the app again

- ! opening, after changing the permission, will re-start the app, which is same as close/open
  So that really close/open is not needed, the system permission change causes the same effect.
  ! Changing from "WHEN IN USE" to "ALWAYS" doesn't re-start the app.
 

- the app is asking again for location "ALWAYS", as it should

- when I set "ALWAYS" (the second time), only then Bluetooth LE is working
 

Conclusions:
- So seems to work only from the 2nd time setting "ALWAYS", permission needs to be switched to "WHEN IN USE" once before.

- I can also install the app, set permission alert to "WHEN IN USE", and then in system dialog change from "WHEN IN USE" to always,
  the app doesn't re-start, but seems to work with Bluetooth now.

- It needs a sequence with "WHEN IN USE" firstly be required, before switching to "ALWAYS", is that the case ?

 

Any clues what the real reason for this odd behaviour might be ?

 

 

 

 

Edited July 8, 2020 by Rollo62

[Rollo62 536]

I have made some more tests, with a pure Bluetooth DiscoverDevices search.

 

It seems that Android requires always the ALLOW_BACKGROUND_LOCATION at Android 10 now,

although I understand the documentation differently.

https://developer.android.com/about/versions/10/privacy/changes

 

The table should say that normal foreground only operation should be possible

 

Now it isn't discovering any longer, I need to have ALLOW_BACKGROUND_LOCATION defined.
While it didn't accept the forground immediately, even if background is set.

In a minimal sample the manifest looks like this

<?xml version="1.0" encoding="utf-8"?>
<!-- BEGIN_INCLUDE(manifest) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.embarcadero.T355_bleAdvData"
        android:versionCode="1"
        android:versionName="1.0.0"
        android:installLocation="auto">

    <uses-sdk android:minSdkVersion="23" android:targetSdkVersion="29" />
    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.BLUETOOTH" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-permission android:name="android.permission.CAMERA" />
    <uses-permission android:name="android.permission.INTERNET" />

    <uses-feature android:glEsVersion="0x00020000" android:required="True"/>
    <application android:persistent="False" 
        android:restoreAnyVersion="False" 
        android:label="T355_bleAdvData" 
        android:debuggable="True" 
        android:largeHeap="False"
        android:icon="@drawable/ic_launcher"
        android:theme="@style/AppTheme"
        android:hardwareAccelerated="true"
        android:resizeableActivity="false"
        android:requestLegacyExternalStorage="true">

        
        
        
        
        <!-- Our activity is a subclass of the built-in NativeActivity framework class.
             This will take care of integrating with our NDK code. -->
        <activity android:name="com.embarcadero.firemonkey.FMXNativeActivity"
                android:label="T355_bleAdvData"
                android:configChanges="orientation|keyboard|keyboardHidden|screenSize"
                android:launchMode="singleTask">
            <!-- Tell NativeActivity the name of our .so -->
            <meta-data android:name="android.app.lib_name"
                android:value="T355_bleAdvData" />
            <intent-filter>  
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter> 
        </activity>
        
        <receiver android:name="com.embarcadero.rtl.notifications.NotificationAlarm" />

    </application>
</manifest>
<!-- END_INCLUDE(manifest) -->

How to set up correctly foreground and background Bluetooth operation now, is this an Android bug,

or am I missing something ?

 

Edited July 9, 2020 by Rollo62

[DelphiMT 5]

I had issues similar to this when making an app that uses Bt LE on android. I'm traveling now and when I get home (in a few days) I'll dig out my notes and provide some examples of how I worked around this. My fuzzy recollection is that because Bluetooth can be used to infer someone's location, you have to have all the location permissions granted, and IIRC it seemed to matter that you do them in a certain order.

[Dave Nottage 557]

12 hours ago, Rollo62 said:

The table should say that normal foreground only operation should be possible

Is that not what this is saying?

 

12 hours ago, Rollo62 said:

Now it isn't discovering any longer, I need to have ALLOW_BACKGROUND_LOCATION defined.

If it doesn't discover when the app is in the foreground, it sounds like a bug; either in the system or documentation. 

You don't happen to have a basic test project, do you?

[Rollo62 536]

7 hours ago, Dave Nottage said:

Is that not what this is saying?

 

If it doesn't discover when the app is in the foreground, it sounds like a bug; either in the system or documentation. 

You don't happen to have a basic test project, do you?

 

Yes, its saying like that in the specs, but I only get foreground access when additionally the background permission was given.

That would explain the need to permit twice, since "WHEN IN USE" seems to be completely ignored, at least in my Samsung S9 Plus.

 

@DelphiMT

Thanks, looking forward to your explanatons regarding to this.

 

Probably these Android quirks has something to do with adding the Covid-19 API in a hurry, which requires always background ?

Edited July 10, 2020 by Rollo62

[Rollo62 536]

@Dave Nottage

Here is a stripped down sample, with its foto story ...

Hope you can spot an issue here.

 

When pressing first time, it enables BLE

 

Pressing 2nd time asks for permission, as it should ...

 

Of course I give permission "WHEN IN USE",

Then its discovering, but NOTHING found (I can retry as often as I want)

 

Its NOT a permission problem, Android shows while app is running that "WHEN IN USE" is fine

 

If I change this to "ALWAYS"

 

Then the app is still running (no restart), and I can discover now perfectly

 

 

 

Can you spot an issue, I'm afraid this could be an Android issue ?

I re-order the requests, as @DelphiMT propose, already in this sample.

 

What I didn't checked is to ask for permission in two steps, probably that helps:

1. Ask for Location

2. Ask for Bluetooth

 

Is that they way how it should work (but it was workong fine before) ?

 

T356_AndBleTest.zip

[Rollo62 536]

@Dave Nottage

Curious me has tested the 2-step process too, first ask for LOCATION, and then ask for BLUETOOTH permission.

But no luck, still need to change in Android system to ALWAYS, see enclosed project.

 

Seems I have to blame Android for this, or is there any workaround ?

I hope that DelphiMT has a good explanation.

 

T356_AndBleTest_2Step.zip

Edited July 10, 2020 by Rollo62

[Rollo62 536]

Since I suspected that Android needs some more time, I also checked a 3-step process.

Where I need 3x press the button 1. location, 2. bluetooth, 3. discover, to avoid too fast calling the API.

 

What I can tell is that it makes no difference.

T356_AndBleTest_3Step.zip

[Rollo62 536]

I just tried to add ALLOW_BACKGROUND_PERMISSION, which shows ALWAYS as option, as it should.

But still I need externally to change the Android options ONCE, only then access is granted.

 

I think I should forget that for a while, I hope my customers will understand that this is an Android issue.

Would be great if this is somewhere documented, so that I can proove this behaviour to angry customers.

 

I think 'm getting too old for this shit, the last months I was only catching several issues in various systems.
Not that I could really work on my own projects, as I should, but wasting my time finding workarounds for things that should be running.

 

 

T356_AndBleTest_4Step.zip

Edited July 10, 2020 by Rollo62

[Rollo62 536]

I still have no clue what happens here, so I started another CrossPost in the German DP.

[Rollo62 536]

I did some more tests, see enclosed.

Test5 = with      ALLOW_BACKGROUND_PERMISSION in Manifest

Test6 = without ALLOW_BACKGROUND_PERMISSION in Manifest

 

Doesn't make any difference, I always need to change permission extenally ONE time back-and-forth,
before I get results from Bluetooth scan.

Strange.

T356_AndBleTest_5_6.zip

[Rollo62 536]

This seems to be a longer story, so I checked the same under Rx10.3.3: works fine, under Rx10.3.3 has above issues.
My android configurations (should be IDE pre-installed both for 10.4 and 10.3.3)

Quote

//## Rx10.3.3:
//## - Android SDK Tools      : 25.2.5
//## - Android SDK Build-tools: 28.0.2
//## - Android API            : 26 Rev 2
//##
//## Rx10.4 Patch 1:
//## - Android SDK Tools      : 25.2.5
//## - Android SDK Build-tools: 29.0.6
//## - Android API            : 29 Rev 4

So I will check possible Android updates now, with the hope that newer API versions has fixes this.

Not sure if an API update solves or make it worse, so I'm afraid I have to check carefully, but I can only check tomorrow.

 

You can find the next Test_007 enclosed, with separate projects for 10.3.3 and 10.4, which were newly creted projects.

 

Update:

I'm afraid no Update is here really available, but I will check more deeply tomorrow.

At least I cannot see any updates related to API 29 when searching here, maybe I pressed the wrong buttons ....

 

T356_AndBleTest_007.zip

Edited July 15, 2020 by Rollo62

[Dave Nottage 557]

13 hours ago, Rollo62 said:

This seems to be a longer story, so I checked the same under Rx10.3.3: works fine, under Rx10.3.3 has above issues.

I'm assuming that was meant to say: "under Rx10.3.3: works fine, under Rx10.4 has above issues"?

 

If you haven't resolved it before the weekend, I'll take a look

[Rollo62 536]

@Dave Nottage

Right, but meanwhile I think the culprit is Android-29 API (Rx10.4), while Android-26 API (Rx10.3.3)  works still fine.
That would be no big issue, if not Android would reject the old API-26 in 15 days.

In the last test I put projects, for Rx10.4 and Rx10.3.3 to test, just see the behaviour of 10.4 when requesting ALWAYS.

Maybe its only an issue with my test phone here (Samsung S9 Plus), but I have similar feedbacks from other customers too recently.

 

I will try to switch back to Rx10.3.3 now, to prepare a last API-26 update before August, so that I have more time to find a workaround.

 

 

Edited July 16, 2020 by Rollo62

[Rollo62 536]

I reworked my projects back to 10.3.3 (API-26) again, so they all went fine there.

 

Today I was looking if an update of API-29 might exist, which helps to fix this issue.

Unfortunately it seems that SDK Platform 29 Rev.4 is the most current one, which is already installed.

In the Android site I cannot see anything newer than this, only when moving to some beta (which I don't want).
 

 

I checked also the behaviour with the new Patch 2, which makes no difference (as expected),
the issue seems to be related to the API-29 really.

Without an newer SDK Platform version available, I'm afraid that I cannot fix this by simple SDK update.

So I have to dig a little deeper.

 

Android seems to have changed location and permission heavily in API-29.

 

 

 

Edited July 22, 2020 by Rollo62

[Rollo62 536]

Just to finalize this:

I could solve the issue, with the help from Phillip in the German DP.

 

After I cleaned-up the permissions, I always used to set COARSE and FINE location both, I've set to COARSE location only,
which I was sure that this is good enough to start Bluetooth.

But that was a wrong assumption, as the Android documentation tells me here:

Quote

The other permission that you must declare is ACCESS_FINE_LOCATION. Your app needs this permission because a Bluetooth scan can be used to gather information about the location of the user. This information may come from the user's own devices, as well as Bluetooth beacons in use at locations such as shops and transit facilities.

 

The strange thing was that BLE started anyhow ignoring that it was not allowed to, after an external permission change back and forth,
while I expected a sudden, startup crash (as usual with permisson issues), when touching any of these dangerous APIs.

Never saw such half-allowed states before, and I still think this is a kind of Android bug.

Maybe I've got used to sudden, startup crashes so much meanwhile, that I don't think twice when they not appear .

 

 

Edited August 3, 2020 by Rollo62