Using:
realm 2.22.0
react-native 0.58.5
Attempting to run on Android (6.0) 64-bit Huawei P9 lite
Building with Android Studio
Application crashes immediately with error:
E/SoLoader: Error when loading lib: dlopen failed: "/data/data/com.netballninja/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib .....
Running the application on 32-bit Android simulator is fine.
I have analyzed the APK file and indeed under /libs/arm64-v8a the librealmreact.so does not exist (only under armeabi-v7a). 64-bit support appears to have been back ported into react-native 0.58.4 (originally slated for 0.59).
I have tried removing the inclusion of arm64-v8a support from the APK, (thinking that Android OS would drop back to 32-bit if no 64-bit libs were present) and the application does then run in 32-bit mode on the 64-bit device.
I assume that I do require a librealmreact.so that is 64-bit (precompiled). How do I ensure that my bundling includes that?
you must add this line to app/build.gradle
android {
....
defaultConfig {
....
ndk {
abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
}
}
}
This is a known bug of SoLoader.
Fixed in v0.8.0 by this.
As you said, the real reason which causes app crashed is that:
the application does then run in 32-bit mode on the 64-bit device.
SoLoader will follow certain of rules to extract some .so files from .apk file when the application runs first time. In 64-bit device, if the .apk file includes 64-bit .so files, soloader will extract them instead of 32-bit files.
Therefore, you can try to fix this problem by following the steps below:
Make sure that build.gradle of module like this:
...
android {
...
splits {
abi {
include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
}
}
defaultConfig {
ndk {
abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
}
}
}
If step1 can not fix your problem, try to upgrade SoLoader to version 0.8.0:
configurations.all {
resolutionStrategy {
force "com.facebook.soloader:soloader:0.8.0"
}
}
Related
I'm working on a MSI installer for our java app using Jpackage.
Versions:
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)
OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode, sharing
jpackage 17.0.1
OS Name: Microsoft Windows Server 2019 Datacenter
OS Version: 10.0.17763 N/A Build 17763
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
Jpackage Usage:
jpackage --input ./home ^
--name "Acme Application" ^
--main-jar app.jar ^
--main-class org.springframework.boot.loader.JarLauncher ^
--java-options "-splash:$APPDIR/splash.png" ^
--java-options -Xmx2g ^
--icon resources/package.ico ^
--win-shortcut ^
--win-menu ^
--type msi ^
--app-version %1
Upgrade Process
The installation works fine and everything runs well. The upgrade process also works fine under normal circumstances. When the user tries to run the new MSI package while the application is still running, the MSI installer prompts the user to close the application before continuing:
Selecting to close the application and continue causes the application to close on the users desktop but the installer then prompts the user again with the same dialog. Selecting the same option (close and continue), allows the installer to complete but the user is then warned that they need to restart.
Upon restarting, it appears that application version 1.0.0 is still running. Checking the jar file signature before and after shows that installer failed to overwrite the original.
Event Viewer
Checking the event viewer, I'm only seeing a few things of interest:
Windows Installer requires a system restart. Product Name: *******. Product Version: 1.0.1. Product Language: 1033. Manufacturer: Unknown. Type of System Restart: 1. Reason for Restart: 0.
and
The Windows Installer initiated a system restart to complete or continue the configuration of '*******'.
Failing to Stop the Application
I also noticed that the application is not completely stopping. Looking at the task manager, it shows the application running under the user and then moves to background processes. This leads me to believe that it's still locking the jar file. The application stops normally under other circumstances so I'm not sure what's different here.
I'm assuming that I need to solve this mystery but I have no idea why the application wouldn't respond to the installer's close signal while working with everything else.
Alright, I've done some digging and this is related to JavaFX's lifecycle. Simply overriding the Application.stop method is not enough to properly shutdown on these types of close requests.
Two changes to my application fixed the issue:
Register a EventHandler on the primary stage onCloseRequest
Here I initialize my spring application as well as register the event handler to stop the application:
#Override
public void start(Stage stage) {
applicationContext.publishEvent(new StageReadyEvent(stage));
stage.setOnCloseRequest(event -> stop());
}
Ensure you have a call to System.exit in your EventHandler
Platform.exit is not enough to close the application under these circumstances:
#Override
public void stop() {
log.info("Shutting down application...");
applicationContext.close();
Platform.exit();
log.info("Shutdown complete");
// System.exit is required or the app will move to a background process on uninstall/upgrade
// events from Windows MSI installer
System.exit(0);
}
Environment: Windows 10, WinForm (.Net 4.7.2) x64 only, CefSharp 71.0.2.0
We need support for playing MP4 in our product (we have a license) and we are attempting to recompile CEF with proprietary codecs enabled.
We're using the instructions from:
https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart.md#markdown-header-windows-setup
Our create.bat file looks like:
set CEF_USE_GN=1
set GN_DEFINES=is_win_fastlink=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
call cef_create_projects.bat
Our update.bat file looks like
set CEF_USE_GN=1
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=C:\code\chromium_git --depot-tools-dir=C:\code\depot_tools --no-distrib --no-build --branch=3578
We are trying to specifically target build 3578 to match the build that comes with CEFSharp. We also enabled proprietary codec using the flag: proprietary_codecs=true
After about 2 hours and no errors the build completes successfully. When we run our page using cefclient.exe from the output build everything works as expected, the video plays correctly.
We copy the following files from the output build folder to our .Net application replacing the files packaged with CEFSharp:
cef.pak
cef_100_percent.pak
cef_200_percent.pak
cef_extensions.pak
chrome_elf.dll
d3dcompiler_47.dll
devtools_resources.pak
icudtl.dat
libcef.dll
libEGL.dll
libGLESv2.dll
natives_blob.bin
snapshot_blob.bin
v8_context_snapshot.bin
\locales\*.*
\swiftshader\libEGL.dll
\swiftshader\libGLESv2.dll
When running our app, the app terminates immediately and this is written to the debug.log file:
[0326/094610.429:FATAL:cookie_manager_impl.cc(620)] Check failed: false. context not valid
Backtrace:
cef_string_utf16_to_upper [0x00007FFD2B53E1E5+1713061]
cef_string_utf16_to_upper [0x00007FFD2B53D44D+1709581]
cef_string_utf16_to_upper [0x00007FFD2B5765D5+1943445]
cef_zip_reader_create [0x00007FFD2B3107B8+159661640]
cef_cookie_manager_get_global_manager [0x00007FFD219B0436+54]
CefCookieManager::GetGlobalManager [0x00007FFD7322879E+94]
(No symbol) [0x00007FFD4E1C07DE]
[0326/094721.035:FATAL:cookie_manager_impl.cc(620)] Check failed: false. context not valid
I was able to see that 71.0.2.0 uses CEF 3.3578.1870.gc974488 / Chromium 71.0.3578.98 from:
https://github.com/cefsharp/CefSharp/commit/7d24861e7af79fc4721eb498bb8417b5aa6cad97
When we run cefclient.exe from our build and navigate to chrome://about it displays:
CEF 3.3578.1870.gc974488
Chromium 71.0.3578.98
Which matches the CEFSharp release notes page.
Any suggestions would be greatly appreciated!
I'm seeing the following output from my .NET Core App 1.0 on Ubuntu after adding a dependency for my PCL that targets netstandard1.3:
foo: /opt/code/src/corehost/cli/fxr/fx_muxer.cpp:316: static pal::string_t fx_muxer_t::resolve_fx_dir(host_mode_t, const pal::string_t &, const runtime_config_t &, const pal::string_t &): Assertion `mode != host_mode_t::standalone' failed.
Aborted (core dumped)
That line of code is:
// No FX resolution for standalone apps.
assert(mode != host_mode_t::standalone);
This didn't happen to me before, so I'm unsure where to start looking. How is this host_mode_t resolved on startup?
It seems to me the problem is that some dependency resolution is happening that doesn't need to, because of a mistake in a configuration file?
Thanks in advance.
EDIT:
This is the full output of the app upon startup once I set COREHOST_TRACE=1:
Tracing enabled
--- Invoked dotnet [version: 1.1.0, commit hash: 0bc55b1fcc0bd58987bf96683c15596918db2b13] main = { ./foo --staging }
Resolved fxr [/var/www/html/foo/staging/libhostfxr.so]...
Tracing enabled
--- Invoked hostfxr [commit hash: 928f77c4bc3f49d892459992fb6e1d5542cb5e86] main Own DLL
ath=[/var/www/html/foo/staging/foo.dll]
Checking if CoreCLR path exists=[/var/www/html/foo/staging/libcoreclr.so]
Detecting mode...
CoreCLR present in own dir [/var/www/html/foo/staging] and checking if [foo.deps.json] file present=[1]
--- Executing in standalone mode...
Treating application '/var/www/html/foo/staging/foo.dll' as a managed executable.
App runtimeconfig.json from [/var/www/html/foo/staging/foo.dll]
Runtime config is cfg=/var/www/html/foo/staging/foo.runtimeconfig.json
dev=/var/www/html/foo/staging/foo.runtimeconfig.dev.json
Attempting to ead runtime config: /var/www/html/foo/staging/foo.runtimeconfig.json
Attempting to read dev runtime config: /var/www/html/foo/staging/foo.runtimeconfig.dev.json
Runtime config[/var/www/html/foo/staging/foo.runtimeconfig.json] is valid=[1]
foo: /opt/code/src/corehost/cli/fxr/fx_muxer.cpp:316: static pal::string_t fx_muxer_t::resolve_fx_dir(host_mode_t, const pal::string_t &, const runtime_config_t &, const pal::string_t &): Assertion `mode != host_mode_t::standalone' failed. Aborted (core dumped)
This issue was twofold:
I was using rsync to publish the app to my server, but I wasn't deleting files no longer in use, so the dependency configuration files were still present;
I had, at some point, added "platform" as the "type" for "Microsoft.NETCore.App" in my dependencies for the "netcoreapp1.0" target. This was causing a DLL to be generated instead of a standalone executable.
Here is my gradle file
apply plugin: 'com.android.application'
apply plugin: 'me.tatarka.retrolambda'
android {
compileSdkVersion 23
buildToolsVersion "23.0.2"
defaultConfig {
applicationId "com.demo.sample"
minSdkVersion 15
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.2.0'
compile 'com.android.support:design:23.2.0'
//Retrofit
compile 'com.squareup.retrofit2:retrofit:2.0.0-beta4'
//Retrofit support libraries
compile 'com.squareup.retrofit2:converter-gson:2.0.0-beta4'
//compile 'com.squareup.retrofit2:converter-simplexml:2.0.0-beta4'
compile 'com.squareup.retrofit2:adapter-rxjava:2.0.0-beta4'
compile 'com.squareup.okhttp3:logging-interceptor:3.0.1'
//RxAndroid
compile 'io.reactivex:rxandroid:1.1.0'
//Explicit support for latest RxJava
compile 'io.reactivex:rxjava:1.1.0'
//Square dagger
provided 'com.squareup.dagger:dagger-compiler:1.2.2'
compile 'com.squareup.dagger:dagger:1.2.2'
//Butterknife
compile 'com.jakewharton:butterknife:6.1.0'
//Picasso
compile 'com.squareup.picasso:picasso:2.3.3'
//Testing dependency
testCompile 'junit:junit:4.12'
testCompile 'org.assertj:assertj-core:2.1.0'
testCompile 'org.mockito:mockito-core:2.0.23-beta'
}
If i un-comment line compile 'com.squareup.retrofit2:converter-simplexml:2.0.0-beta4' android studio throws nasty error at compile time
:app:transformClassesWithDexForDebug
trouble processing "javax/xml/XMLConstants.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
1 error; aborting
Error:Execution failed for task ':app:transformClassesWithDexForDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
I'm not understanding what the error actually means. Also, is there a way to get around this problem.
Seem like Simple XML has transitive dependencies which are already included in Android. See https://github.com/square/retrofit/issues/1536.
We need to exclude three dependencies: stax:stax-api, stax:stax, and xpp3:xpp3.
I managed to achieve this by using this compile statement in gradle
compile ('com.squareup.retrofit2:converter-simplexml:2.0.0-beta4'){
exclude module: 'stax-api'
exclude module: 'stax'
exclude module: 'xpp3'
}
this is another error am getting
FAILURE: Build failed with an exception.
What went wrong:
ANDROID_HOME not specified. Either set it as a gradle property, a system environment variable or directly in your build.gradle by setting the extension jfxmobile.android.androidSdk.
Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
i think, you have to add your android path on your build.gradle . Here is my setting for the android part:
jfxmobile {
android {
// signingConfig {
// storeFile file("")
// storePassword ''
// keyAlias ''
// keyPassword ''
// }
applicationPackage = 'my.package.app.name'
manifest = 'src/android/AndroidManifest.xml'
resDirectory = 'src/android/res'
androidSdk ="$System.env.HOME/android-sdks" // this is bassicly path to your android sdk
}
}
Try it.
Regards,
Ivan
Since you haven't defined the OS you are using, I'll go ahead and include both.
Ubuntu (or any other Linux distro I think):
Add the following to your ~/.bashrc file.
First
nano ~/.bashrc
Then add the following in the last line
export ANDROID_HOME= "Enter you sdk path"
This path will end with a /Android/sdk/
For eg. mine is /home/Android/sdk/
Log out and log in again and presto, magic!
If bashrc does not seem to work. Use profile instead ie ~/.profile
Remember to log out to allow changes to occur on startup.
Windows:
We can't define names to exported paths in Windows(as far as I know) so we need to include it in the build.gradle
jfxmobile {
android {
compileSdkVersion = '15'
buildToolsVersion = '22.0.1'
androidSdk = 'C:/Users/your username/AppData/Local/Android/sdk'
}
ios {
infoPList = file('src/ios/Default-Info.plist')
}
}
And hey, there's the magic again!
If you installed Android somewhere else, point it to the correct direction.
Use the gluon plugin for Netbeans. Its the best way I found for working with javafxports. It takes all headaches from customizing basic things out of the way.
Why set it globally in Ubuntu and not in the build.gradle file?
Declaring it globally is an approach which means you don't have to repeat the same process again in a new project.