Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android9 Crash Due To androidHardwareAccelerationDisabled #1069

Closed
RmondJone opened this issue Dec 9, 2019 · 34 comments
Closed

Android9 Crash Due To androidHardwareAccelerationDisabled #1069

RmondJone opened this issue Dec 9, 2019 · 34 comments

Comments

@RmondJone
Copy link

Bug description:
Android9使用你们的库,由于硬件加速原因会报如下错误,试过用原生WebView没有这个问题!

2019-12-09 14:17:13.890 27811-27962/com.focustech.xyz A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1c in tid 27962 (RenderThread), pid 27811 (m.focustech.xyz)
2019-12-09 14:17:14.478 28380-28380/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-12-09 14:17:14.478 28380-28380/? A/DEBUG: Build fingerprint: 'Xiaomi/dipper/dipper:9/PKQ1.180729.001/V11.0.3.0.PEACNXM:user/release-keys'
2019-12-09 14:17:14.478 28380-28380/? A/DEBUG: Revision: '0'
2019-12-09 14:17:14.478 28380-28380/? A/DEBUG: ABI: 'arm'
2019-12-09 14:17:14.478 28380-28380/? A/DEBUG: pid: 27811, tid: 27962, name: RenderThread  >>> com.focustech.xyz <<<
2019-12-09 14:17:14.479 28380-28380/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1c
2019-12-09 14:17:14.479 28380-28380/? A/DEBUG: Cause: null pointer dereference
2019-12-09 14:17:14.479 28380-28380/? A/DEBUG:     r0  00000000  r1  c5c44300  r2  e6c91e0d  r3  00000000
2019-12-09 14:17:14.479 28380-28380/? A/DEBUG:     r4  00000000  r5  00000000  r6  adaf2000  r7  00000000
2019-12-09 14:17:14.479 28380-28380/? A/DEBUG:     r8  00000004  r9  00000000  r10 00000000  r11 00000000
2019-12-09 14:17:14.479 28380-28380/? A/DEBUG:     ip  e70f08d0  sp  bf3795f0  lr  e6c148c7  pc  e6f69e78
2019-12-09 14:17:14.525 28380-28380/? A/DEBUG: backtrace:
2019-12-09 14:17:14.525 28380-28380/? A/DEBUG:     #00 pc 003dfe78  /system/lib/libhwui.so (SkSurface::getCanvas()+4)
2019-12-09 14:17:14.525 28380-28380/? A/DEBUG:     #01 pc 0008a8c3  /system/lib/libhwui.so (android::uirenderer::skiapipeline::GLFunctorDrawable::onDraw(SkCanvas*)+1090)
2019-12-09 14:17:14.525 28380-28380/? A/DEBUG:     #02 pc 00344855  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+212)
2019-12-09 14:17:14.525 28380-28380/? A/DEBUG:     #03 pc 00344e5f  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+154)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #04 pc 0032c5ad  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+272)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #05 pc 0032c8c3  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+202)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #06 pc 003447e5  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #07 pc 00344e5f  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+154)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #08 pc 0032c5ad  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+272)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #09 pc 0032c8c3  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+202)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #10 pc 003447e5  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #11 pc 00344e5f  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+154)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #12 pc 0032c5ad  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+272)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #13 pc 0032c8c3  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+202)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #14 pc 003447e5  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #15 pc 00344e5f  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+154)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #16 pc 0032c5ad  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+272)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #17 pc 0032c8c3  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+202)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #18 pc 003447e5  /system/lib/libhwui.so (SkDrawable::draw(SkCanvas*, SkMatrix const*)+100)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #19 pc 00344e5f  /system/lib/libhwui.so (SkLiteDL::draw(SkCanvas*) const+154)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #20 pc 0032c5ad  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::drawContent(SkCanvas*) const+272)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #21 pc 0032c8c3  /system/lib/libhwui.so (android::uirenderer::skiapipeline::RenderNodeDrawable::forceDraw(SkCanvas*)+202)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #22 pc 0009207b  /system/lib/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::renderLayersImpl(android::uirenderer::LayerUpdateQueue const&, bool, bool)+794)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #23 pc 0035fff7  /system/lib/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::renderFrame(android::uirenderer::LayerUpdateQueue const&, SkRect const&, std::__1::vector<android::sp<android::uirenderer::RenderNode>, std::__1::allocator<android::sp<android::uirenderer::RenderNode>>> const&, bool, bool, android::uirenderer::Rect const&, sk_sp<SkSurface>)+38)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #24 pc 0035f6bb  /system/lib/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::draw(android::uirenderer::renderthread::Frame const&, SkRect const&, SkRect const&, android::uirenderer::FrameBuilder::LightGeometry const&, android::uirenderer::LayerUpdateQueue*, android::uirenderer::Rect const&, bool, bool, android::uirenderer::BakedOpRenderer::LightInfo const&, std::__1::vector<android::sp<android::uirenderer::RenderNode>, std::__1::allocator<android::sp<android::uirenderer::RenderNode>>
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #25 pc 0009a7ef  /system/lib/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+150)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #26 pc 00362d9d  /system/lib/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+576)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #27 pc 0032b8ff  /system/lib/libhwui.so (android::uirenderer::WorkQueue::process()+122)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #28 pc 000a32a3  /system/lib/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+178)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #29 pc 0000c113  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+166)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #30 pc 000637f5  /system/lib/libc.so (__pthread_start(void*)+22)
2019-12-09 14:17:14.526 28380-28380/? A/DEBUG:     #31 pc 0001e019  /system/lib/libc.so (__start_thread+24)
2019-12-09 14:17:16.499 28380-28380/? E/crash_dump32: cannot open libmiuindbg.so: No such file or directory
2019-12-09 14:17:16.505 1024-1024/? E//system/bin/tombstoned: Tombstone written to: /data/tombstones/tombstone_02
2019-12-09 14:17:16.737 1491-1777/? E/InputDispatcher: channel '2798de1 com.focustech.xyz/com.focustech.xyz.ui.main.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
2019-12-09 14:17:16.817 2151-2151/? E/Launcher: changeViewByFsGestureState,  view=FitSystemWindowView,  alpha=1.0,  scale=1.0
2019-12-09 14:17:16.817 2151-2151/? E/Launcher: changeViewByFsGestureState,  view=ShortcutMenuLayer,  alpha=1.0,  scale=1.0
2019-12-09 14:17:16.841 1491-1777/? E/InputDispatcher: channel '241d00 com.focustech.xyz (server)' ~ Channel is unrecoverably broken and will be disposed!

