调用File.listFiles出现JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal...异常

  最近在弄一个目录检索功能，直接调用File的listFiles()进行层级检索，在低版本手机上没有问题，但是在6.0的手机上，发生崩溃闪退，诡异的是，try catch居然catch不住，Throwable都不行。
代码崩溃位置

异常信息
JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0xba
string: ‘����HD��������.mkv’
in call to NewStringUTF
from java.lang.String[] java.io.File.listImpl(java.lang.String)
“pool-1-thread-1” prio=5 tid=15 Runnable
| group=“main” sCount=0 dsCount=0 obj=0x12e42fa0 self=0x7f9b475c00
| sysTid=27674 nice=0 cgrp=default sched=0/0 handle=0x7f74dda440
| state=R schedstat=( 1740771 5213154 15 ) utm=0 stm=0 core=4 HZ=100
| stack=0x7f74cd8000-0x7f74cda000 stackSize=1037KB
| held mutexes= “mutator lock”(shared held)
native: #00 pc 000000000045fa94 /system/lib64/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiPKcPNS_9ArtMethodEPv+312)
native: #01 pc 000000000042f19c /system/lib64/libart.so (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+220)
native: #02 pc 00000000002e51b8 /system/lib64/libart.so (ZN3art9JavaVMExt8JniAbortEPKcS2+1268)
native: #03 pc 00000000002e5a60 /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+116)
native: #04 pc 0000000000118764 /system/lib64/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+144)
native: #05 pc 0000000000120998 /system/lib64/libart.so (_ZN3art11ScopedCheck5CheckERNS_18ScopedObjectAccessEbPKcPNS_12JniValueTypeE.constprop.116+11084)
native: #06 pc 0000000000129be0 /system/lib64/libart.so (_ZN3art8CheckJNI12NewStringUTFEP7_JNIEnvPKc+468)
native: #07 pc 0000000000019328 /system/lib64/libjavacore.so (Z13toStringArrayI13VectorCounter12VectorGetterEP13_jobjectArrayP7_JNIEnvPT_PT0+204)
native: #08 pc 00000000000195f8 /system/lib64/libjavacore.so (???)
native: #09 pc 0000000000043574 /data/dalvik-cache/arm64/system@[email protected] (Java_java_io_File_listImpl__Ljava_lang_String_2+152)
at java.io.File.listImpl(Native method)
at java.io.File.list(File.java:740)
at java.io.File.listFiles(File.java:782)
  异常信息太多，截取主要部分。刚开始有点蒙，第一想法系统API不应该存在这么大的问题，竟然catch都catch不住。然后开始查资料，看log信息。log里面，包含了很多信息，最重要看开头，JNI DETECTED ERROR IN APPLICATION… jni调用异常，其中c代码 NewStringUTF，转换成字符串时报错。这个原因是检索的文件中，存在非utf-8编码的命名文件，调用listFiles()方法时，底层本地方法报错，引发程序崩溃。本地方法层出现问题，自然不是Java层可以控制的了。
  怎么解决？头疼了一个晚上。最后尝试着打包一个release包出来，放手机上运行。结果，竟然好了？！！！网上资料，在AndroidManifest application标签，添加android:debuggable="false"属性，我这边测试没有效果。但是安卓打包release版本，安卓系统会自动将debugable属性改为false，防止应用被恶意破解调试。
  事实，确实解决了。具体为什么会这样，不太清楚，有可能谷歌的想法，在调试开发阶段，本地方法层的错误直接抛出，release发布阶段，本地层内部进行判断控制处理，具体没有深入研究。
  问题解决了，但一个较真的问题来了，release包，那非utf-8编码的命名文件是像其他文件一样返回File[]结果，还是直接被略过？
本着这个想法，稍微较真了一回
这是debug包

直接异常崩溃
release包检索情景

里面有4个文件，134.mp3是为了进行对比，手动创建的一个空mp3文件，其他3个都是非utf-8编码命名文件，就是乱码文件。
这是手机上原文件

看得出来，release包，这些乱码文件是和其他文件一样，都会返回listFiles()的File[]结果中，不会被略过。看具体输出信息，似乎经过了一定转码，但也有可能是电脑上特殊字符的转换。
好了，问题解决，特此记录一下，免得以后再被坑。