Please don't use armeabi anymore, Google stopped supporting it years ago.

Weex only supports armeabi-v7a, arm64-v8a and x86 and we don't test Weex on armeabi anymore. If there is a confusion about what Weex ABI supports and what don't, you could give us a PR to make the documentation better.

Because we are the service provider, Party A wants armeabi. Now I am replacing v7a with armeabi
,Do you have any suggestions? ths

Maybe you could help us improve the document. I saw some pepole complained the error you met, and a document improvement may solve the problems for future users of Weex.

I know how code is written and running, but that may limits me writing good document from users' perspecteive.

First of all, I have to solve this problem in order to supplement the documentation to help people who have encountered such problems. Now, I don't know how to solve them. Can you give me some advice?

Have you tried armeabi-v7a?

The current NDK 18 Weex using doesn't support armeabi, and I can't make Google to support armeabi in the furture release of NDK.

All right, I am testing with armeabi-v7a now. I have to replace armeabi with armeabi-v7a, which may be difficult to advance.

I can compile armeabi using your source code, but the new jsc does not provide armeabi so, [https://registry.npmjs.org/jsc-android/-/jsc-android-241213.1.0.tgz], so you know Where can I find armeabi libjsc.so?

I still have a question. Is there any difference between the android-jsc file provided by jsc-android and the android-jsc-intl file? Why is their libjsc.so volume difference? I am using android-jsc libjsc.so to replace android-jsc-intl libjsc.so will have problems? I thought that one of them was a normal version and the other was an international version.

• android-jsc-intl contains ICU, which support various languages, like Russian, Greek, or other language you may heard.
• android-jsc doesn't have that kinds of language support. You can test it for youself, whether the language you need is supported.

For armeabi of jsc-android, there is nothing I can do. I think as Google stopped supporting armeabi, libraries in Android wil not provide it either, as time goes.

If you see this and have students who have the same problem. This may be the only way to switch to armeabi-v7a. If any of the students have a good solution, share it, thank you.

E/AwareLog: AtomicFileUtils: readFileLines file not exist: android.util.AtomicFile@46e6539
E/weex: tryUseRunTimeApi ? false
E/WXParams: setCrashFilePath: /data/user/0/com.fund.weex.fundandroidweex/app_crash
E/weex: weexjss's Path is/data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm/libweexjss.so
E/weex: jsc's Path is/data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm/libjsc.so
E/weex: findLibJscRealPath /data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm/libjsc.so
E/weex: enableAlarmSignal:true
E/weex: getUseSingleProcess is running false
E/WeexCore: params_utils.cpp:197,g_use_single_process is false
E/weex: getLibJscPath is running /data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm
E/WeexCore: params_utils.cpp:232,g_jscSoPath is /data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm
E/weex: getLibJssPath is running /data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm/libweexjss.so
E/WeexCore: params_utils.cpp:245,g_jssSoPath is /data/app/com.fund.weex.fundandroidweex-Lmd-9iQybVplTgLxkyw2oA==/lib/arm/libweexjss.so
E/WXParams: getCrashFilePath:/data/user/0/com.fund.weex.fundandroidweex/app_crash
E/WeexCore: params_utils.cpp:257,g_crashFilePath is /data/user/0/com.fund.weex.fundandroidweex/app_crash
E/weex: getLibIcuPath is running /system/usr/icu/icudt60l.dat
E/MemoryLeakMonitorManager: MemoryLeakMonitor.jar is not exist!
E/WeexCore: params_utils.cpp:270,g_jssIcuPath is /system/usr/icu/icudt60l.dat
E/weex: getLibJsbPath is running /data/data/com.fund.weex.fundandroidweex/cache/weex/libs/weexjsb/armeabi-v7a/libweexjsb.so
E/WeexCore: setDebugMode 2
E/libc: Access denied finding property "net.dns1"
E/WeexCore: multi_process_and_so_initializer.cpp:38,MultiProcessAndSoInitializer IS IN init
E/WeexCore: weex_js_connection.cpp:140,WeexJSConnection g_crashFileName: /data/user/0/com.fund.weex.fundandroidweex/app_crash/crash_dump.log
E/[HOTFIX]: [ThreadDexHotfixMonitor]Bind hotfix monitor service fail!
E/fundandroidwee: Invalid ID 0x00000000.
E/weex: idle from create instance cache size is 0
E/weex: onRenderError -1001,degradeToH5|createInstance fail|wx_create_instance_error isJSFrameworkInit==false reInitCount == 1
E/WeexCore: weex_js_connection.cpp:288,WeexJSConnection catch: spinWaitPeer timeout
E/WeexCore: weex_js_connection.cpp:183,IPCException server died spinWaitPeer timeout
E/WeexCore: multi_process_and_so_initializer.cpp:47,JSFramwork init start sender is null
E/WeexCore: weex_js_connection.cpp:140,WeexJSConnection g_crashFileName: /data/user/0/com.fund.weex.fundandroidweex/app_crash/crash_dump.lo
E/WeexCore: weex_js_connection.cpp:252,startupPie :1
E/weex: initFrameWorkCount :1
E/weex: PerformanceData
E/memtrack: Couldn't load memtrack module
E/memtrack: Couldn't load memtrack module
E/weex: PerformanceData
E/memtrack: Couldn't load memtrack module
E/memtrack: Couldn't load memtrack module

I changed to armeabi-v7a, but still reported the same error, you should check it out.

It worked fine in Playground, could please provide more infromation.

It seems to me there is a crash and the crash file is printed in the logcat. Maybe you could share the crash file.

size ==0 the log is empty!

This looks like weexSdkInstance failed to initialize. Is this problem difficult to locate?

Just output this information

I compared the versions of 26 and 28. Why did the instance initialization on the 28 version comment this line of code?

I let go of this line of code and it didn't work.
if you have time please checkout。ths

in WxBridgeManager initFramework() method:

I found the problem, the framework initialization is sometimes very slow, my test found that sometimes it takes 40 seconds to initialize. It seems that you have not tested well with the new jsc.

I found the problem, the framework initialization is sometimes very slow, my test found that sometimes it takes 40 seconds to initialize. It seems that you have not tested well with the new jsc.

It tooks 40 seconds to execute nativeInitFrameworkEnv ?

That never happened in my phone, or CI environment. Does it happen in a certain phone, or any phone you have? Could you please provide more detail, like the OS version, phone name, etc.?

I have reproduced on many mobile phones, Huawei p20, xiaomi MIX2, Samsung s8 plus, Huawei p30... The phones I have on hand have been reproduced. The probability of recurring on MIX2 is relatively large.

Is this call to the jsc api or the weexCore api?

Please don't use armeabi anymore, Google stopped supporting it years ago.

Weex only supports armeabi-v7a, arm64-v8a and x86 and we don't test Weex on armeabi anymore. If there is a confusion about what Weex ABI supports and what don't, you could give us a PR to make the documentation better.

I have the same problem. Is this starting from Weex v0.20 ?

Please don't use armeabi anymore, Google stopped supporting it years ago.
Weex only supports armeabi-v7a, arm64-v8a and x86 and we don't test Weex on armeabi anymore. If there is a confusion about what Weex ABI supports and what don't, you could give us a PR to make the documentation better.

I have the same problem. Is this starting from Weex v0.20 ?

I met after 0.28.0, replacing the new jsCore from 0.28.0 weex sdk.

Is this call to the jsc api or the weexCore api?

It will invoke a C++ API in WeexCore, and you can view all the C++/Java binding in this file.

FYI: Have you tried the Weex Playground, which also uses the new JSC. I think there may be a configuration problem in your app with the new JSC. Is there a libjsc.so file in your App? If not, you should configure it right.

If the suggestion I gave above is helpful, please upgrade the current documentation so that we could help more users.

确实是libjsc.so的问题，可以对比一下 playground 的libjsc.so位置

If the suggestion I gave above is helpful, please upgrade the current documentation so that we could help more users.

As you can see, the framework init takes about 40 seconds.

@bobSir Does Weex Playground have the same problem on your phone?

I'm in the same corp. with bobSir, and I found something strange. In multi_process_and_so_initializer.cpp with function Init， the code has jumped into the case
if (sender == nullptr) and throws the Exception IPCException server died spinWaitPeer timeout
and WeexJSConnection catch: spinWaitPeer timeout。

Expecting to give some advice to us. Thanks any way.

Maybe you should have a look at #3030

I solved this problem temporarily, and I found that some time-consuming operations in my application may block the initialization of jsFrameWork. My current approach is to listen for the time-consuming operations after the jsFrameWork initialization is complete.
But the same operation before 0.28.0, the initialization of jsFrameWork is normal. Maybe what weex can do?
If a classmate encounters the same problem as me, you can refer to my approach.

But the same operation before 0.28.0, the initialization of jsFrameWork is normal. Maybe what weex can do?

If you suspect this is the problem of the new JSC, you can build Weex from source together with the legacy JSC. For detail of the build comand, you can look at the travis command line

Anyway, I will just close it. Feel free to contact me if there are any other problems.