Rollo62

Yes, probably thats true and we would end here. Just to think a little out-of-the-box, towards possible Delphi future implementations: What would happen if Delphi would add a {$STRICT_CHAR ON/OFF} directive, which should not be too difficult IMHO ? Could that help to solve such issues between char/string, by simply defining this when needed in the unit with the overload ? I'm afraid not so easy, because the ambiguity happens in the caller, not necessarily in the overload unit itself. So the caller unit has to use this "strict_char" around such critical parts, similar like other directives do. Anyway, if that is good or bad or creates much other problems I cannot tell from my guts, but at least its maybe something weird to think about 🙂 Ok, for me the question is answered already here, since seems no new elegant workaround available now. Thanks for your thoughts and feedback.

Thanks, Peter. Thats what I assumed too, but is there any deeper explanation how overload resolution of Char and String really works, and how this could be solved ? Maybe even the general resolution between Char and String. I understand that a String can be made of one Char 'a', which may be resolved as Char or String, which leads to ambiguities. Is there any clever trick to make this type references clear, and maybe even workable in overloads ? - I can use casts ( but that won't work for overlaod either ) - I could define and cast to my own types, like MyChar and MyString ( which is also not very elegant ) - Maybe constants like #13, #10, #0 have more "char-type-ness" than their string '' conterparts, but in practice that doesn't help much. Pascal has had the reputation of being the most type-safe language for quite some time, but just that char/string ambiguity has always left a bad taste, at least for me. I always wondered if these types cannot be made more "type-safe" nicely somehow.

Maybe this showcase is interesting too, and this more modern site.

The version I have installed is jdk-8.0.242.08-hotspot, which is the one that come together with the RadStudio iinstaller. I've never tried to update to a newer version than the one bundeld and approved with the IDE, maybe it makes sense to check with this older version.

Hi there, I'm considering to dive a little into the Python universe, and ask myself which one is the best approach to get started. Currently I use the package manager Chocolatey under Windows, not for Python yet, but it should be able to install Python and Anaconda as well. I would like to bundle and use Python, Python4Delphi from a Delphi application as controller, best of all nicely integrated in one setup, to produce a commercial application. Since inclusion into one binary setup is very likely problematic, this can be also a separate download of installers, which best of all can be running silently. I like the environment of Python, but I would like to keep customers away from all the nerdy internals, as much as possible. I have a few main questions to all of this What is the best installer (distribution ) to be packed ( or separately downloaded ) together with a complete commercial application What is the best installer to meet all the licenses, containing Python, their Packages and repositories ( I think Anaconda is the only repository, but I'm unsure ). Can Python itself be used (bundled or separate installed) within a commercial applications ? The License itself seems a kind of specific .Python license The licenses of the separate packages need to be checked individually, that is not my point here at the moment. I would like to find what is the best way to bundle Python, Python4Delphi with a Delphi application. In general I understand the differences like that: Chocolatey Is able to install Python and Anaconda too, but this is maybe only an additional layer which is not necessary What I understood is that the Conda universe can completely replace Chocolatey and more, is that correct ?. Is it worth to replace Chocolatey by Anaconda, also for other projects, like the Node.js, PHP universes ? Does it make sense to keep them side-by-side, so that they play out their synergies ? Conda Is the pure package manager application, whereas Anaconda and Miniconda are distributions including already Python and some packages. Seems to be related to Anaconda universe only Anaconda: Best if you are new to conda or Python ( really ? ) Has the onvenience of having Python and over 1500 scientific packages automatically installed at once Have enough time and disk space (a few minutes and 3 GB) If you don’t want to install each of the packages you want to use individually. Is a full distribution of the central software in the PyData ecosystem, and includes Python itself along with the binaries for several hundred third-party open-source projects. It seems Anaconda is bloated Licensing is maybe problematic, if I consider a properitary application later on ( would need an Enterprise account and pricing ) Miniconda: If you do not mind installing each of the packages you want to use individually ( that should be a one-liner each, installing all their dependencies too ). Try to optimize install time or disk space, by installing only the necessary libraries at once If you want to get fast access to Python and the conda commands, and wish to sort out the other programs later. Its essentially an installer for an empty conda environment, containing only Conda, its dependencies, and Python. It seems Microconda is lean and clean, thats what I prefer Licensing is somewhat unclear, it seems that Microconda is free to be integrated in applications ( maybe installing a few packages only depends on their licenses alone ? ) PIP: PyPi: This is the package manger for Python itself, I'm not sure to what that repository is related to ( is it only PyPi ? ). It seems to have a separate repo, is that right ? Does Anaconda and PIP share some repositories and packages ? If so, which one are more actual ? Maybe the Python experts in this forum have more insight into the Python setup, usable for complete applications. I hope to find some answers here how to utilize all above at its best, otherwise the whole Python thing stays maybe a personal playground only.

Looks very nice and relaxing. Have you heard about the Skia contest ? It should be still ongoing, not sure if they take games as "UI" too.

All that can happen, but its also true that the whole pip, npm, composer, chocolatey universes and also the applications and websites build on that rely on such same repositories. These should be billions I would guess. This would break as well for many other applications, no matter if bundled or not, or if hosted on AWS. I was never aware of any bigger problems with that repos, of course security issues always appear here and there on a daily bases, but in general well maintained packages, reviewed by many people, should have relative low risk. That said also Workpress, Joomla, whatever face the same risks, even every Website, not only a very specific desktop application. I would assume if someone compromizes for example ImageMagick, then the whole web will be down, not caring much about such small desktop app. The last case I can think of was OpenSSL or log4j, which had that ability to put the web down, it can basically catch anyone anytime always. We're all using some external stuff here and there, even Delphi itself was compromized before, so I would not think that risk with repos would not be manageable. But thanks to remind me on that risk question, so it might be a good idea to integrate some additional "security" features inside, for example to be able to cut off the apps fastly from a central server by a blacklist server maybe, if some problems with packages are known.

Maybe the difference I'm looking for is the ability also to integrate non-python packages, like this example, this is why I'm looking after Anaconda vs. Chocolatey for example. Yes, its a test balloon and new consideration for me too, to find out that whole thing makes sense. I'm not thinking of a huge application, but about a small app that can do a few little things very good, like a swiss knife. There are so many very good, well maintained open libraries out there, why not make use of them and even push their publication a little ? I know quite a few free or not-free "utility" products that rely on other open-source packages, only for making them more user-friendly. To download from 3rd Party I see not as problen at all, best example is Delphi itself: - Installer downloads Ms Dot-Net installer - Delphi uses Android SDK packages ( I have to confirm license sepatately ) and so on. I think this is nothing new or "smelly" with that approach, at least from my point of view. We only have to take care about the license questions, maybe switch from open to licensed packages in some cases. For that reasons I'm looking after platforms that supports most packages in a most convenient way.

I'm not sure how Win10 Notification behaves, but what happens if you try to decouple this from the incomin ComPort thread ? procedure TForm62.comportclient1Receive(Sender: TObject; InQue: Integer); begin SendMessage(handle, pm_ProcessBarcodeScan, WPARAM(0), LPARAM(0)); //<= Better avoid any ProcessMessages application.processmessages; end; procedure TForm62.ProcessBarcodeScan(var Message: TMessage); begin inherited; SendWin10Notification('Hello World', 'Sent by Message'); end; procedure TForm62.SendWin10Notification(aTitle, aAlertBody: string); begin TThread.ForceQueue( //<= This ensure the call inside main thread, and should avoid to use a Timer IMHO nil, procedure var lNotification : TNotification; begin lNotification := NotificationCenter.CreateNotification; // Processed in Main UI thread here lNotification.Name := format('Windows10Notification%d', [GetTickcount]); lNotification.Title := aTitle; lNotification.AlertBody := aAlertBody; lotificationCenter1.PresentNotification( lNotification ) //insendmessage <== This doesn't help, if you call this several times. // Where is FNotification be created, probably only once at start ? // I think you could have to create a local FNotification here, if you don't have the need to touch this variable again. end ); end; //<= This is probably not necessary at all procedure TForm62.Timer1Timer(Sender: TObject);

Yes, but it seems not all Packages are available in the standard distribution or the connected PyPi repository. Thats why I looked into Anaconda repository, which seems to be well maintained. If I distribute Python together in an compiled setup, then I would like to have a minimal installation and all required packages were loaded after install from the main exe. A GUI protects the user from any interfearance with the Python backend. If you meant that the "normal" Python distribution is free to add in commercials too, and is able to bootstrap itself from PyPi or Anaconda, then this might be a good alternative too. As far as I have seen, the Python license would allow that, I think you're right. Some Python-nauts recommend to use Miniconda for that bootstrap purpose, which would also be by favorite so far. Thats why I ask what the best setup for this task would be, I'm a 5% Python newbie so far 🙂 Only have used a few scripts for testing. Not quite, I want to prepare pre-build apps with e.g. InnoSetup, similar as usual, convenient Windows Apps, where the simple user shall be totally shielded against any underlying command-line operations or other "difficult" tasks, like re-loading extra packages, etc. Everything should be packed in a nice GUI, with a few buttons to operate, while that hard work is done by some special Python packages underneath. The GUI should only prepare all packages accordingly and run the prepared scripts.

As said, its not FMX related, but gives you a lot of info about memory usage, performance, power consumprtion, hardware, network status etc. It has several tools that can be configured in a custom way. Instruments is a kind of separate tool in XCode, so not much problems to use it, it can connect to running or start new processes.

Profiling is a bit tricky, I think there is no real integrated version for FMX yet. But you could try to use the Macos XCode Instrument tools, they show a lot of details for any running apps, but I havent used them any more in the last few years. I think it should be more powerful and useful even. https://gist.github.com/loderunner/36724cc9ee8db66db305

I'm not sure what exactly you are looking for, especially for FMX. A Macos "performance monitor", like a rudimentary "Windows Task-Manager", is called ACtivity Monitor under Macos. This has nothing special for FMX of course.

Ok, here is something to play around with natural spline interpolation vs. other kinds. https://tools.timodenk.com/cubic-spline-interpolation Maybe that has enough gamification factor to fulfil the high expectations here.

So you need to fit all datapoints, but want to avoid large overshootings, then this paper is maybe also interesting for you. https://towardsdatascience.com/numerical-interpolation-natural-cubic-spline-52c1157b98ac

Android: There are quite old infos from Brian Long, maybe too much has changed meanwhile. http://www.blong.com/articles/delphixe7nfc/nfc.htm Android iOS: Maybe WinSoft ? https://winsoft.sk/infclib.htm https://blogs.embarcadero.com/powerful-core-nfc-api-library-for-delphi-firemonkey-on-ios-by-winsoft/ And maybe you find something in Dave's great Kastri Library too https://github.com/DelphiWorlds/Kastri/blob/master/Demos/NFC/MainFrm.pas

Sorry, its probably too late. I had read it as: ... I dont have any issues IOS - Developer/Deployment certificate with Provisioning profile.

Done. But the personal questions had gone way beyond of good taste, IMHO.

For iOS distribution you MUST have a developer account, a provision certificate, etc. etc. etc., the whole Apple "Security by bureaucracy" flash ... https://docwiki.embarcadero.com/RADStudio/Sydney/en/IOS_Mobile_Application_Development I'm afraid there is no way around it.

Haven't checked the sources: I would assume that the SubscribeToMessage() is called twice, with using the same event handler. That should not be allowed, from the EListError error above. So you could try to move this line to a position where it is only called once per lifetime of the app, during initialization ( in TScreenOrientationMonitor.Create for example, if that exists in the source ).

