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>
Related
I am building LineageOS 18.1 for tecno kd7. I have system, system_ext, product & vendor paritions. The rom port I built is having a boot loop.
Here is the last_kmsg
What is causing the boot loop?
I am suspecting these lines
[ 1.802608] (0)[354:apexd]apexd: This device does not support updatable APEX. Exiting
[ 2.352523] (0)[1:init]reboot: Restarting system with command 'boringssl-self-check-failed'
I just need direction on what I need to what is causing the phone to bootloop
I also faced the same issue. The boringssl-self-test binary is using incorrect libcrypto.so library.
You can run the boringssl-self-test with strace and check for the issue.
In file : external/boringssl/selftest/boringssl_self_test.rc
service boringssl_self_test64_vendor /system/bin/strace -tt /vendor/bin/boringssl_self_test64
setenv BORINGSSL_SELF_TEST_CREATE_FLAG true # Any nonempty value counts as true
#reboot_on_failure reboot,boringssl-self-check-failed
stdio_to_kmsg
seclabel u:r:vendor_boringssl_self_test:s0
AOSP (android 8.0.0-r3) for Pixel XL, Im trying to stop Android from loading nfc_nci.marlin.so by
removed nfc_nci.marlin from device-marlin.mk
removed the source from system/nfc/halimpl/pn54x
After rebuild and flash to phone, I still notice from logcat :
sphal namespace is not configured for this process. Loading
/vendor/lib64/hw/nfc_nci.marlin.so from the current namespace instead.
Since I did not build nfc_nci.marlin.so, I did a search and found a hit in vendor/google_devices/marlin/proprietary/vendor.img. How can I stop the AOSP from loading this share library from vendor image??
Don't know if you have the same device tree as me, but you have to remove nfc_nci.marlin.so from PRODUCT_COPY_FILES in vendor/google/devices/marlin/marlin-vendor-blobs.mk, then manually from out(..)/vendor/lib(,64)/hw/ and rebuild the AOSP
I'm using Android Studio to debug a NativeActivity app written in C++
In my C++ code the first thing I do in android_main() is wait 10 seconds for the debugger to attach. In the 'Debug' window I see:
Now Launching Native Debug Session
and then after a few seconds
Debugger attached to process 28458
and then right after it attaches, the debugger is stopped with a signal:
Signal: 33 (signal SIG33)
I press 'Resume Program' and then I get the same signal again and again for 7-8 times. After that, the program continues as expected, debugger attached and I am able to stop it at breakpoints.
What's the meaning of that SIG33? how can I prevent it?
Signal 33 is used internally by bionic for the backtrace facilities.
See comment in __libc_current_sigrtmin.cpp.
// POSIX timers use __SIGRTMIN + 0.
// libbacktrace uses __SIGRTMIN + 1.
// libcore uses __SIGRTMIN + 2.
See definition of __SIGRTMIN for generic, arm, x86, and mips.
#define __SIGRTMIN 32
I think that SIG33 is caused by gdb and gdb is not correctly ignoring it.
Those can be ignored and/or silenced using below GDB command-line:
handle SIG33 nostop noprint
SIG33 is used to signal about "threading libraries" by LLDB.
Excerpt from LLDB source:
AddSignal (33, "SIG33", false, false, false, "threading library internal signal 2");
But I don't seem to understand the reason why your code is getting this. May be due to some minor dependency issues.
I have just created an API 23 emulator on my machine:
HAXM: v1.4 with 1GB allocated RAM
AVD Base: Nexus 4
RAM: 768MB, and 896MB in a second try
Heap: 64 MB
GPU acceleration: no
I tried it successfully with a few apps of my own. But each time I try an application that uses a WebView as a UI, the app crashes that way:
The three first line of this logcat are the only pertaining to my app (highlighted in blue). All other lines do not mention my application package's name in the 'Application' column of LogCat, but one does in the middle of the message (circled in blue).
I can load the HTML code into the WebView. The crash occurs at setContentView(theWebView) time:
public class MyActivity extends Activity {
private WebView mWebview = null;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mWebview = new WebView(this);
mWebview.loadDataWithBaseURL("file:///android_asset/", HTML_CODE, "text/html", "UTF-8", null);
setContentView(mWebview); // THIS IS WHERE THE CRASH OCCURS
}
[...]
Using or not using runOnUiThread() to run mWebview.loadDataWithBaseURL() produces exactly the same result, which is expected as onCreate() is actually on the UI thread.
The html code I am using does not change anything. In the case above, the HTML_CODE variable contains this:
<html>
<head></head>
<body>
<h1>Hello</h1>
<p>Hello world!</p>
</body>
</html>
The app runs perfectly, even with a more advanced HTML+CSS+JS+JS<->Java binding code on all the API 17 and 19 devices and emulators I tried. This is where I'm puzzled. I didn't have a chance to try with an actual Android 6.0 (API 23) device though.
EDIT
I have just :
migrated from Eclipse to Android Studio
upgraded HAXM to v1.5
upgraded my SDK Tools (24.4.1) and my platform (23.0.1)
The problem still occurs but the log is different, and a bit clearer. There is a ClassNotFoundException I cannot explain:
10-28 20:26:05.102 2168-2168/com.example.myapp W/System: ClassLoader referenced unknown path: /data/app/com.example.myapp-1/lib/x86
10-28 20:26:08.583 2168-2168/com.example.myapp E/DataReductionProxySettingListener: No DRP key due to exception:java.lang.ClassNotFoundException: com.android.webview.chromium.Drp
10-28 20:26:09.393 2168-2213/com.example.myapp W/chromium: [WARNING:data_reduction_proxy_config.cc(423)] SPDY proxy OFF at startup
10-28 20:26:12.521 2168-2286/com.example.myapp A/chromium: [FATAL:gl_surface_android.cc(58)] Check failed: kGLImplementationNone != GetGLImplementation() (0 vs. 0)
10-28 20:26:12.521 2168-2286/com.example.myapp A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 2286 (GpuThread)
Any idea? (I'm investigating further so I will update this post should I find anything relevant)
This behaviour was not caused by any erroneous setting of the AVD or any missing prerequisite (harware, etc...).
As cryptojuice mentioned in comments this was caused by an OpenGL ES prerequisite issue on emulator side:
#8 ...#chromium.org
Unfortunately OpenGL ES 2.0 support has been mandatory for devices
since at least Android 4.0, so we haven't ever explicitly supported
GLES 1.x at all and it was only working before by accident :/
It seems a bit problematic that the emulator (without host GPU
emulation) doesn't meet the minimum requirements for Android devices.
We might be able to work around this for the emulator at a significant
performance cost; we're talking to the emulator team about what the
best thing to do here is.
Now this is fixed (SDK tools 25.1 RC1 / platform 23 rev 3), even though this doesn't appear on the ticket linked above.
I am working on a app, where I will use android NDK & JNI.
Whenever I run my app on any android 4.0 or higher version... my app will crash and gives the following error...
A/libc(18556): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
D/libEGL(18606): loaded /system/lib/egl/libGLES_android.so
D/libEGL(18606): loaded /system/lib/egl/libEGL_adreno200.so
D/libEGL(18606): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
D/libEGL(18606): loaded /system/lib/egl/libGLESv2_adreno200.so
I/Adreno200-EGLSUB(18606): <ConfigWindowMatch:2078>: Format RGBA_8888.
D/OpenGLRenderer(18606): Enabling debug mode 0
Main problem is Fatal signal 11 (SIGSEGV) at 0xdeadbaad(code=1)
If anyone know about this... then tell me the reason.
initially, the segmentation fault and, specially the 0xdeadbaad, would mean a memory corruption or similar but, I recently found that, with the NDK, this is also the default behaviour for assertions: on assert fail it sends SIGSEGV, instead of SIGTRAP, and sets the memory pointer to this hex string.
You should check that your code is calling to assert or, in case you're using third party's software, check that you're passing the proper values to every call. A quick way to check this would be building your library with NDEBUG set to 1 (by default if you set APP_OPTIM := release in your Application.mk) and check if you still have exactly the same problem.
Hope this helps.