13518219792
android4.x之后已经限制so不能从sdcard加载,但是可以从其他目录加载.
创新互联公司是专业的平湖网站建设公司，平湖接单;提供成都网站建设、成都做网站,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行平湖网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
so库不是简单的改一个字符串就行的.
如果加载成功,调用出错,那说明确实做了位置判断,不过真的很少会有这样的需求,一般常见的是会做包名判断,自身完整性校验
首先 在你把需要的文件复制到项目libs文件夹下(如果没有这个文件夹，自己建一个)；
然后再build.gradle的dependencies 里添加依赖；
文件不同添加依赖方式不同，如是arr文件
compile(name: 'XMF-2.0.3-release', ext: 'aar')
如果是jar包compile files('libs/passguard.jar')
当然也可以右键项目 选择open module setting--dependencies--选择+号添加你的文件
如果还有什么问题，联系我
好久没有写点东西发了，工作中的事情有点杂，也找不到整块东西可以写的。
最近调查了一个问题，稍微追了一下流程，这里记录一下。
由于我们支持的设备相对比竞品，zygote进程多占用了好几倍的内存空间。通过dump meminfo后发现，我们的设备在so库，ttf，和unkonwn mmap的内存空间相比竞品一共大了20多M，其中so库多了15M左右。
通过查看zygote进程的smaps，确定了占用空间最大的几个so库确实是我们自己的。虽然确定了内存占用大的原因，还是得把这些so库是加载在zygote进程中的时机确定了才行。
我的第一反应就是在zygote启动时，加载sharedLibrary()时，把这些库加载了，于是去看了这部分源码，并没有。
通过反复调试以及追踪源码，最后发现是在JVM启动的过程中加载了这些so库，这些so库的配置在“system/etc/public.libraries.txt”下。
这个文件里配置的都是public的so库，能够被普通app访问的。类似的配置文件还有“vendor/etc/”下面的，还有一些其他的配置地方，我没有深入去看，想要看的盆友可以自己去看源码或者注释。
下面我就带大家一起看看虚拟机加载这些so库的流程。
调用栈：
frameworks/base/cmds/app_process/app_main.cpp
----runtime.start("com.android.internal.os.ZygoteInit", args, zygote);
frameworks/base/core/jni/AndroidRuntime.cpp
----AndroidRuntime::startVm
---JNI_CreateJavaVM(pJavaVM, pEnv, initArgs）
art/runtime/jni/java_vm_ext.cc
---android::InitializeNativeLoader();
system/core/libnativeloader/native_loader.cpp
----Initialize()
----ReadConfig(public_native_libraries_system_config, sonames, always_true, error_msg)
其中，public_native_libraries_system_config 为 system/etc/public.libraries.txt
这部分流程是在安卓设备开机过程中的，在执行ZygoteInit.main()之前会先启动java虚拟机的，这样fork其他java进程的时候，java环境就已经有了，不用再创建虚拟机了。
最后贴一下Initialize()函数：
我们从一个简单的NDK Demo开始分析。
下面从 System.loadLibrary() 开始分析。
下面看 loadLibrary0()
参数 loader 为Android的应用类加载器，它是 PathClassLoader 类型的对象，继承自 BaseDexClassLoader 对象，下面看 BaseDexClassLoader 的 findLibrary() 方法。
下面看 DexPathList 的 findLibrary() 方法
回到 loadLibrary0() ，有了动态库的全路径名就可以装载库了，下面看 doLoad() 。
nativeLoad() 最终调用 LoadNativeLibrary() ，下面直接分析 LoadNativeLibrary() 。
对于JNI注册，这里暂不讨论，下面看 OpenNativeLibrary() 的实现。
下面看 android_dlopen_ext() 的实现
接下来就Android链接器linker的工作了。
下面从 do_dlopen() 开始分析。
find_library() 当参数translated_name不为空时，直接调用 find_libraries() ，这是装载链接的关键函数，下面看它的实现。
find_libraries() 中动态库的装载可以分为两部分
下面从 find_library_internal() 开始分析。
下面分析 load_library()
下面看另一个 load_library() 的实现
下面分析ELF文件头以及段信息的读取过程，也就是LoadTask的 read() ，它直接调用ElfReader的 Read() 方法。
动态库的装载在LoadTask的 load() 中实现。
下面看ElfReader的 Load() 方法
动态库的装载已经完成，下面看链接过程。
下面看 prelink_image()
链接主要完成符号重定位工作，下面从 link_image() 开始分析
下面以函数引用重定位为例分析 relocate() 方法
1,在项目根目录下建立文件夹libs/armeabi文件夹
2,将so库放入libs/armeabi文件夹注意事项：
1,如果采用静态注册的方式请注意C文件中严格按照命名规则Java_packageName_className_method()的方式命名
2,在Android项目中建立同上述命名规则中packageName中相同的包名,在此包名下建立同上述命名规则中className相同的类名
3,在className声明native方法
4,程序中加载so库System.loadLibrary(data/data/xxx.xxx.xxx/lib/xx.so)或者System.loadLibrary(xx),例如：System.loadLibrary(data/data/com.dtBank.app.service/lib/libjnixcld.so);
Android项目直接在手机上可以运行。但是打包完后会报这个错误，通过错误信息大概可以看出是混淆文件的问题，然后就加上RX的混淆重新打包就可以运行了。
