Develop Reference

.net MAUI application fails to launch on local arm64-v8a device

I've developed MAUI application. Eveything works perfectly on emulator and I want to try it out on my Xiaomi Redmi note 9. But it fails with:
Loaded assembly: /data/data/com.companyname.mauieventsamplecs/files/.__override__/System.Numerics.Vectors.dll [External]
[monodroid-assembly] open_from_bundles: failed to load assembly lt-LT/System.Private.CoreLib.resources.dll
[chatty] uid=10359(com.companyname.mauieventsamplecs) identical 2 lines
[monodroid-assembly] open_from_bundles: failed to load assembly lt-LT/System.Private.CoreLib.resources.dll
[uieventsamplec] Process terminated due to "Infinite recursion during resource lookup within System.Private.CoreLib. This may be a bug in System.Private.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names. Resource name: IO_FileName_Name"
[libc] Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 1418 (uieventsamplecs), pid 1418 (uieventsamplecs)
I pinpointed that it's the problem of different CPU. By default, the app is building on Any CPU (emulator runs x86_64 system). Which I would hope should include arm64-v8a, but it seems to only include all Intel CPU. Tried launching arm64-v8a emulator, but it's not supported since my device is Intel and not AMD
I tried changeing solution platform to ARM64, but ether that did not help or, you need to something more than just adding new solution platform and assigning it to actually make it work.
So my question is: how one should set up the MAUI to launch on local arm64-v8a if that's even possible.

Turns out it was the problem based on lt-LT/System.Private.CoreLib.resources.dll After few days of debugging and finally switching my phone language from LT to US in my phone settings it fixed the problem.

Try set in MauiApp1.csproj
<PropertyGroup Condition="$(TargetFramework.Contains('-android')) and '$(Configuration)' == 'Release'">
<!--<RuntimeIdentifiers>android-arm;android-arm64;android-x86;android-x64</RuntimeIdentifiers>-->
<RuntimeIdentifiers>android-arm;android-arm64</RuntimeIdentifiers>
</PropertyGroup>

Android Bundle package crash on startup

My Delphi project have both android 32 and 64 destination. I can deploy them on my test devices and they both works fine.
Now google forces me to upload a single app bundle file (.aab), so i flagged the "Generate Android App Bundle file (arm + arm64)" option, set up my provisioning keystore, loaded the alias and then generated that .aab file
I uploaded that as a beta release for my app from the android developer portal and after a few hours it became available to download for my test devices. But.. it shows the start up logo.. and nothing else.
I don't really know how to debug this since both the apks are working fine (32 and 64 bit), so i tried to launch adb logcat *:W, but i still cannot get useful info. I got those lines in endless loop:
10-30 09:59:21.656 13723 13723 E systems.<my app name>: Not starting debugger since process cannot load the jdwp agent.
10-30 09:59:21.688 13723 13723 W systems.<my app name>: JIT profile information will not be recorded: profile file does not exits.
10-30 09:59:21.688 13723 13723 W systems.<my app name>: JIT profile information will not be recorded: profile file does not exits.
10-30 09:59:21.703 922 1100 E ANDR-IOP: IIop:: Iop HAL Service is not available.
10-30 09:59:21.707 13723 13743 E Perf : Fail to get file list oat
10-30 09:59:21.707 13723 13743 E Perf : getFolderSize() : Exception_1 = java.lang.NullPointerException: Attempt to get length of null array
10-30 09:59:21.743 13723 13723 W linker : Warning: "/data/app/<my app name>-43xRWdYLtXcvUAbEkuUk6g==/split_config.arm64_v8a.apk!/lib/arm64-v8a/lib<my app name>.so" unused DT entry: DT_RPATH (type 0xf arg 0x2cf24) (ignoring)
Just for info: getFolderSize() is not a function i use in my code (its not even declared).
Also, i think this is pretty important: my app deploys some .so files (different files for 32 and 64 bit) and some other files, like images and fonts.
Why i think this is important? Just a suspect born reading this similar issue (but with xamarin): https://github.com/xamarin/Xamarin.Forms/issues/11450
I also tried to deploy the .aab manually on my devices but the only thing i found is how to generate the .apks file from the .aab, and i still cannot deploy it on my devices.
I'm using Delphi 10.4.1 and i also tried to recreate the .dproj file setting up everything again.
How i can debug this? Or how i can get more info about the cause?
Edit: Solved it! I had a few problems that, mixed together, caused this; i'll try to list them in case someone will have a similar issue and will end here!
my androidmanifest.template.xml file was generated by an older version of delphi and was missing some important parts
you need to include all the needed .so files in both 32 and 64bit build to actually have them in the bundle
using TPath.GetLibraryPath() when loading .so files can produce different results if you are using it inside a .aab bundle package
i was trying to load one of those .so file from the initialization section using the function TPath.GetLibraryPath() to get the root path, that was causing a unhandled exception that make my app crash into the splash screen
I solved simply removing TPath.GetLibraryPath() from the path i was using to load my .so and now it works

