title: Native crash peak on Samsung devices
body: <p>In the last month I saw a strong peak of native crashes on Google Play Console and they are coming from Samsung devices at 98% mostly Android 10 (90%) and secondarily Android 9 (10%). More than the half of cases are about Samsung S9 devices, while the rest is about a pretty recent device models (Samsung s10+, Note9, etc).</p>
  <p>There is the stacktrace:</p>
  <pre><code>  #00  pc 0000000000083360  /apex/com.android.runtime/lib64/bionic/libc.so (abort+176)
    #01  pc 0000000000008a74  /system/lib64/liblog.so (__android_log_assert+324)
    #02  pc 00000000003fb0dc  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::swapBuffers(android::uirenderer::renderthread::Frame const&amp;, SkRect const&amp;)+276)
    #03  pc 00000000003fae4c  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::swapBuffers(android::uirenderer::renderthread::Frame const&amp;, bool, SkRect const&amp;, android::uirenderer::FrameInfo*, bool*)+92)
    #04  pc 0000000000407c8c  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+716)
    #05  pc 0000000000406d38  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+216)
    #06  pc 0000000000417a44  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+228)
    #07  pc 0000000000417770  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+80)
    #08  pc 00000000000137a4  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+284)
    #09  pc 00000000000e3b14  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
    #10  pc 0000000000085330  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
  </code></pre>
  <p><del>In addition, also another issue appeared on Samsung devices only and Android 10 only (device model distribution seems pretty random):</del> this was solved without any particular action taken</p>
  <pre><code>#00  pc 0000000002cfeadc  /data/app/com.google.android.webview-8w0eiuwFhdVaEviNzD1U7g==/base.apk!libmonochrome.so (offset 0x15b000)
  </code></pre>
  <p>I have no clue on what is causing the issue, but I also attach my <code>build.gradle</code> file dependencies because these problems are usually linked to Google libraries.</p>
  <p>Did anyone see the same issue?</p>
  <p><del><strong>UPDATE</strong>
  Regarding the first issue, one of the major changes I applied to the app activity in which crashes happen, is about the newer Android View Binding. Since the crash seems to be related to UI, maybe this is the case. Does anyone use View Binding as well?</del></p>
  <p><del><strong>UPDATE 2</strong>
  It looks like that switching to the old <code>findViewById</code> (just in the Activity that was active at the time of the crash) instead of using View Binding made the problem disappear. For the moment I'm testing it on a small pool of beta testers but at this time I should have already seen some crash report. I will keep this post updated.</del></p>
  <p><strong>UPDATE 3 ─ 2022</strong>
  With the latest updates of Android 11, some things have changed, especially <a href="https://developer.android.com/about/versions/11/behavior-changes-all#fdsan" rel="nofollow noreferrer">this</a>. I don't know whether it was because I switched to API 31 or because I uploaded again Crashlytics symbols, but now I see a lot of new crash reports in Google Play console:</p>
  <pre><code>  #00  pc 0000000000053350  /apex/com.android.runtime/lib64/bionic/libc.so (fdsan_error(char const*, ...)+588)
    #00  pc 000000000005304c  /apex/com.android.runtime/lib64/bionic/libc.so (android_fdsan_close_with_tag+736)
    #00  pc 0000000000053884  /apex/com.android.runtime/lib64/bionic/libc.so (close+16)
    #00  pc 000000000000371c  /system/lib64/libTcpOptimizer.mobiledata.samsung.so (close+220)
    #00  pc 00000000001e7c24  /vendor/lib64/libgsl.so (!!!0000!6a7f7ec785028d96437db04399d932!4e552d6!+28)
    #00  pc 00000000000bb5f8  /vendor/lib64/libgsl.so (gsl_syncobj_destroy+152)
    #00  pc 000000000025d538  /vendor/lib64/egl/libGLESv2_adreno.so (!!!0000!10f39af3d5dda97a64124dee6a3783!4e552d6!+456)
    #00  pc 0000000000244ff8  /vendor/lib64/egl/libGLESv2_adreno.so (!!!0000!04fe7c7713a0660472688458ecb7a2!4e552d6!+144)
    #00  pc 000000000002b928  /system/lib64/libEGL.so (android::eglSwapBuffersWithDamageKHRImpl(void*, void*, int*, int)+776)
    #00  pc 0000000000027ea4  /system/lib64/libEGL.so (eglSwapBuffersWithDamageKHR+72)
    #00  pc 00000000003b0724  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::swapBuffers(android::uirenderer::renderthread::Frame const&amp;, SkRect const&amp;)+176)
    #00  pc 00000000003a3e30  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::swapBuffers(android::uirenderer::renderthread::Frame const&amp;, bool, SkRect const&amp;, android::uirenderer::FrameInfo*, bool*)+92)
    #00  pc 00000000003ac81c  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+1196)
    #00  pc 00000000003ae9e4  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+524)
    #00  pc 000000000039cefc  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+208)
    #00  pc 00000000003bf0ec  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+88)
    #00  pc 000000000001553c  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+320)
    #00  pc 0000000000014db0  /system/lib64/libutils.so (thread_data_t::trampoline(thread_data_t const*)+408)
    #00  pc 00000000000b6234  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64)
    #00  pc 0000000000050e64  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
  </code></pre>
  <p>This seems of course correlated to both the fdsan problem linked above and obscure abort stacktraces I'm seeing since two years ago. So I started digging into my code, looking for any fd-related bug and I came out with the following:</p>
  <p><strong>BUG #1:</strong> Found a bug in the code where I never closed a file descriptor after having passed it to <code>[MediaExtractor].setDataSource(FileDescriptor)</code>, because I thought <code>[MediaExtractor].release()</code>. <strong>I was wrong</strong>.</p>
  <p><strong>BUG #2:</strong> Found another subtle bug in JNI code where I'm receiving a file descriptor and I use it to open a stream with <code>fdopen()</code> and then I close it with <code>fclose()</code> when finished. This whole stream thing is made inside a third-party library and I wasn't aware of that ─ or I didn't really care about ─ and I was <strong>also</strong> calling <code>close()</code> over the same already-closed file descriptor. This lead to the so called double-close bug and guess what? fdsan is responsible for detecting this kind of bug and then abort. Before Android 11, fdsan behavior was to just output a silent warning, but then default settings changed to a fatal abort signal. This could not be a coincidence...?</p>
  <p>I sent out a version of the app with the above fixes to beta testers. Looking forward to post some positive results.</p>