Dave Nottage

I've managed to come up with something without having to patch FMX.WebBrowser.Android, but it still required Java code. I've put a demo here: https://github.com/DelphiWorlds/KastriFree/tree/master/Demos/WebBrowserFileChooser Note that it relies on other units in the Kastri Free project: https://github.com/DelphiWorlds/KastriFree ..including the compiled .jar, so you might want to just clone the repo and load the demo from it.

EMBT need to modify the Java code for the WebBrowser class (in source\rtl\androiddex\java\fmx\src\com\embarcadero\firemonkey\webbrowser\WebBrowser.java) so that it uses a descendant of WebChromeClient that implements onShowFileChooser, much like the Java equivalent, here: https://stackoverflow.com/a/36413800/3164070 It's possible to do something similar by: Creating your own descendant (in Java), creating a jar for it and importing it Patching FMX.WebBrowser.Android to call setWebChromeClient on FWebView for an instance of your descendant

Thanks.. I've added my devices to the list.

Has anyone managed to make DelphiTwain: http://www.kluug.net/delphitwain.php work on 64-bit? The code loads the Twain DLL OK (TWAINDSM.DLL), however for me it fails in the LoadSourceManager routine: FTwainProc(Info, nil, DG_CONTROL, DAT_PARENT, MSG_OPENDSM, @FVirtualWindow) Which returns a result of TWRC_FAILURE. The corresponding condition code is TWCC_BADVALUE

Bumping this in case anyone else might be able to contribute, i.e. we're still having the same problem. Test case is still in the same location, i.e: https://github.com/DelphiWorlds/MiscStuff/blob/master/Test/RDSTwainTestCase.zip

In your TfmSelect.btnSelectClick method, move the Close statement to the beginning of the method.

Does this have anything to do with it? https://devzone.paylane.com/api-guide/cards/card-data-storage/

I receive: [Window Title] Project1 [Content] Could not save: A required privilege is not held by the client [OK] Which is odd, since SetTokenPrivilege succeeds. Using Delphi 10.3.2

Ah, thanks. Here was me thinking that it used domain name rules.

That's very odd, since it's perfectly valid. I'd report it to Google.

I have a Pixel 3a running in 64-bit mode with 4GB of RAM.

You don't think what? Neither of us made any claim otherwise.

Yaron didn't mention a requirement of > 4GB memory; he was talking about devices with 64-bit processors. Most devices manufactured since late 2014 are 64-bit, so choose one that was made since then, but always check by Googling the device info. It would be very unusual for a 64-bit device with Android 5 or greater to have a 32-bit version of Android.

Further to my last reply: I've wrapped up the functionality into my Device Lens tool in version 1.1.0 beta. If you use Slack and join my Slack team at this link: https://slack.delphiworlds.com/ (If you have not already joined), go to the #DeviceLens room where I've uploaded a zip of the executable, as well as a couple of notes on how to retrieve the application label.

It means you have another app on the device that is using the same package name, that was signed using a different key (usually using a different version of Delphi). If you're unsure as to which one it is, one way to check is to use adb, which is in the platform-tools folder under the Android SDK root, so change directory into there, and run this: adb shell pm list packages -f <yourpackagename> e.g: adb shell pm list packages -f com.embarcadero.Location Example output: package:/data/app/com.embarcadero.Location-7NS38JcbdfTgvZ3_WPSj-w==/base.apk=com.embarcadero.Location The part after "package:" and before "=<packagename>" is the path to the APK. Pull the package to the PC, e.g: adb pull /data/app/com.embarcadero.Location-7NS38JcbdfTgvZ3_WPSj-w==/base.apk C:\Temp Then use aapt (in the build-tools\<version> folder under the SDK root, where <version> is whatever version you're using) to discover the application label, e.g: aapt dump badging C:\Temp\base.apk | grep application-label Example output: application-label:'Location'

On deployment, the <%provider%> tag is either replaced with provider information for secure file sharing, e.g: <provider android:name="android.support.v4.content.FileProvider" android:authorities="com.embarcadero.Test.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/provider_paths" /> </provider> or it is simply removed. If you're expecting the former, please ensure that you have Secure File Sharing checked in the Entitlements section of Project Options for the configuration you are building for (i.e. Debug and/or Release)

Pretty sure Delphi can at least deploy to iOS 13.2 devices using Xcode 11.2 beta. I know for sure that Delphi 10.3.2 cannot debug for iOS 13.2 devices, though.

There's no "easy" way to cater for older versions, whether it's iOS, macOS or Android. The best you can do is check the API documentation for which version the methods were introduced (or removed) and use TOSVersion.Check to determine whether the code is relevant and can be called, and branch to another part of the code if you need to cater for lower versions. There's a bunch of examples of TOSVersion.Check being used in the FMX code, so you could refer to them.

1. This should at least have you started: uses Androidapi.JNI.Java.Net, Androidapi.JNI.JavaTypes, Androidapi.Helpers, Androidapi.JNIBridge; function BytesToHex(const ABytes: TBytes): string; var I: Integer; begin Result := ''; for I := Low(ABytes) to High(ABytes) do Result := Result + IntToHex(ABytes[I], 2); end; procedure GetMacAddresses(const AAddresses: TStrings); var LInterfaces, LAddresses: JEnumeration; LInterface: JNetworkInterface; LJavaBytes: TJavaArray<Byte>; LBytes: TBytes; LByte: Byte; I: Integer; LAddress: JInetAddress; LName, LHostAddress: string; begin AAddresses.Clear; LInterfaces := TJNetworkInterface.JavaClass.getNetworkInterfaces; while LInterfaces.hasMoreElements do begin LInterface := TJNetworkInterface.Wrap(JObjectToID(LInterfaces.nextElement)); LJavaBytes := LInterface.getHardwareAddress; if LJavaBytes <> nil then begin SetLength(LBytes, LJavaBytes.Length); for I := 0 to LJavaBytes.Length - 1 do LBytes[I] := LJavaBytes.Items[I]; AAddresses.Add(BytesToHex(LBytes)); end; end; end; 2. Check the code (and warning) for GetUniqueDeviceID, here: https://github.com/DelphiWorlds/KastriFree/blob/master/Core/DW.OSDevice.Android.pas Apparently things have changed a little since Android 8: https://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID

If you're using Bluetooth for tethering, it's more than likely due to needing to request permissions for location at runtime, as Bluetooth discovery requires one of them: https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions There's an example of how to do this in this demo: https://github.com/Embarcadero/RADStudio10.3Demos/tree/master/Object Pascal/Multi-Device Samples/Device Sensors and Services/Bluetooth/BLEScanner

Check the file AndroidManifest.xml in the folder: C:\Users\(username)\AppData\Roaming\Embarcadero\BDS\20.0 Where (username) is your logged in Windows username. This is the file that the IDE uses for AndroidManifest.template.xml. Part of the file should look like this: <%provider%> <%application-meta-data%> <%uses-libraries%> <%services%>

It's a Delphi problem: https://quality.embarcadero.com/browse/RSP-26388

Known issue. If you imported an iOS 12.x SDK from an earlier version of Xcode, target that for now.

Following exactly the same steps, from scratch?

Changed to: Bob Is A Developer Works OK. If it helps, my setup is: Delphi 10.3.2 iOS 12.4 SDK iPhone X running iOS 13.2 Xcode 11.1