jcwhit

I can confirm that this idea works. I have actually taken it a step further using the template from the beginning of the thread as shown here <%uses-permission%> <!-- for these next lines to work, uncheck from projects "uses" options --> <uses-permission android:name="android.permission.BLUETOOTH" android:maxSdkVersion="30" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" android:maxSdkVersion="30" /> <uses-permission android:name="android.permission.BLUETOOTH_SCAN" android:usesPermissionFlags="neverForLocation" /> <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" android:maxSdkVersion="30" /> ........ NOTE: as before this is just a portion of the template file I have tested this on Android 8 and 12 so far and it works like I think it would. Android 8 permission granting has not changed. Android 12 now only asks to connect to nearby devices and to determine relative location. I assume this is just the standard Android display for this. Android 12 no longer asks about using the Phone's location, fine or coarse. So this makes the user interface a lot cleaner. What Delphi is missing is the ability to add these qualifiers to a permission. That may be to hard to implement in clean way. One downside to this approach, you need to save the template file. Next Delphi upgrade will erase this template, so keep a copy.

Has anyone solved this problem? I have working apps with android:targetSdkVersion="32", but the UI is not very friendly. It is asking for location permission, because you have to grant ACCESS_FINE_LOCATION, if you dont use the neverforlocation permission flag. I have tested on Android 7,8,11 and 12. Android 12 asks for location permission and shows to fine and coarse as an option. If you select coarse, then BTLE will not work. There are some other anomalies happening that i have not worked out yet. Here is the uses-permisson portion generated by 11.2 <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.BLUETOOTH" android:maxSdkVersion="30" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" android:maxSdkVersion="30" /> <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" /> <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" /> <uses-permission android:name="android.permission.BLUETOOTH_SCAN" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Greetings As i commented in RSP-35804, I also had problems converting existing Android Apps. For those who do not have access, here is the text. " I came here from RSP-35919 (Android 12 - Bluetooth LE discover devices - access to location). I was updating a BTLE app from API 23 to API 30 for the Aug 2022 deadline. I started with Delphi 11.1 and had the same issue. The APP would fail during initialization. I backed up to 10.3.3 and API 23 and verified it still worked. Then moved through the API levels one at a time, changing to 10.4.2 when needed, then 11.0 and finally 11.1 and API 30. Made the changes needed at each API level and compiler version. (Note: when the permission types changed in 11.0, I created conditional compiler code so I could easily go back and forth between 10.4.2 and 11.0). It now works. What I changed that allowed it to work on 11.1 and API 30, I am not sure. Tested on Android 7,8,11, and 12. Both 32 and 64bit. Again, I am only doing BTLE device discovery, not location." I have now converted my second App which was a little more complex than the first one. I had similar but different problems. At one point I had the error that started this thread, along with the location error RSP_35804 and a few others. I used the same basic process I describe above. What I am beginning to think is that the issue is a combination of the Android Manifest, library update (as described here) and carefully reviewing the project deployment page. Here is the closest process I have to a conversion checklist. At every API level change, delete both the Android Manifest Template and the Android Manifest. Start fresh. If you manually change this, make sure you save your changes elsewhere so you can update these later. Since I had not updated in a while, I had to start with 10.3.3, you start with where it worked last. Make sure you clean the project before Building. Then go look at the directory and see what is left. You might want to delete whatever is left, unless it is a file that you specifically need to be included. (See the next item and CLASSES.DEX) Carefully review the Project Deployment Options Page (PROJECT->Deployment) in all configurations (32 bit, 64 bit, DEBUG and RELEASE). This is especially true when going to version 11.x. The CLASSES.DEX file moved from the DEBUG/RELEASE directory to a <projectname>.classes sub-directory. Going back and forth between 11.x and 10.4.2 can orphan the CLASSES.DEX and I think this is causing issues. (What I dont like is you cannot delete anything on this page that the IDE inserted. So if you have been carrying this project since 10.0 or before there can be a lot of excess baggage.) When you get to version 11.x, it is imperative that you update the libraries as described in the link above for every project. This is not an IDE global update, but appears to be a project specific update. The better approach may be to start the project fresh when moving to 11.x. I have not done this, so I do not know what fun things this idea can bring. Also Jasja idea did not work for me.

I have read the documentation several times and followed step by step. The item that seems to determine APK or AAB in Android 64 bits is the setting Project Options/Building/Compiling/Other Options -- Generate Android 32 bit and 64 bit binaries No matter which setting I used, only an AAB file is generated, with both 32 and 64 bit .so files. In Android 32 bits, this option is not present. This might make sense given what i found at the Play Store. This is all moot though. Reading more in the Play Store I find that after August 2021, only AAB will be accepted for new Apps and after November 2012 for updates. Might as well convert to AAB now and move on.

So I admit I am late to this party. My 4 apps are very simple and control electronic devices that I design and sell. I finally am getting around to updating to Android 64 bits because I am doing a major overhaul of one of the devices. I have switched two of the APPS to Android 64, compiled and started testing. So far no issues. I tried to make a RELEASE-APPLICATION STORE version and it only generates .AAB file. Since I control the keystore, Google will not let me upload a .AAB file. My question then, is it possible to generate an APK file when using Android 64 bits. I would like to control the Keystore (old fashioned thinking), but if .AAB is the only option then I will move on. My environment Delphi 10.4.2 Build 19041, 64 bit edition Used existing project and just changed the settings to Android 64 bits Tried both settings in Project Options/Building/Compiling/Other Options -- Generate Android 32 bit and 64 bit binaries Removed the .dproj and started over again, but still only generated .AAB file Thanks in advance

This issue shows up when writing a Characteristic from the Andorid app to the BT device. Here is the sequence using these TBluetoothGattCharactertistics methods SetValueAsUint32, then 4 bytes are transmitted. SetValueAsUint64, then 8 bytes are transmitted SetValueAsUint32, then 8 bytes are transmitted, the first four bytes contain the new 32 bits and the remaining 4 bytes contain the previous 64 bit value ************************************************************************************************************* In System.Bluetooth we find this method @line 2717(10.4.2), which all of the above methods call procedure TBluetoothGattCharacteristic.SetValueAs<T>(AValue: T; Offset: Integer); var LBytes: TBytes; begin LBytes := Value; if (Length(LBytes) < Offset + SizeOf(AValue)) then SetLength(LBytes, Offset + SizeOf(AValue)); Move(AValue, LBytes[Offset], SizeOf(AValue)); SetValue(LBytes); end; LBytes is always the last value sent (64 bits or 8bytes in the above example). As long as offset is zero (0), following a 64bit value with a 32bit or less value, will always result in SetLength not being called. And as long as offset is zero, this procedure can never reduce the size of LBytes, it can only increase the size of LBytes. ***************************************************************************************************************** my work around was to create a method in my BT wrapper that creates a variable ClrValue of type TBytes set length to 1 call the method SetValue(ClrValue) This resets the TBluetoothGattCharactertistics property Value to be length 1 and thus the SetLength in the above code will always be called and the correct number of bytes will be transmitted. ***************************************************************************************************************** I went back and checked 10.1 Update2 and the same code as above is there. This may be expected behavior, I dont know, Other than my little work around, I found no intrinsic way to change the array length and thus the bytes transmitted. If you call SetValueAsUint32, I would expect 4 bytes to be transmitted, regardless of what was transmitted before.