问题表现 在低于 Android 7(Android Nougat)以下出现 错误的崩溃日志信息如下 1 2 3 4 5 6 7 8 9 Caused by: java.lang.ClassNotFoundException: Didn't find class "java.lang.invoke.SerializedLambda" on path: DexPathList[[dex file "/data/user/0/com.example/.00000000000/A3AEECD8.dex", zip
第一:可能是添加MultiDex分包,但未初始化的原因,在Application中重写attachBaseContext函数,对MultiDex初始化即可。
简介 本文记录的是:国庆节前夕,解决Crash率高达9.08%问题成功避免加班拿3倍工资的故事 PS: 除了在时间上两者相遇外,本文中提到的两个(top1&top2)crash问题与dex分包并没有关系 ---- 初见问题(2015-09-25) 2015-09-25:产品灰度第一天灰度结果:Crash率9.08%,主要是如下两个Crash所导致 TOP1: java.lang.NoClassDefFoundError 堆栈还原: java.lang.NoClassDefFoundError: com/ex
在一开始写Android的时候经常碰到一些ClassNotFoundException,大部分情况下是少导入了什么包导致的。我碰到一个困扰了一年之久的ClassNotFoundException,终于在这两天我解决了这个问题,下面让我给大家表演一下真正的技术。
Android模拟器6.0版本进入系统时,桌面应用com.android.launcher3会发生随机Crash。 W/System.err( 1611): java.lang.IllegalArgumentException: Wrong state class, expecting View State but received class android.appwidget.AppWidgetHostView$ParcelableSparseArray instead. This usually h
尝试在 Android 系统中执行 Java 程序 , 【开发环境】Android 命令行中执行 Java 程序 ( IntelliJ IDEA 中创建 Java / Kotlin 工程 | dx 打包 DEX 字节码文件 | dalvikvm 命令 ) , 出现的错误记录 ;
想进大厂,就关注「 程序亦非猿 」 时不时 8:38 推送优质文章,觉得有用,置顶加星标
在上一篇博客 【Android 逆向】启动 DEX 字节码中的 Activity 组件 ( DEX 文件准备 | 拷贝资源目录下的文件到内置存储区 | 配置清单文件 | 启动 DEX 文件中的组件 | 执行结果 ) 中 , 尝试启动 DEX 字节码文件中的 Activity 组件 , 出现如下报错信息 :
main方法时ZygoteInit入口方法,其中调用了ZygoteInit的preload方法,preload方法中又调用了ZygoteInit的preloadClasses方法。
使用场景 : 需要 Hook 住 View 的 OnClickListener 点击方法 , 该监听器在 View 的内部类 ListenerInfo 中 , 需要先通过反射 , 得到 ListenerInfo 字节码对象 ;
任何结论在没有经过实际检验之前都不能够确定一定没问题。三年前写的文章回过头来发现有些部分内容是有问题的(PS:这的确比较尴尬),再次对结果进行验证之后重新修改了之前的结论。幸亏文章阅读量不是很多,希望被误导的同学能够在其他地方得到正确结论。
我们知道不管是插件化还是组件化,都是基于系统的ClassLoader来设计的。只不过Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码
Dalvik是Google公司自己设计用于Android平台的Java虚拟机。它可以支持已转换为.dex(即Dalvik Executable)格式的Java应用程序的运行,.dex格式是专为Dalvik设计的一种压缩格式,可以减少整体文件尺寸,提高I/o操作的类查找速度所以适合内存和处理器速度有限的系统。
曾几何时,国内各大公司掀起了一股研究Android动态加载的技术,两年多过去了,动态加载技术俨然成了Android开发中必须掌握的技术。那么动态加载技术是什么呢,这里谈谈我的个人看法,如有雷同,纯属偶然。 什么是动态加载技术 对于动态加载的概念,没有一个权威的定义,参考网上的解释,我们举一个例子,动态加载代码就是通过在运行时加载外部代码(磁盘,网络等)改变程序行为的技术(感觉有点像装饰者模式)。主要目的是为了达到让用户不用重新安装APK就能升级应用的功能。 为了加深大家对这种概念的理解,我们结合pc端来说说
09-24 18:22:23.692: E/AndroidRuntime(22703): FATAL EXCEPTION: main 09-24 18:22:23.692: E/AndroidRuntime(22703): Process: com.example.nongmin, PID: 22703 09-24 18:22:23.692: E/AndroidRuntime(22703): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.nongmin/com.jarvis.user.info.UApplyedActivity}: android.view.InflateException: Binary XML file line #17: Error inflating class com.clockrock.widget.PullToRefreshLayout 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2392) 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2443) 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.app.ActivityThread.access$800(ActivityThread.java:157) 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1354) 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.os.Handler.dispatchMessage(Handler.java:110) 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.os.Looper.loop(Looper.java:193) 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.app.ActivityThread.main(ActivityThread.java:5348) 09-24 18:22:23.692: E/AndroidRuntime(22703): at java.lang.reflect.Method.invokeNative(Native Method) 09-24 18:22:23.692: E/AndroidRuntime(22703): at java.lang.reflect.Method.invoke(Method.java:515) 09-24 18:22:23.692: E/AndroidRuntime(22703): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:829) 09-24 18:22:23.692: E/AndroidRuntime(22703): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:645) 09-24 18:22:23.692: E/AndroidRuntime(22703): at dalvik.system.NativeStart.main(Native Method) 09-24 18:22:23.692: E/AndroidRuntime(22703): Caused by: android.view.InflateException: Binary XML file line #17: Error inflating class com.clockrock.widget.PullToRefreshLayout 09-24 18:22:23.692: E/AndroidRuntime(22703): at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java
一、SHA-1混淆 Found 2 versions of android-support-v4.jar in the dependency list, but not all the versions are identical (check is based on SHA-1 only at this time). All versions of the libraries must be the same at this time. Versions found are: Path: D:\wor
在Method与Filed数超限的背景下,我们将多工程拆分成多个Dex打到Apk中解决该问题,但是在使用MultiDex的时候,还会遇到一些问题。 在启动的时候会发生如下Crash。 在4.4以下会Crash,而5.0以上则不会发生Crash
上一篇博客 【Android 逆向】Dalvik 函数抽取加壳 ( 类加载流程分析 | ClassLoader#loadClass 函数分析 | BaseDexClassLoader#findClass 分析 ) 分析到 , 类加载流程中 , 在 BaseDexClassLoader 中的 findClass 方法中 , 主要调用 DexPathList pathList 成员的 findClass 函数查找类 ;
大致的意思是: ClassLoader 是一个负责加载classes的对象,ClassLoader类是一个抽象类,需要给出类的二进制名称,ClassLoader尝试定位或者产生一个class数据,一个典型的策略是把二进制名字转换成文件名然后到文件系统中找到该文件 以下是ClassLoader常用到的几个方法及其重载方法:
开发Android应用时,有时候Java层的编码不能满足实际需求,需要通过JNI的方式利用C/C++实现重要功能并生成SO文件,再通过System.loadLibrary()加载进行调用。常见的场景如:加解密算法、音视频编解码、数据采集、设备指纹等。通常核心代码都封装在SO文件中,也自然成为“黑客”攻击的目标对象,利用IDA Pro等逆向工具,可以轻松反编译未采取任何保护措施的SO文件,生成近似源代码的C代码,业务逻辑、核心技术将直接暴露在攻击者的眼前。进一步造成核心技术泄漏、隐私数据泄漏、业务逻辑恶意篡改等危害。
在 Android 开发中 , 尤其是项目比较大时 , 或引入的依赖库过多 , 一般的项目后期都会遇到 如下问题 , 整个工程的方法数超过了
在 dex_demo 应用 Module 中 , 创建 com.example.dex_demo.MainActivity2 类 ;
上篇文章讲到了apk的分包,通过multidex构建出包含多个dex文件的apk,从而解决65536的方法数限制问题《Android Dex分包》。
Java代码都是写在Class里面的,程序运行在虚拟机上时,虚拟机需要把需要的Class加载进来才能创建实例对象并工作,而完成这一个加载工作的角色就是ClassLoader。
例如记住了当前类的引用this、父类super等等。class文件记录的信息往往比java文件多。
PathClassLoader 是 Android 平台的类加载器 , 继承了 BaseDexClassLoader ;
参考 : 4.4.4_r1/xref/libcore/dalvik/src/main/java/dalvik/system/DexPathList.java
【Android 插件化】插件化简介 ( 组件化与插件化 ) 【Android 插件化】插件化原理 ( JVM 内存数据 | 类加载流程 ) 【Android 插件化】插件化原理 ( 类加载器 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 原理与实现思路 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 类加载器创建 | 资源加载 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 注入上下文的使用 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 获取插件入口 Activity 组件 | 加载插件 Resources 资源 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 运行应用 | 代码整理 )
Android Studio2.0时,新增了一个 Instant Run的功能,而各大厂的热修复方案,在代码,资源等方面的实现都是很大程度上参考了Instant Run的代码。所以可以说 Instant Run 是推进Android 热修复的主因。
一、类加载机制1. ClassLoader的类型2. ClassLoader的加载过程二、Java虚拟机的运行时内存模型三、垃圾标记算法1、引用计数算法:2、根搜索算法3、Java中的引用类型四、垃圾收集算法1. 标记-清除算法2. 复制算法3. 标记压缩算法4. 分代收集算法五、Android 虚拟机1. Android使用的虚拟机2. 引起GC的原因3.垃圾收集六、常见的内存问题七、常见的内存泄漏场景
在Android早期的版本中,应用程序的运行环境是需要依赖Dalvik虚拟机的。不过,在后来的版本(大概是4.x版本),Android的运行环境却换到了 Android Runtime,其处理应用程序执行的方式完全不同于 Dalvik,Dalvik 是依靠一个 Just-In-Time (JIT) 编译器去解释字节码。
说到这个就躲不过一个关键点 ClassLoader(类加载器) ,所以我们先从Java开始。
我们知道,Java源文件(.java)经过编译器编译之后,会转换成Java字节码(.class),然而程序是如何加载这些字节码文件到内存中呢?这就用到了ClassLoader,即类加载器。ClassLoader类加载器负责读取 Java 字节代码,并转换成 java.lang.Class类的一个实例。从而只有class文件被载入到了内存之后,才能被其程序所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。
在 Android中实现「类方法指令抽取方式」加固方案原理解析 博客中 , 首先对 Dex 字节码文件的结构进行了分析 , 函数抽取 , 主要是将 Dex 字节码文件中的函数进行抽取 , 然后在运行时再进行恢复操作 ;
本博客转载自网址:http://blog.csdn.net/urrjdg/article/details/78091094
在日常的 Android 应用安全分析中,经常会遇到一些对抗,比如目标应用加壳、混淆、加固,需要进行脱壳还原;又或者会有针对常用注入工具的检测,比如 frida、Xposed 等,这时候也会想知道这些工具的核心原理以及是否自己可以实现。
在分析IPC基于Android 6.0)的过程中,里面的核心部分是Native的,并且还包含一些linux kernel,而作为Android开发者看到的代码大部分都是Java层,所以这就一定会存在Java与C/C++代码的来回跳转,那么久很有必要来先说一下JNI,本文主要内容如下:
之前一直了解到加壳脱壳,直接使用Fart等脱壳工具进行的,停留在知其然不知其所以然的层次,所以以此准备进行Android 基础理论的学习中,首先要深入理解类加载器和动态加载二者之间的关系,本文记录了类加载器和动态加载之间的关系和原理,由于作者能力有限,会尽力的详细讲解两者之间的关系,如本文中有任何错误,烦请指正,感谢~
在上一篇博客 Android热修复学习之旅开篇——热修复概述中,简单介绍了各个热修复框架的原理,本篇博客我将详细分析QQ空间热修复方案。
三,JavaVM创建之后,我们就有了JNINativeInterface,里面包含了所有的Java接口,比如FindClass,NewObject,CallObjectMethod等
热修复已经不是什么新的话题,目前仍然对它的讨论很火,本文是一篇动态修复的实践篇,以腾讯HotFix为蓝本,带你体验热修复之旅。
上一篇博客 【Android 逆向】ART 脱壳 ( InMemoryDexClassLoader 脱壳 | BaseDexClassLoader 构造函数 | DexPathList 构造函数及后续调用 ) 分析到 , 在 DexPathList 中的 makeInMemoryDexElements 方法中 , 调用了 DexFile(ByteBuffer buf) 构造函数 , 创建 DexFile ;
当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时出错,提示: Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536 出现这种问题的原因是: 1. Android2.3及以前版本用来执行dexopt(用于优化de
市场上热修复有两种一种是基于multidex的更新修复(比如tinker),另外一种是native hook(比如dexposed),tinker这种是反射获取dexelements数组,修改dex加载顺序。今天我们主要介绍dex这种。 热修复包括两个部分
通过上面几个类的关系,和类的查找过程,我们可以发现最终是通过遍历 DexPathList的 dexElements数组进行类的查找加载,当找到类就返回;
开发过程中,一些低频使用的API不太记得,每次都要查一下。比如Build这个类。 做一个app,一边显示代码,一边显示结果,岂不美哉。
周一发布了新版本,当天晚上用户就为app未测试到的bug发飙了,恩,很快就找到了问题所在,一个容易疏忽的空指针。虽然只是一个小小的bug但是不修复是很影响用户体验的啊,如果要重新修复上线,波及范围太广了,所有用户又要重新下载。 我们可以让这个bug“偷偷”的修复
领取专属 10元无门槛券
手把手带您无忧上云