Environment:

  • OS:Android
  • OS version:9
  • react-native version:0.61.4
  • react-native-webview version:7.5.1
@siddhantsoni
Copy link

siddhantsoni commented Dec 9, 2019

I am facing the same crash in Android 9 and also 10. This is happening when hardware acceleration is enabled by default. It gets fixed by using androidHardwareAccelerationDisabled prop to disable hardware acceleration.

Disabling hardware acceleration doesn't help me as I am using WebGL APIs in my webpage which requires hardware acceleration to render.

Can someone help resolve this NDK crash?

  • OS: Android
  • OS version: 9, 10
  • react-native version: 0.61.2
  • react-native-webview: 7.5.1

@ItsNoHax
Copy link

ItsNoHax commented Dec 10, 2019

Facing the same crash on Android 10. Will try disabling hardware acceleration now.

Edit: Can confirm disabling hardware acceleration fixes this!

OS: Android
OS version: 10
react-native-version: 0.61.5
react-native-webview: 7.6.0

@gamingumar
Copy link

I am also facing the same issue in production build. This only happens for me the first time app starts. After the crash when I open the app again it works fine.

@ItsNoHax
Copy link

ItsNoHax commented Jan 13, 2020

@Titozzz This issue seems to have passed unnoticed and is causing a lot of headache since turning hardware acceleration off just isn't a feasible solution.

@ItsNoHax
Copy link

Guys, make sure your Webview always has a height of 1 or bigger. In my case my webview had 0 height until we send back the html content's height back.

@gamingumar
Copy link

@ItsNoHax this is how I am using it.

<WebView
      style={{
        flex: 1,
        minHeight: 200 }}
/>

@ItsNoHax
Copy link

ItsNoHax commented Jan 16, 2020 via email

@ItsNoHax
Copy link

ItsNoHax commented Feb 5, 2020

@Titozzz Hardware Acceleration on Android is causing a lot of crashes! In our case disabling hardware acceleration is not a possible solution since we need to render bigger pieces of HTML.

@selvin007
Copy link

selvin007 commented Feb 14, 2020