Debugging an Android crash without a stack trace

This app instantiates a WebView on app launch without adding it to the UI tree. This is done for preloading purposes.
When finally adding the WebView to the UI tree later on, the app crashes without a stack trace.
At the time the WebView gets added to the UI tree, logcat shows the following on an emulator running API level 22:
D <last app event before adding preloaded webview to ui tree>
W ResourceType: No known package when getting name for resource number 0xffffffff
E eglCodecCommon: glUtilsParamSize: unknow param 0x000085b5
E eglCodecCommon: glUtilsParamSize: unknow param 0x00008b49
E eglCodecCommon: glUtilsParamSize: unknow param 0x00008b4b
E eglCodecCommon: glUtilsParamSize: unknow param 0x00008b4a
D AndroidRuntime: >>>>>> START com.android.internal.os.RuntimeInit uid 10059 <<<<<<
D AndroidRuntime: CheckJNI is ON
E cutils-trace: Error opening trace file: Permission denied (13)
E memtrack: Couldn't load memtrack module (No such file or directory)
E android.os.Debug: failed to load memtrack module: -2
D AndroidRuntime: Calling main entry org.chromium.components.crash.browser.CrashpadMain
W linker : libwebviewchromium.so: unused DT entry: type 0x6ffffef5 arg 0x4c34
W linker : libwebviewchromium.so: unused DT entry: type 0x6ffffffe arg 0x4bd4
W linker : libwebviewchromium.so: unused DT entry: type 0x6fffffff arg 0x3
E chromium: [0722/152535.383241:ERROR:elf_dynamic_array_reader.h(61)] tag not found
E chromium: [0722/152535.394807:ERROR:file_io_posix.cc(140)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
E chromium: [0722/152535.394897:ERROR:file_io_posix.cc(140)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
E chromium: [0722/152535.401624:ERROR:system_snapshot_linux.cc(125)] Couldn't read property ro.product.board
D AndroidRuntime: Shutting down VM
I WindowState: WIN DEATH: Window{2507ca0c u0 com.myapp.debug}
Does this point to the root cause of the crash?
I'm wondering if they are instead part of a crash recovery/dump mechanism (due to the reference to "CrashpadMain" before the errors), and if I would be able to find a stack trace elsewhere. While I can use adb bugreport, I don't know where to look in the report for information on the crash instance.
Of note, I've only been able to reproduce this crash (though consistently) on emulators, and only running API levels 22, 25, 27 and 29. A physical device, and an emulator running API level 23, do not reproduce it.

From the crash output it looks like the builds you're using have is_official_build=true set? (which makes sense for perf I guess)
This basically prevents Android from generating useful crash dump output at all, because the unwind tables are omitted from the binary. The only way to debug crashes in this kind of binary is to use Crashpad dumps, but those are unlikely to be hooked up usefully in a test environment?
Build with exclude_unwind_tables=false to override the default. This will increase binary size quite a bit, but should result in you getting a meaningful stack backtrace with more than one frame. You should then be able to symbolise the stack trace addresses to find out what's crashing.
exclude_unwind_tables
Current value (from the default) = true
From //build/config/compiler/compiler.gni:103
Exclude unwind tables by default for official builds as unwinding can be
done from stack dumps produced by Crashpad at a later time "offline" in the
crash server. Since this increases binary size, we don't recommend including
them in shipping builds.
For unofficial (e.g. development) builds and non-Chrome branded (e.g. Cronet
which doesn't use Crashpad, crbug.com/479283) builds it's useful to be able
to unwind at runtime.

Running Animation sample app (for Sceneform) on Android Emulator

I am trying to run the Animation sample app on my Android Emulator:
Pixel 2 API 27 Oreo
Android 8.1 x86
but the app keeps crashing.
Below are my logcat warnings: (I only copied the lines in orange)
E/eglCodecCommon: glUtilsParamSize: unknow param 0x00008a30
glUtilsParamSize: unknown param 0x00008a30 E/native:
online_calibration_manager.cc:47 OnlineCalibrationManager: Could not
open
/data/user/0/com.google.ar.sceneform.samples.animation/cache/arcore-online-recalibration
for reading. E/NdkImageReader: AImageReader_getWindow E/native:
session.cc:1397 Invalid ray produced by view data! A/libc: Fatal
signal 11 (SIGSEGV), code 128, fault addr 0x0 in tid 6227
(mples.animation), pid 6227 (mples.animation)
I can run hello_ar_java sample on the emulator, so I guess the configurations of the emulator are correct?

Malloc debug on Android Nougat doesnt work for my Native code

I am trying to find memory leaks and corruptions in my native code, which is part of a sample java app. Since the procedure for using malloc debug has been updated from Nougat onwards (ref: Malloc Debug for Android N), I have followed the steps in that page to set the options of my interest.
Fortunately, I was able to get the mem corruption detection work (by use of guard option) for a simple buffer overflow in my native code. But, whatever option I use, I couldn't get the leaks detected.
I tried these options:
adb shell setprop libc.debug.malloc.options backtrace
adb shell setprop libc.debug.malloc.options leak_track
I also tried a combination of both options. I didnt see any mallocs or leaks present in my code being captured in logcat. In fact, for most devices I see that device is stuck in bootup when 'backtrace' option is set.
However, what I see is in the logs, is apparently false-positives for leaks in lot of other system programs:
12-16 13:05:51.908 8396 8396 E malloc_debug: +++ chmod leaked block of size 152 at 0x7f7de4b0e0 (leak 1 of 19)
...
12-16 13:05:52.156 8423 8423 E malloc_debug: +++ chown leaked block of size 152 at 0x7f8384b0e0 (leak 1 of 26)
...
12-16 13:05:56.533 8845 8845 E malloc_debug: +++ getprop leaked block of size 152 at 0x7fb684b0e0 (leak 1 of 17)
...
12-16 13:07:24.036 12393 12393 E malloc_debug: +++ /system/bin/dex2oat leaked block of size 131072 at 0xeb22c010 (leak 1 of 2452)
...
12-16 13:07:49.192 13734 13734 E malloc_debug: +++ logcat leaked block of size 5176 at 0x7f8dc5f020 (leak 1 of 21)
So, I have two questions in this context:
Does my apk need to be in a specific location for backtrace/leak_track to work? Was it ever tested for apks before, at least on N?
Do I need to set any other option for leak detection to work?
It looks like Malloc debug on Nougat is not explored much, so I didnt see any results on Google for any known issues or restrictions.
More details on my setup:
- Android Nougat 7.0
- 64 bit chipset
- Java sample app, with native code as shared lib