//加载器,apkPath为包含dex文件的.apk或jar路径,dexPath是优化后的dex文件路径,第三个表示libraryPath表示Native库的路径,最后是父类加载器 DexClassLoader classLoader= new DexClassLoader(apkPath, dexPath,null,getClassLoader()); try{      //类,在加载类时,先检查父类是否已经加载过这个类?      Class<?> mLoadClass=classLoa

1. 外部动态加载DEX文件风险描述 Android 系统提供了一种类加载器DexClassLoader,其可以在运行时动态加载并解释执行包含在JAR或APK文件内的DEX文件.外部动态加载DEX文件的安全风险源于:Anroid4.1之前的系统版本容许Android应用将动态加载的DEX文件存储在被其他应用任意读写的目录中(如sdcard),因此不能够保护应用免遭恶意代码的注入:所加载的DEX易被恶意应用所替换或者代码注入,如果没有对外部所加载的DEX文件做完整性校验,应用将会被恶意代码注入,从

1.Android动态加载dex技术初探 http://blog.csdn.net/u013478336/article/details/50734108 Android使用Dalvik虚拟机加载可执行程序,所以不能直接加载基于class的jar,而是需要将class转化为dex字节码. Android支持动态加载的两种方式是:DexClassLoader和PathClassLoader,DexClassLoader可加载 jar/apk/dex,且支持从SD卡加载:PathClassLoade

[版权所有,转载请注明出处.出处:http://www.cnblogs.com/joey-hua/p/5402599.html ] 此方案的目的是隐藏源码防止直接性的反编译查看源码,原理是加密编译好的最终源码文件(dex),然后在一个新项目中用新项目的application启动来解密原项目代码并加载到内存中,然后再把当前进程替换为解密后的代码,art模式下也没问题.好了,废话不多说,来看代码,下面是最终想运行的项目,也称为原项目: 这是原项目的目录,项目名叫Hello,就两个activity,第

本文转载自: http://blog.csdn.net/wy353208214/article/details/50859422 1.什么是类加载器? 类加载器(class loader)是 Java™中的一个很重要的概念.类加载器负责加载 Java 类的字节代码到 Java 虚拟机中.Java 虚拟机使用 Java 类的方式如下:Java 源程序(.java 文件)在经过 Java 编译器编译之后就被转换成 Java 字节代码(.class 文件).类加载器负责读取 Java 字节代码,并转换

/文章作者:MG193.7 CNBLOG博客ID:ALDYS4 QQ:3496925334/ 在读者阅读本文章前,建议先阅读笔者之前写的一篇对安卓载荷的分析文章 [逆向&编程实战]Metasploit安卓载荷运行流程分析_复现meterpreter模块接管shell 0x01 重温载荷运行原理 在笔者之前已经对Metasploit中的安卓载荷(以下简称Payload)进行了分析,已经明确了meterpreter模块如何对中马机下达命令的原理 先重温一遍Payload如何接收远控端发送的数据并执行

Dex动态加载是为了解决什么问题? 在Android系统中,一个App的所有代码都在一个Dex文件里面. Dex是一个类似Jar的存储了多个Java编译字节码的归档文件. 因为Android系统使用Dalvik虚拟机,所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件.这里需要强调的是,Dex和Jar一样是一个归档文件,里面仍然是Java代码对应的字节码文件. 当Android系统启动一个应用的时候,有一步是对Dex进行优化,这个过程有一个

前言 在目前的软硬件环境下,Native App与Web App在用户体验上有着明显的优势,但在实际项目中有些会因为业务的频繁变更而频繁的升级客户端,造成较差的用户体验,而这也恰恰是Web App的优势.本文对网上Android动态加载jar的资料进行梳理和实践在这里与大家一起分享,试图改善频繁升级这一弊病. 声明 欢迎转载,但请保留文章原始出处:) 博客园:http://www.cnblogs.com 农民伯伯: http://over140.cnblogs.com Android中文翻译组:

在目前的软硬件环境下,Native App与Web App在用户体验上有着明显的优势,但在实际项目中有些会因为业务的频繁变更而频繁的升级客户端,造成较差的用户体验,而这也恰恰是Web App的优势.本文对网上Android动态加载jar的资料进行梳理和实践在这里与大家一起分享,试图改善频繁升级这一弊病. Android应用开发在一般情况下,常规的开发方式和代码架构就能满足我们的普通需求.但是有些特殊问题,常常引发我们进一步的沉思.我们从沉思中产生顿悟,从而产生新的技术形式.如何开发一个可以自定义

http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html Android应用开发在一般情况下,常规的开发方式和代码架构就能满足我们的普通需求.但是有些特殊问题,常常引发我们进一步的沉思.我们从沉思中产生顿悟,从而产生新的技术形式. 如何开发一个可以自定义控件的Android应用?就像eclipse一样,可以动态加载插件:如何让Android应用执行服务器上的不可预知的代码?如何对Android应用加密,而只在执行时自解密,从而防

在目前的软硬件环境下,Native App与Web App在用户体验上有着明显的优势,但在实际项目中有些会因为业务的频繁变更而频繁的升级客户端,造成较差的用户体验,而这也恰恰是Web App的优势.本文对网上Android动态加载jar的资料进行梳理和实践在这里与大家一起分享,试图改善频繁升级这一弊病. Android应用开发在一般情况下,常规的开发方式和代码架构就能满足我们的普通需求.但是有些特殊问题,常常引发我们进一步的沉思.我们从沉思中产生顿悟,从而产生新的技术形式.如何开发一个可以自定义

最近工作中接到了一个研究防止逆向编译的任务.研究了几天资料,最后基本实现了防破解技术,在这个工程中,也略有一些心得体会,现整理下来分享,供大家探讨参考研究.文中如有纰漏.失实之处,请大家及时给与指正. 防破解技术主要有四种实现方式:1.代码混淆(ProGuard)技术 2.签名比对技术 3.NDK  .so 动态库技术 4.动态加载技术. 参考资料:http://bbs.pediy.com/showthread.php?t=137112 第一种 代码混淆技术(ProGuard)  该技术主要是进

动态加载框架DL分析 插件化开发,主要解决三个问题1.动态加载未安装的apk,dex,jar等文件2.activity生命周期的问题,还有service3.Android的资源调用的问题 简单说一下怎样解决这三个问题,让插件化开发成为可能1.解决未安装的apk比较简单,用DexClassLoader就可以解决(原始的jar要用dx转换一下,不能直接加载)2.activity在未安装的apk中只是一个普通的类,生命周期不会被系统管理.解决这个问题就是在宿主apk注册代理activity,这个act

前言 上周五DPAndroid小分队就第二阶段分享内容进行了讨论,结果形成了三个主题:性能优化.动态加载.内核远离.我选择的是第二项——动态加载.在目前的Android开发中,这一部分知识还是比较流行的,很大一部分原因是65k方法数的限制.国内各大IT公司的app开发者或多或少都遇到过这个老大难问题,并且各辟蹊径,公布了各自的应对方法.选这个议题,第一在于有价值(大型IT公司的Android开发一定会不可避免地在这个问题上纠结过,小型公司/开发者也许不在意,较高的门槛剔除了很多初级的无用信息):

为什么需要插件开发: 相信你对Android方法数不能超过65K的限制应该有所耳闻,随着应用程序功能不断的丰富,总有一天你会遇到一个异常: Conversion to Dalvik format failed:Unable toexecute dex: method ID not in [0, 0xffff]: 65536 可能有些同学会说,解决这个问题很简单,我们只需要在Project.proterty中配置一句话就Ok啦, dex.force.jumbo=true 是的,加入了这句话,确实可

一.前言 又到周末了,时间过的很快,今天我们来看一下Android中插件开发篇的最后一篇文章的内容:动态加载Activity(免安装运行程序),在上一篇文章中说道了,如何动态加载资源(应用换肤原理解析),没看过的同学,可以转战: http://blog.csdn.NET/jiangwei0910410003/article/details/47679843 当然,今天说道的内容还这这篇文章有关系.关于动态加载Activity的内容,网上也是有很多文章介绍了.但是他们可能大部分都是介绍通过代理的方

转载请注明出处:http://blog.csdn.net/singwhatiwanna/article/details/39937639 (来自singwhatiwanna的csdn博客) 前言 好久没有发布新的文章,这次打算发表一下我这几个月的一个核心研究成果:APK动态加载框架(DL).这段时间我致力于github的开源贡献,开源了2个比较有用且有意义的项目,一个是PinnedHeaderExpandableListView,另一个是APK动态加载框架.具体可以参见我的github:http

携程Android App的插件化和动态加载框架已上线半年,经历了初期的探索和持续的打磨优化,新框架和工程配置经受住了生产实践的考验.本文将详细介绍Android平台插件式开发和动态加载技术的原理和实现细节,回顾携程Android App的架构演化过程,期望我们的经验能帮助到更多的Android工程师. 需求驱动 2014年,随着业务发展需要和携程无线部门的拆分,各业务产品模块归属到各业务BU,原有携程无线App开发团队被分为基础框架.酒店.机票.火车票等多个开发团队,从此携程App的开发和发布

探秘腾讯Android手机游戏平台之不安装游戏APK直接启动法 重要说明 在实践的过程中大家都会发现资源引用的问题,这里重点声明两点: 1. 资源文件是不能直接inflate的,如果简单的话直接在程序中用代码书写. 2. 资源文件是不能用R来引用的,因为上下文已经不同了,腾讯的做法是将资源文件打包(*.pak文件和APK打包在一起),虽然APK是没有进行安装,但是 资源文件是另外解压到指定文件夹下面的,然后将文件夹的地址传给了第三方应用程序,这样第三方应用程序通过File的inputstream

在开发过程中,经常会用到第三方库,比如地图.视频.文档编辑.图表之类.依赖这些库,需要添加其SDK,有时需要用到jni层的So文件,比如百度地图等. 那么问题来了,如果两个不同的库之间的so文件发生冲突这么办? 比如:单独添加地图的库,运行没有问题.单独添加一个视频库,运行没有问题.但两者同时添加,其中一个库在init的时候报错.这当然和第三方库的开发水平有很大关系,但我们怎么解决这个问题呢?这就用到动态加载的方法. 这是原先的静态加载方法,将所有依赖库的so文件全部一股脑的放进armeabi文