<ScrollView contentContainerStyle={{ flex: 1 }}> <WebView automaticallyAdjustContentInsets={false} scrollEnabled={false} source={{ uri: '' }} /> </ScrollView>

Worked for me

  • OS: Android
    
  • OS version: 9
    
  • react-native version: 0.61.5
    
  • react-native-webview version: 8.1.0
    

@safaiyeh
Copy link
Collaborator

Experiencing the same issue.

cc @kokuls can you drop some of your investigation in this thread

@RmondJone
Copy link
Author

RmondJone commented Feb 15, 2020

目前我的方案是重写RNCWebViewManager

  @ReactProp(name = "androidHardwareAccelerationDisabled")
  public void setHardwareAccelerationDisabled(WebView view, boolean disabled) {
    if (disabled) {
      view.setLayerType(View.LAYER_TYPE_NONE, null);
    }else{
      view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
    }
  }

并且在应用这个库的地方把androidHardwareAccelerationDisabled设置为true

<WebView
    {...props}
    ref={webView}
    androidHardwareAccelerationDisabled={true}
    injectedJavaScript={script}
    source={currentSource}
    scrollEnabled={currentScrollEnabled}
 />

强制把硬件加速给关了,切记开软件加速View.LAYER_TYPE_SOFTWARE也不行,会导致另外一个问题

java.lang.IllegalStateException: Unable to create layer for RNCWebViewManager$RNCWebView @86b0117, size 1440x10308 exceeds max size 8192
    at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
    at android.os.MessageQueue.next(MessageQueue.java:328)
    at android.os.Looper.loop(Looper.java:148)
    at android.app.ActivityThread.main(ActivityThread.java:6560)
    at java.lang.reflect.Method.invoke(Method.java)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1113)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:974)

导致这个问题的原因是ScollView嵌套了WebView,导致Webview不确定大小,而且Webview启动了硬件加速或者软件加速,由于硬件加速或者软件加速是有个最大的缓存区域的,最终导致超过了缓存范围。这个估计也不是官方库的Bug,是Android的Bug,他们也没有办法处理!

@SageWu
Copy link

SageWu commented Feb 28, 2020

same issue

@G3z
Copy link

G3z commented Feb 28, 2020

updating the webview component from playstore fixed the issue for us

@SageWu
Copy link

SageWu commented Mar 16, 2020

updating the webview component from playstore fixed the issue for us

playstore?

@G3z
Copy link

G3z commented Mar 16, 2020

playstore?

Yes, I mean updating chrome and It's webview component on the actual phone trough Google's playstore

@SageWu
Copy link

SageWu commented Mar 17, 2020

react-native-render-html can help...

@RmondJone
Copy link
Author

react-native-render-html can help...

Yes! I'm already Instead!

@kokuls
Copy link

kokuls commented Mar 19, 2020

Are you using react-native-navigation by any chance? I had a very similar stacktrace to you and managed to “fix” the bug by disabling screen transition animations.

@GitGitBoom
Copy link

Also using react-navigation. Fixed in my case by setting the mode property to "modal" on the stack navigator that contains my webview screens.

https://reactnavigation.org/docs/stack-navigator#transparent-modals

@react-navigation/native@5.1.3
├─ react-native-webview@9.0.1
└─ react-native@0.61.5

@github-actions
Copy link

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

@bitcrumb
Copy link

This is still happening in the latest version. Please reopen.
Setting androidHardwareAccelerationDisabled={true} on the WebView does prevent from crashing through.

@SS-In
Copy link

SS-In commented Jun 30, 2020

I had the same issue.
It works for me (Android 9 and 10).
To avoid crash WebView must have height > 0 and opacity < 1.

<WebView style={{ flex: 1, minHeight: 200, height: 300, opacity: 0.99 }} />

@at3s
Copy link

at3s commented Jul 29, 2020

I had the same issue.
It works for me (Android 9 and 10).
To avoid crash WebView must have height > 0 and opacity < 1.

<WebView style={{ flex: 1, minHeight: 200, height: 300, opacity: 0.99 }} />

tkank you, it work for me <3

@cristianoccazinsp
Copy link
Contributor

Is this still an issue?

@manuhook
Copy link

Is this still an issue?