Maybe adding 'android.permission.BLUETOOTH_ADMIN'; makes any difference for you. Not sure how Pairing and Bonding differ in detail, and can be used under Delphi. Do you have any simple example code of what you want to achieve in Java (Android) / Objective-C (iOS) ? Maybe its possible to add and implement that in Delphi too In the code above you don't do anything "bonding special", I would say. https://medium.com/@martijn.van.welie/making-android-ble-work-part-4-72a0b85cb442 https://www.kynetics.com/docs/2018/BLE_Pairing_and_bonding/

Hi there, I'm playing around with the platform behaviours, and I found some strange behaviour when adding them to both 32-Bit and 64.Bit. (1) 32-Bit node: While it is possible to add the library to 32-Bit, ... <== dw-kastri-base-2.0.0.jar was added (2) 64-Bit node: it seems impossible to add the same library to the 64-Bit node: ... <== dw-kastri-base-2.0.0.jar cannot be added Although it seems pretty much possible to add different libraries under the same name ( see work-runtime-2.1.0.dex.jar or others of the default libraries ). In case (2) under 64-Bit I don't get any error or message or something, it simply didn't appear in the list above. It seems to work when I add under 32-Bit only, also under 64-Bit (at least I don't see any errors here), but it doesn't work when I add it under 64-Bit node only. Then it seems not be available in the 32-Bit node. It seems to compile, run and work anyhow, see enclosed demo, but I'm unsure if this by lucky accident ony. Maybe you have some idea what could be going wrong here ?. T457_TestAndLib_001.zip Running under Delphi D11.1 Patch 1

Yes, sorry for that. I am currently chasing some strange behaviours I see on some older Android systems maybe connected with Android-32 CPU. Thats why I just try to look into all possible corners to find a reason, but I have no clear reproducable error right now.

For what platform ? From my setup here: Under Android64, debugging is broken in more complex projects, already since >= 10.4 or so, simply starts veeery slow, shows blackscreen and stops. Under Android32, debugging is still fine and fluid. But I haven't seen such D33566 yet. My recommendationm for any Internal error is, to completely clean all compiled, temporary stuff, and build the project new. That resolved the internal errors in 99.9% in my cases, which leads to my opinion that internal errors are causes mostly by mainy failing processes, leaving DCU or other files in a ghost state.

