Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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.
  2. 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
  3. 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.