yes :(

@poonamdhomane
Copy link

poonamdhomane commented Oct 16, 2020

@SS-In thanks , this works for me
<WebView style={{ flex: 1, minHeight: 200, height: 300, opacity: 0.99 }} />

@sea129
Copy link

sea129 commented Nov 26, 2020

setting opacity to 0.99 solves it

@vikasg603
Copy link

I had the same issue.
It works for me (Android 9 and 10).
To avoid crash WebView must have height > 0 and opacity < 1.

<WebView style={{ flex: 1, minHeight: 200, height: 300, opacity: 0.99 }} />

This works, But how you understood this issue?

@jwm0
Copy link

jwm0 commented Feb 16, 2021

I had the exact same issue using a youtube wrapper around a WebView. It would occasionally crash the android app when navigating from/to (react-navigation) the view using WebView. It seemed non-deterministic and happen on some devices more often than others. By setting androidLayerType explicitly to hardware this completely solved the issue and the crashes no longer occur.

@GleidsonDaniel
Copy link

GleidsonDaniel commented Mar 9, 2021

I had the same issue.
It works for me (Android 9 and 10).
To avoid crash WebView must have height > 0 and opacity < 1.

<WebView style={{ flex: 1, minHeight: 200, height: 300, opacity: 0.99 }} />

If you dont want to fix a height, just use minHeight prop + opacity, works as expected.

I believe that there is some incompatibility with react navigation, only when using the webview together with this lib that this problem occurs, a deeper study is needed to find out what happens.

There are some clues in the logcat but I'm not so good with native code lol.

@sangolariel
Copy link

sangolariel commented Jul 27, 2021

Add "androidLayerType={'hardware'}" it work for me.

       <WebView
            source={{
              uri: `https://www.youtube.com/embed/${_videoId}?playsinline=1`,
            }}
            androidLayerType={'hardware'}
            allowsFullscreenVideo={true}
            mediaPlaybackRequiresUserAction
            useNativeResumeAndPauseLifecycleEvents
            javaScriptEnabled
            allowsInlineMediaPlayback
            useWebKit={true}
            originWhitelist={['*']}
            automaticallyAdjustContentInsets
            onError={(e: any) => {
              setState({
                ...state,
                error: e.error,
              });
            }}
            onLoadEnd={() =>
              setState({
                ...state,
                isReady: true,
              })
            }
    />

@rafaelpinabew
Copy link

From version 10.8.0 the prop androidHardwareAccelerationDisabled is deprecated and should use the prop androidLayerType instead, on the References it says the following:

Avoid setting both androidLayerType and androidHardwareAccelerationDisabled props at the same time, as this may cause undefined behaviour.

Make sure to not set both props at the same time, for me doing this would cause the app to fail without any logs.

Just set:

<Webview androidLayerType="hardware" .... />

https://github.com/react-native-webview/react-native-webview/blob/master/docs/Reference.md#androidHardwareAccelerationDisabled

@Abbondanzo
Copy link

We've had success by:

  1. ensuring that the height of a WebView is always greater than 0 and
  2. setting the androidLayerType property to hardware as others have mentioned

Views must have a minimum height of 1 if they are to be set to a hardware layer type!

Why does this work?

I had the same issue.
It works for me (Android 9 and 10).
To avoid crash WebView must have height > 0 and opacity < 1.
<WebView style={{ flex: 1, minHeight: 200, height: 300, opacity: 0.99 }} />

This works, But how you understood this issue?

TL;DR: For anyone else setting the opacity to anything other than 1, Android is automatically setting the layer type of the webview to LAYER_TYPE_HARDWARE.

Under the hood, setting the opacity style calls a view's setAlpha method (see source code here). Acknowledged in the Android documentation is that all versions from Build.VERSION_CODES.M (a.k.a. Android 6.0) and up automatically set the view's layer type to LAYER_TYPE_HARDWARE to avoid render costs.

When a view has a layer type that is of LAYER_TYPE_HARDWARE or LAYER_TYPE_SOFTWARE, painting of that view happens separately from the main paint of your navigating view. Webviews are part of a special ViewGroup subclass called AbsoluteLayout in Android that do not respect transitions or animations from wrapping views. I have yet to test this theory but I would be interested to see if setting transitionGroup to true on the RNCWebView would stop this issue from occurring.

@idanlevi1
Copy link

Just add androidLayerType={'hardware'} to WebView props

<WebView 
  androidLayerType={'hardware'}
  // other props...
/>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests