Hans♫

We just released an update to our Android app, which is now built with Delphi 12.3 (and API level 35). Unfortunately it looks like it wont run on most Chromebooks with ChromeOS (it works fine on Android). The previous version built with Delphi 12.2 did work on ChromeOS. We can reproduce it on our own Chromebook and have exported a log from this device (see attached). One line in the log attracts my attention: 09-08 14:16:27.109 10076 2581 2581 W NativeActivity: NativeActivity LoadNativeLibrary("/data/app/~~E-VhoBM1TL6eFtEyKe6GJw==/com.MYAPP.android-_-VEr2wdpUe0s69SzjhivA==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libMYAPPFMX.so") failed: dlopen failed: library "libz.so" needed or dlopened by "/data/app/~~E-VhoBM1TL6eFtEyKe6GJw==/com.MYAPP.android-_-VEr2wdpUe0s69SzjhivA==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libMYAPPFMX.so" is not accessible for the namespace "(default)" Any ideas? - Did Delphi 12.3 change the way it links "libz.so" on Android? arc-bugreport_MYAPP.txt

Thank you Dave. I see that in "System.ZLib.pas" it defines all functions like this, which did not change from Delphi 12.2 to 12.3: libzlib = '/usr/lib/libz.so'; function compress(dest: PByte; var destLen: LongWord; source: PByte; sourceLen: LongWord): Integer; cdecl; external {$IFDEF POSIX} libzlib name _PU + 'compress'{$ENDIF}; Since its the same Chromebook that does work with a Delphi 12.2 build, the version of libz.so did not change either, so I think that the note you added from Google could not be the problem. The strange thing is that everything works fine on real Android devices. Its only ChromeOS running Android apps that has this problem. Something must have changed with Delphi 12.3 that cause this error. The API level did change to 35 with the new Delphi version, and probably a lot of internal tweaks to load the binary built with Delphi? - and maybe also the way it internally loads dynamic libraries?

Having various components on a TListbox, scrolling does not work when i touch a component that has HitTest=True. What is the best way to solve this? I have comboboxes, radiobuttons, checkboxes, etc on Listboxitems to create a dynamic interface. So far I have only used native components on iOS (TMS iCL) where scrolling vs control interaction, is handled automatically by the OS in a very smooth way. Now we are preparing an Android version based on our FMX view, but on FMX it does not seem to work out of the box. If HitTest is true for a component, then scrolling does not work, and if HitTest is false for a component, then it does not respond, but scrolling works. I found this nice solution made by David Nottage, but it requires to create a descending class of each component used: https://stackoverflow.com/questions/57452568/prevent-firing-events-while-scrolling-tvertscrollbox

If you plan to buy a mac (mini), please note: the simulator only works on ARM processors. All new macs use ARM now, but if you buy an old one, be sure to avoid Intel. The first Mac Mini with M1 (arm) processor was released in 2020.

It also depends on your need to access the hardware on the computer. If you need to access microphone, camera, harddrive, audio, USB devices, etc. you have much better control with an installed app. It is the case with both desktop and mobile devices. That's the reason we release our app on Windows, MacOS, Android and iOS.

Ha, ha, I am sure you know what I mean 😉 I'm no expert in the compilers memory management and optimization. I was trying to explain why it made no difference to add [ref]. I guess that if you create a "packed" record that is smaller than a pointer then it will be passed by value.

Thats because there is no difference. As the text says, with "const" only, the compiler decides the most efficient way. For a record the most efficient way is to pass its reference, so adding [ref] makes no difference.

I think the answer is in this text from the FreeAndNil article linked above: ... [ref], which forces the compiler to pass a const parameter as a reference. Without it, the compiler can optimize passing of const parameter depending on the size of the parameter.

Ok, thats great. So let me elaborate: When you have found out what native functions are used in Objective-C to get the wanted result, then you can search the source code of Delphi for those functions. This will tell you exactly what function to call in Delphi to access the feature. Its of course nice to be able to get help here in DelphiPraxis, but its even better if you know how to find the solution on your own - and its much faster 🙂

To increase the chances for a positive response, I would recommend to first check if its possible at all with XCode and Objective-C. If it's possible there then its usually also possible in Delphi, and then you can begin figuring out how its done and eventually ask about it here.

Our Android App is rejected by Play Store because it exceeds the 150 MB limit. It is not an option to make it smaller as it includes a large 170 MB file with audio samples, which is required by our app. The way to handle large app is to use the "Play Feature Delivery" option: https://developer.android.com/guide/playcore/feature-delivery However, the instructions to use the "Feature Delivery" is highly tied up on having a project in Android Studio. We could probably do it by setting up a dummy app in Android Studio, but I guess it will take some time without any knowledge about Android Studio. Anyone having found a way to deploy a large Delphi app to Play Store?

Thank you so much 👍 We have successfully incorporated your new solution in our project (we use our own build script). It has also been tested on Play Store and that works too!

It might be a simple task for some, but at least not for me 🙂 First step of the switch is to create a Delphi interface to the new jar, and next step is to make the code work with that interface and jar. With the current solution we used the interface to play-core-1.10.0.jar, that you created and supplied in your Kastri example project. I made a quick attempt to do the same myself for asset-delivery-2.2.2.jar, using Java2OP.exe and the instructions supplied by Embarcadero - but unsuccessful. I believe this is just the first problem, out of many, to complete this switch of jar's. Probably because I have no idea what I am doing... So I won't list the error messages here to start a problem solving session. I think it is more beneficial for the Delphi community if its solved by a competent person and shared with the community - and I'll be pleased to pay for the work, even if its shared.

