Rio 10.3.3 Update

-
RAD Studio 10.3.3 update is live.

Just like previous 10.3.2 update got big feature in macOS 64bit platform, 10.3.3 brings long awaited Android 64bit platform support.



Adding 64bit Android platform is pretty straightforward.

You need to add 64bit SDK - make sure it uses the same base paths as 32bit SDK, open your project and 64bit Android will be automatically added to the platform list.

You need to make sure that all deployed resources for 32bit platform are also included for 64bit platform and you are ready to go.

If you want to test application on the device, you have to make sure that your device actually has 64bit Android OS. Even some newer low end devices still use 32bit OS despite the fact they do have 64bit CPUs. If you are about to purchase new device, double check OS bitness.

If your device does not have 64bit OS and you run 64bit Delphi application on it, it will show message "64-bit OS device required".

Unfortunately, 64bit Android debugger has some issues with particular devices and it refuses to run. If you are owner of such device, you can still debug in 32bit mode. Not ideal, but in most cases it will not matter much for the Android side. Most likely debugger fixes will be issued as hot fix rather than update and hopefully before next 10.4 release.

You can build 32bit and 64bit Android APKs separately, and for Google Play Store deployment using App Bundle is the best option. Android App Bundle is similar to iOS universal binary. It packs both 32bit and 64bit variants and Play Store will repack and deliver only one of those variants for every particular device depending on whether it runs 32bit or 64bit Android OS.

In this release, all mobile platforms still run under ARC compiler. This will ease migration to 64bit Android since basically all you need to do is recompile your application.

Unifying memory management and removing mobile ARC compilers is still scheduled for next major release 10.4.

You can find full list with all new features and other information at http://docwiki.embarcadero.com/RADStudio/Rio/en/10.3_Rio_-_Release_3

Comments

Post a Comment

Popular posts from this blog

Coming in Delphi 12: Disabled Floating-Point Exceptions

-
Delphi 12 is in the works. One of its small features that will have a huge impact is a change in the default handling of floating-point exceptions, which will now be masked on all platforms. Previously, floating-point exception handling was different across platforms, and most notably on the Windows platform: In VCL and console applications, floating-point exceptions were not masked and would raise an exception. On the other hand, FireMonkey applications had all floating-exceptions masked by default, regardless of which platform they were running on. Basically if you haven't explicitly changed the exception mask in your code to some value other than the default, and you had code that attempted to divide some number with zero, you would get an EZeroDivide exception in previous Delphi versions on the Windows VCL application. In Delphi 12, there is no exception, and the result of such a division will be +INF . So the following code will no longer raise an exception. If you were r
Read more

Beware of loops and tasks

-
Loops and anonymous methods don't go hand in hand. Any variable that changes for each iteration will cause problems if it is used within an anonymous method. I explained the mechanism behind variable capturing in the post Mysterious Case Of Wrong Value , along with the problem it causes with loops and its solution. Commonly, anonymous methods are used as callbacks or event handlers, where there are no loops in the context where variable capture happens. While there is a possibility to have an unexpected—wrong—value in such scenarios, it is rather easy to debug them and understand the order in which some code is called, and why the captured value is wrong in a given place. With the rise of multi-threading usage, and especially the Parallel Programming Library and tasks, writing anonymous methods inside a loop becomes more common, and it is much easier to write code where a captured variable will have the wrong value. The biggest problem with such code is that it will be harder to
Read more

Catch Me If You Can - Part II

-
It has been quite some time since I wrote the Catch Me If You Can post about the inability of LLVM-backed compilers to catch non-call hardware exceptions. In other words, hardware exceptions raised by code written in the same block as the try...except exception handler. Since then, more LLVM-backed compilers have been added to Delphi, and with those, more reasons to change common coding practices... but still, very few developers know about the issue. The original article covered only try...except exception handlers, and exploring what exactly happens with implicit and explicit try...finally handlers was left as an exercise to the readers and to some future, now long overdue, post. And Now: All Hell Breaks Loose When you read about non-call hardware exceptions not being caught by an immediate try...except block, the implications might not look too serious. After all, while plenty of code can raise exceptions, try...except handlers are not that frequently used in places, as mo
Read more