@Dave Nottage Thanks, that's interesting. Unfortunately it doesn't give me a clue howto workaround these issues really in a reliable way ( currently I'm not dealing with service, but wanted to know howto handle the .jar in the right way ). I considered a "brute-force" copy and paste the same library into the 32/64 Bit structures, but I had to realize that this is only one structure under a general entry "<ItemGroup>", which has no platform specific versions. <ItemGroup> <DelphiCompile Include="$(MainSource)"> <MainSource>MainSource</MainSource> </DelphiCompile> <DCCReference Include="Unit1.pas"> <Form>Form1</Form> <FormType>fmx</FormType> </DCCReference> <JavaReference Include="..\..\..\Kastri\Src\Lib\dw-kastri-base-2.0.0.jar"> <Disabled/> </JavaReference> <BuildConfiguration Include="Base"> <Key>Base</Key> </BuildConfiguration> <BuildConfiguration Include="Debug"> <Key>Cfg_1</Key> <CfgParent>Base</CfgParent> </BuildConfiguration> <BuildConfiguration Include="Release"> <Key>Cfg_2</Key> <CfgParent>Base</CfgParent> </BuildConfiguration> </ItemGroup> That would explain why there is a "There can only be one" behaviour for the .jars. I slightly assume it doen't really matter if the library is in the 32- or 64-Bit tree, as long as it is there it will be taken for both. Howto ensure that it is taken for both, is there a secret Delphi switch ? Strange is that there were are separate library trees for the standard libraries, for 32- and 64-Bits, just as it should be: <PropertyGroup Condition="'$(Base_Android)'!=''"> //<== 32-Bit <DCC_UsePackage>fmx;DbxCommonDriver;bindengine;IndyIPCommon;emsclient;FireDACCommonDriver;IndyProtocols;Skia.Package.RTL;IndyIPClient;dbxcds;FmxTeeUI;bindcompfmx;ibmonitor;FireDACSqliteDriver;DbxClientDriver;soapmidas;fmxFireDAC;dbexpress;inet;DataSnapCommon;dbrtl;FireDACDBXDriver;Skia.Package.FMX;CustomIPTransport;DBXInterBaseDriver;IndySystem;ibxbindings;bindcomp;FireDACCommon;IndyCore;RESTBackendComponents;bindcompdbx;rtl;RESTComponents;DBXSqliteDriver;IndyIPServer;dsnapxml;DataSnapClient;DataSnapProviderClient;DataSnapFireDAC;emsclientfiredac;FireDAC;FireDACDSDriver;xmlrtl;tethering;ibxpress;dsnap;CloudService;FMXTee;DataSnapNativeClient;soaprtl;soapserver;FireDACIBDriver;$(DCC_UsePackage)</DCC_UsePackage> <VerInfo_Keys>package=com.embarcadero.$(MSBuildProjectName);label=$(MSBuildProjectName);versionCode=1;versionName=1.0.0;persistent=False;restoreAnyVersion=False;installLocation=auto;largeHeap=False;theme=TitleBar;hardwareAccelerated=true;apiKey=</VerInfo_Keys> <BT_BuildType>Debug</BT_BuildType> <VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo> <Android_LauncherIcon36>$(BDS)\bin\Artwork\Android\FM_LauncherIcon_36x36.png</Android_LauncherIcon36> ... <Android_NotificationIcon96>$(BDS)\bin\Artwork\Android\FM_NotificationIcon_96x96.png</Android_NotificationIcon96> //<== 32-Bit Jars <EnabledSysJars>annotation-1.2.0.dex.jar;asynclayoutinflater-1.0.0.dex.jar;billing-4.0.0.dex.jar;browser-1.0.0.dex.jar;cloud-messaging.dex.jar;collection-1.0.0.dex.jar;coordinatorlayout-1.0.0.dex.jar;core-1.5.0-rc02.dex.jar;core-common-2.0.1.dex.jar;core-runtime-2.0.1.dex.jar;cursoradapter-1.0.0.dex.jar;customview-1.0.0.dex.jar;documentfile-1.0.0.dex.jar;drawerlayout-1.0.0.dex.jar;firebase-annotations-16.0.0.dex.jar;firebase-common-20.0.0.dex.jar;firebase-components-17.0.0.dex.jar;firebase-datatransport-18.0.0.dex.jar;firebase-encoders-17.0.0.dex.jar;firebase-encoders-json-18.0.0.dex.jar;firebase-iid-interop-17.1.0.dex.jar;firebase-installations-17.0.0.dex.jar;firebase-installations-interop-17.0.0.dex.jar;firebase-measurement-connector-19.0.0.dex.jar;firebase-messaging-22.0.0.dex.jar;fmx.dex.jar;fragment-1.0.0.dex.jar;google-play-licensing.dex.jar;interpolator-1.0.0.dex.jar;javax.inject-1.dex.jar;legacy-support-core-ui-1.0.0.dex.jar;legacy-support-core-utils-1.0.0.dex.jar;lifecycle-common-2.0.0.dex.jar;lifecycle-livedata-2.0.0.dex.jar;lifecycle-livedata-core-2.0.0.dex.jar;lifecycle-runtime-2.0.0.dex.jar;lifecycle-service-2.0.0.dex.jar;lifecycle-viewmodel-2.0.0.dex.jar;listenablefuture-1.0.dex.jar;loader-1.0.0.dex.jar;localbroadcastmanager-1.0.0.dex.jar;play-services-ads-20.1.0.dex.jar;play-services-ads-base-20.1.0.dex.jar;play-services-ads-identifier-17.0.0.dex.jar;play-services-ads-lite-20.1.0.dex.jar;play-services-base-17.5.0.dex.jar;play-services-basement-17.6.0.dex.jar;play-services-cloud-messaging-16.0.0.dex.jar;play-services-drive-17.0.0.dex.jar;play-services-games-21.0.0.dex.jar;play-services-location-18.0.0.dex.jar;play-services-maps-17.0.1.dex.jar;play-services-measurement-base-18.0.0.dex.jar;play-services-measurement-sdk-api-18.0.0.dex.jar;play-services-places-placereport-17.0.0.dex.jar;play-services-stats-17.0.0.dex.jar;play-services-tasks-17.2.0.dex.jar;print-1.0.0.dex.jar;room-common-2.1.0.dex.jar;room-runtime-2.1.0.dex.jar;slidingpanelayout-1.0.0.dex.jar;sqlite-2.0.1.dex.jar;sqlite-framework-2.0.1.dex.jar;swiperefreshlayout-1.0.0.dex.jar;transport-api-3.0.0.dex.jar;transport-backend-cct-3.0.0.dex.jar;transport-runtime-3.0.0.dex.jar;user-messaging-platform-1.0.0.dex.jar;versionedparcelable-1.1.1.dex.jar;viewpager-1.0.0.dex.jar;work-runtime-2.1.0.dex.jar</EnabledSysJars> </PropertyGroup> <PropertyGroup Condition="'$(Base_Android64)'!=''"> //<== 64-Bit <DCC_UsePackage>fmx;DbxCommonDriver;bindengine;IndyIPCommon;emsclient;FireDACCommonDriver;IndyProtocols;Skia.Package.RTL;IndyIPClient;dbxcds;PkS4_Core_Rx1111;FmxTeeUI;bindcompfmx;hclcore_xe11;ibmonitor;FireDACSqliteDriver;DbxClientDriver;soapmidas;fmxFireDAC;dbexpress;inet;DataSnapCommon;htmleditcore_xe11;htmledit_xe11;dbrtl;FireDACDBXDriver;htmlcomp_xe11;Skia.Package.FMX;CustomIPTransport;DBXInterBaseDriver;IndySystem;ibxbindings;bindcomp;FireDACCommon;IndyCore;RESTBackendComponents;bindcompdbx;rtl;RESTComponents;DBXSqliteDriver;IndyIPServer;dsnapxml;DataSnapClient;DataSnapProviderClient;DataSnapFireDAC;emsclientfiredac;FireDAC;FireDACDSDriver;xmlrtl;tethering;ibxpress;dsnap;CloudService;FMXTee;DataSnapNativeClient;soaprtl;soapserver;FireDACIBDriver;$(DCC_UsePackage)</DCC_UsePackage> <VerInfo_Keys>package=com.embarcadero.$(MSBuildProjectName);label=$(MSBuildProjectName);versionCode=1;versionName=1.0.0;persistent=False;restoreAnyVersion=False;installLocation=auto;largeHeap=False;theme=TitleBar;hardwareAccelerated=true;apiKey=</VerInfo_Keys> <BT_BuildType>Debug</BT_BuildType> <VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo> <Android_LauncherIcon36>$(BDS)\bin\Artwork\Android\FM_LauncherIcon_36x36.png</Android_LauncherIcon36> ... <Android_NotificationIcon96>$(BDS)\bin\Artwork\Android\FM_NotificationIcon_96x96.png</Android_NotificationIcon96> //<== 64-Bit Jars <EnabledSysJars>annotation-1.2.0.dex.jar;asynclayoutinflater-1.0.0.dex.jar;billing-4.0.0.dex.jar;browser-1.0.0.dex.jar;cloud-messaging.dex.jar;collection-1.0.0.dex.jar;coordinatorlayout-1.0.0.dex.jar;core-1.5.0-rc02.dex.jar;core-common-2.0.1.dex.jar;core-runtime-2.0.1.dex.jar;cursoradapter-1.0.0.dex.jar;customview-1.0.0.dex.jar;documentfile-1.0.0.dex.jar;drawerlayout-1.0.0.dex.jar;firebase-annotations-16.0.0.dex.jar;firebase-common-20.0.0.dex.jar;firebase-components-17.0.0.dex.jar;firebase-datatransport-18.0.0.dex.jar;firebase-encoders-17.0.0.dex.jar;firebase-encoders-json-18.0.0.dex.jar;firebase-iid-interop-17.1.0.dex.jar;firebase-installations-17.0.0.dex.jar;firebase-installations-interop-17.0.0.dex.jar;firebase-measurement-connector-19.0.0.dex.jar;firebase-messaging-22.0.0.dex.jar;fmx.dex.jar;fragment-1.0.0.dex.jar;google-play-licensing.dex.jar;interpolator-1.0.0.dex.jar;javax.inject-1.dex.jar;legacy-support-core-ui-1.0.0.dex.jar;legacy-support-core-utils-1.0.0.dex.jar;lifecycle-common-2.0.0.dex.jar;lifecycle-livedata-2.0.0.dex.jar;lifecycle-livedata-core-2.0.0.dex.jar;lifecycle-runtime-2.0.0.dex.jar;lifecycle-service-2.0.0.dex.jar;lifecycle-viewmodel-2.0.0.dex.jar;listenablefuture-1.0.dex.jar;loader-1.0.0.dex.jar;localbroadcastmanager-1.0.0.dex.jar;play-services-ads-20.1.0.dex.jar;play-services-ads-base-20.1.0.dex.jar;play-services-ads-identifier-17.0.0.dex.jar;play-services-ads-lite-20.1.0.dex.jar;play-services-base-17.5.0.dex.jar;play-services-basement-17.6.0.dex.jar;play-services-cloud-messaging-16.0.0.dex.jar;play-services-drive-17.0.0.dex.jar;play-services-games-21.0.0.dex.jar;play-services-location-18.0.0.dex.jar;play-services-maps-17.0.1.dex.jar;play-services-measurement-base-18.0.0.dex.jar;play-services-measurement-sdk-api-18.0.0.dex.jar;play-services-places-placereport-17.0.0.dex.jar;play-services-stats-17.0.0.dex.jar;play-services-tasks-17.2.0.dex.jar;print-1.0.0.dex.jar;room-common-2.1.0.dex.jar;room-runtime-2.1.0.dex.jar;slidingpanelayout-1.0.0.dex.jar;sqlite-2.0.1.dex.jar;sqlite-framework-2.0.1.dex.jar;swiperefreshlayout-1.0.0.dex.jar;transport-api-3.0.0.dex.jar;transport-backend-cct-3.0.0.dex.jar;transport-runtime-3.0.0.dex.jar;user-messaging-platform-1.0.0.dex.jar;versionedparcelable-1.1.1.dex.jar;viewpager-1.0.0.dex.jar;work-runtime-2.1.0.dex.jar</EnabledSysJars> </PropertyGroup> Just looking at the "annotation-1.2.0.dex.jar" entry, there were two places where it is included. While for the external libraries, see above, Delphi allows only one place for all architectures, strange. Still I'm unsure if this one will be enough for compilation of Android-32 and -64, how could I check if a library is binded into the package ? I can find the reference, I assume, inside the classes.dex, but not sure if it always gets there . Will there be any useful error message, if the reference would be missing, either in 32- or 64-Bit or both ? This error hopefully pops by linker failures. When I would ever need to handle separate 32- and 64-Bit Jars, I'm afraid there is no option in Delphi to do that right now, maybe by adding a wrapper JAR only, handling that externally.