With the new API 34, it looks like the solution we made for install time assets, based on the Kastri example, no longer works. When installing the resulting .aab on a device (Google Pixel8) running Android 14 it throws an security exception and the Install Time asset isn't loaded: java.long.SecurityException: com.<applicationname>.android: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts As far as I see, the problem is the play-core-1.10.0.jar (February 2021) is no longer accepted. And we need to migrate to the new Play libraries (since April 2022) https://developer.android.com/reference/com/google/android/play/core/release-notes Specifically the Play Asset Delivery Library - Latest update 2.2.2 (May 2024) https://developer.android.com/reference/com/google/android/play/core/release-notes-asset_delivery Anyone having experienced the same?

Having Skia on MacOS is a great improvement because it allows us to enable Metal without losing rendering quality. However, on Windows we experience slow rendering with Skia. We use Delphi 12.1 Patch 1, with our FMX based app. A full screen slide-in animation of a TFrame on top of the main form is smooth with GlobalUseSkia=false. When setting GlobalUseSkia=true, the framerate of the animation goes down to around 2-4 fps. This is with GlobalUseSkiaRasterWhenAvailable=true. Setting GlobalUseSkiaRasterWhenAvailable=false, then the framerate doubles, but then vector graphics is no longer antialiased. We have not changed any components or code in paint routines, but maybe we should? Any idea what goes wrong?

@vfbb Any update on this issue? - Maybe a bug should be filed in the QP?

Yes, I can reproduce this in a blank project. You did not see it because you used gray in gray. When using white on black, then you can see it: <No Skia | Skia + Vulkan > Enlarged: <No Skia | Skia + Vulkan > This is produced with an empty app with only this code: GlobalUseSkia := true; GlobalUseSkiaRasterWhenAvailable := false; GlobalUseVulkan := true; ... procedure TForm1.PaintBox1Paint(Sender: TObject; Canvas: TCanvas); var lStroke: TStrokeBrush; lPath: TPathData; begin lStroke := TStrokeBrush.Create(TBrushKind.Solid, claWhite); lStroke.Thickness := 1.5; lPath := TPathData.Create; lPath.AddEllipse(RectF(-12, -12, 12, 12)); lPath.Translate(50,50); Canvas.Fill.Color := claBlack; Canvas.FillRect(RectF(0,0,100,100), 0, 0, [], 1); Canvas.DrawPath(lPath, 1, lStroke); lStroke.Free; lPath.Free; end;

Its a path. Our code looks like this (simplified): fStroke := TStrokeBrush.Create(TBrushKind.Solid, claSilver); fStroke.Thickness := 1.5; fPath := TPathData.Create; fPath.AddEllipse(RectF(-12, -12, 12, 12)); ... Canvas.DrawPath(fPath, 1, fStroke);

Thank you. We had the Form.Quality set to SystemDefault, which seem to do the same as setting it to HighQuality. I tried to set it to HighQuality, but did not see any difference. However, I just found out that with Skia+Vulkan, it actually draws with anti-aliasing, but in a very simple way. Here is our back button. The version to the left is with no Skia. To the right it is with Skia + Vulkan: <No skia | Skia+Vulkan> I though the Skia+Vulkan version was not anti-aliased, but when enlarging, I can see that it is: The quality of the anti-aliasing is simply lower with Skia+Vulkan (and the forms quality is set to high quality). Is there a way to change that?

Yes, it looks the same both with and without Vulkan: no anti-aliasing.

Enabling Vulkan requires to uncheck SkiaRaster, according to the description. We are seeing a performance improvement and it runs pretty smooth when unchecking the SkiaRaster. If there is an additional performance improvement by enabling Vulkan, it is not clearly visible, so I'll need to measure the frame rate to find. However, unchecking SkiaRaster also disables anti-alias when drawing a path, so it is not currently an option. Maybe that could be solved somehow by accessing the Skia Canvas?

Yes, we have both Intel macs and Apple Silicon macs at the office, but we currently build only for Intel and rely on the Rosetta 2 emulator. Both Intel and Silicon work "fine" when enabling Metal. However, we have not measured the framerate on animations or the painting speed, so here "fine" means that its high enough to not attract attention.

Thank you. Interesting where the bottleneck is? BTW, we are not using the Skia Canvas (ISkCanvas), but as I understand the description, it is only needed to unlock more features, not to increase speed? For now we can simply turn off Skia on Windows, and use it only on MacOS, Android and iOS. But as soon as we begin to implement SKIA specific functionality, it becomes more difficult to maintain, if we have to support non-Skia too.

No, unfortunately a simple app does not have this problem. And as a side-note, thinking about your question: Asking "general" questions like I did is of course a tradeoff: When have I tried enough to ask? I am sure I would be able to solve the problem on my own, but I also know that it could easily take a day, a week or even a month to solve. Sometimes just to find out that the solution was simple, but locating it was complex. Sometimes others have been through the same and discovered something that might not be obvious. I admit that I asked my question early in the process, long before having tried all options. But that was with a hope that someone else have been through this and have some useful information 🙂