Android混淆代码时提示"Warning:org.apache.commons.httpclient.util.URIUtil: can't find referenced class org.apache.commons.codec.net.URLCodec"
解决方法是proguard-rules.pro中增加如下语句：
-dontwarn org.apache.commons.httpclient.**
其他类似的警告信息，可以参考以上的方法，逐行添加即可。
ProGuard error can't find superclass or interface org.apache.http.entity
QFix 是手Q团队近期推出的一种新的 Android 热补丁方案，在不影响 App 运行时性能（无需插桩去 preverify）的前提下有效地规避了 dalvik 下”unexpected DEX”的异常，而且还是很轻量级的实现：只需调用一个很简单的方法就能办到。
自2015年 Android 热补丁技术开始出现，之后各种方案和框架层出不穷，原创性的技术方案主要有以下几种：
插桩的解决方案会影响到运行时性能的原因在于：app 内的所有类都预埋引用一个独立 dex 的空类，导致安装 dexopt 阶段的 preverify 失败，运行时将再次 verify+optimize。近期我们通过 ReDex 尝试优化手Q的启动性能时发现：
另外即使后期手Q的发布版本实际上无需发布补丁，我们也需要预埋插桩的逻辑，这本身也是不合理的一点，所以确实有必要去探索新的方向，既保留补丁的能力，同时去掉插桩带来的负面影响。
寻找新的解决方案，还是需要回过头来分析下这个异常出现的条件：
主要思路是：每当系统调用到这个方法，通过 native hook 拦截这个系统方法，更改这个方法的入口参数，将 fromUnverifiedConstant 统一改为 true，但和 Andfix 类似，native hook 方式存在各种兼容性和稳定性问题，而且拦截的是一个涉及 dalvik 基础功能同时调用很频繁的方法，无疑风险会大很多。
这段逻辑所在的方法是 dvmResolveClass，通过类之间的引用会调用这个方法，入口参数分别是引用类的 ClassObject，被引用类的 classIdx，以及引用关联的 dalvik 指令是否为 const-class/instance-of，返回的是被引用类的 ClassObject，经反复阅读分析，终于发现了一个可以利用的细节:
dvmResolveClass 在最开始会优先从当前 dex 已解析类的缓存里找被引用类，找到了直接返回，找不到时说明被引用类还没有被加载，接着加载成功后，会往当前 dex 缓存里设置上这个类的引用，后续所有对补丁类的解析引用都不会走到后面的“unexpected DEX”异常逻辑里，至于 dex 里已解析类 get/set 的相关逻辑如下：
另外考虑多 dex 的情况，补丁类很可能被多个不同 dex 里的类引用，那么需要在每个 dex 里找到一个引用类来预先引用补丁类吗？如果 app 里引用类和补丁类原本是在同一个 dex 里，引用类有可能是 preverify 的，这种情况是需要预先引用的；如果原本就不是一个 dex 里的，引用类由于有对其它 dex 类的依赖，就肯定不是 preverify 的，这种情况条件2本来就是不满足的，就没有必要预先引用了，所以可以推断出只需要针对补丁类在原先 App 所对应的 dex 进行预先引用即可。
梳理了思路后，马上在一个简单的 demo 上验证：
上面的 demo 预埋了补丁里包含的类，但在实际运用中我们是无法预先设定哪些类要打补丁的，dex 里对补丁类 const-class/instance-of 方式的引用指令是编译时确定的，但具体是哪些类又需要在运行时动态确定，所以这种动态方式行不通，最初想到的是类似插桩的做法，预先把 app 里所有类都以 const-class 方式引用一遍，但很明显有以下问题：
1）由于 App 里类的数量很多，所有类的预先引用统一放在一个地方肯定不现实，需要分散在多个区，只对补丁类所在的少数几个区执行预先引用的操作，但这里如何划分的粒度不好把握，而且 App 里的类及数量一直变化，我们做过一些尝试，但没有比较理想的可考量的方案。
2）预先引用解析所有类，会增加引用类的加载耗时和引用语句本身的执行耗时，对于执行耗时，可以通过添加条件判断来优化，如果要解析的类在补丁类名列表里就执行该语句，否则就不执行，对于加载耗时，初步的测试结果如下（这里一个划分的区包含500个左右的类，并进一步区分了是否 preverify，而测试的补丁包里包含2个类）：
3）该方案实现起来特别繁琐，不实用。
新的方案在 Java 层找不到可行的实现方式，就尝试从 native 层切入，只需首次引用解析补丁类时，直接通过 jni 调用 dalvik 的 dvmResolveClass 这个方法，当然传入的参数 fromUnverifiedConstant 需要设为 true，这个思路与前面说的 native hook 方式不同，不会去 hook 这个系统方法，而是从 native 层直接调用：
这里的关键是能获取到前两个参数的值，第一个参数引用类的 ClassObject，最初借鉴的是 dvmResolveClass 里调用的 dvmFindClassNoInit 这个方法，但这个方法获取一个类的 ClassObject 需要两个参数，其中类名很容易构造，但需要额外的操作获取引用类的 ClassLoader 对象的地址，之后又找到一个更便利的方法 dvmFindLoadedClass：
输入： 原有 apk 的所有 dex、补丁包所有的类名
输出： 补丁包每个类所在 dex 的编号以及 classIdx 的值
注1： 如果在补丁新增原 app 不存在的类，运行时新增类只会被补丁 dex 即同一个 dex 里的类所引用，所以新增的补丁类无需预先解析引用。
注2： 由于”unexpected DEX”异常出现在 dalvik 的实现里，art 模式下不会存在，以上预先引用补丁类的逻辑只需用在5.0以下的系统。
最终新方案的整体实现流程如下图所示：
这个方案由于是 native 层的，我们也通过众测方式对兼容性做了充分的验证：
1. 不同系统版本导出符号：
在2.x版本dalvik是用C写的，2.3以上的4.x版本是用C++写的，基于C++ name mangling原理， dvmFindLoadedClass在编译后会变为_Z18dvmFindLoadedClassPKc，但经IDA反汇编libdvm.so分析，dvmResolveClass没有变化
2. yunos ROM的兼容性问题：
在第一次众测任务中，有446位用户参与，其中有6位反馈补丁不生效的问题，从反馈的结果码看都是libdvm.so加载成功，但是符号导出为NULL导致的，后来发现这6位用户安装的都是yunos的rom，经分析定位到原因如下：
可以看到dlopen libdvm.so时将库的名字改为了libvmkid_lemur.so，yunos的dalvik实现实际上在后面这个库里，而且通过反汇编发现导出的符号名也变化了，但内部的实现逻辑没有变化：
dvmResolveClass -> vResolveClass _Z18dvmFindLoadedClassPKc -> _Z18kvmFindLoadedClassPKc
在dlsym调用时考虑以上两种可能的符号名即可，经本地和以上问题用户的再次验证，已成功解决。
3. x86平台的兼容性问题：
解决了yunos的兼容问题后，在第二次众测任务中，有1884位用户参与，有3位反馈异常，发现问题用户都是x86平台的，由于最开始未对x86平台作兼容，arm平台的动态库在x86手机上运行的异常有两种：
a) 部分手机一直卡在黑屏界面，经日志定位，这些手机都安装了houndini的第三方库，会自动将arm的so转换为x86平台兼容的，so加载及符号导出都没问题，在成功获取dvmResolveClass符号地址后，就一直卡在dvmResolveClass的调用逻辑里，应该是houndini库的转换问题
b) 部分手机运行正常，但导出符号都为NULL
在提供x86平台的so后，以上两个问题也成功解决了。
本文探讨的主要是为解决补丁 Java 方案在 dalvik 下”unexpected DEX”异常提供一个新的思路，在整个 Android 补丁大的技术框架下，只是其中一个环节，有问题，欢迎大家多多交流！
Linux下的so文件通常是作为动态链接库使用的，但其实so文件跟可执行程序一样都是ELF格式，所以应该都是可以直接执行的。
Linux下编译可以执行的so文件如下：
#include <stdio.h>
#include <stdlib.h>
void lib_entry()
{
printf("Entry point of the service library\n");
exit(0);
}
注意，lib_entry()必须以exit(0)结束，否则会导致进程退出失败。
使用如下命令编译源代码：
$ gcc -shared service.c -o libservice.so -Wl,-e,lib_entry -fPIC
-Wl表示传递给链接器ld的参数，分隔的逗号会被替换成空格。-e,lib_entry就指明了入口函数。
而对于Android来说，只需要在Android.mk文件中增加LOCAL_LDLIBS += -Wl,-e,lib_entry就可以达到相同的目的了。
int main(int argc,char* argv[])这样的参数进去？答案是不能，那么启动参数从哪里读取呢？ 答案就是从/proc/$pid/cmdline中手工解析获取。
C库的代码，在调用代码时候为什么没有崩溃？正常情况下，可执行程序的入口函数实际上是C库的的入口函数，然后C库自身初始化完成，解析参数后调用我们自己实现的入口函数。按照常规逻辑，如果没有初始化C库，那么调用C库函数的时候，几乎肯定是会崩溃的。
反编译正常的可执行程序，应该都能看到C库的初始化函数，而指定了入口的，基本上都没有这个函数的调用。
但是在Linux下面ld.so会帮我们初始化一次C库，而我们又是被ld.so加载起来的，因此理论上，我们不需要再次初始化C库了。
Android系统上使用SQLite数据库存储数据，结果发现，如果刚刚写入数据之后在很短的时间之内，如果立即断电会丢失刚刚写入的数据。
根据Google官方的文档,发现，从API-16开始，提供了enableWriteAheadLogging这个API来要求SQLite先写日志，后写数据库。这个行为才是常规数据库默认的行为。
一般Android设备使用的存储设备都是Flash闪存,是有写入寿命以及空间限制的，因此默认不启用日志功能，也是迫不得已，更何况数据库日志属于只增不减的，这就导致长时间运行后，会出现空间无法释放的问题。
还有一个解决方法就是，插入以及修改数据的时候，启用SQLite的事务模型，由于事务一定要保证数据已经同步到磁盘了，因此，可以避免出现断电后数据由于没有刷新到磁盘导致的数据丢失。
db.beginTransaction();
try {
...
db.setTransactionSuccessful();
} finally {
db.endTransaction();
}
很多时候，会发现直接通过Kill，杀掉进程，一般是不会丢失数据的，原因在于磁盘写入的时候，系统会进行缓存，等合并到一定的量或者时间，系统一次性同步到磁盘，这样可以大大提供系统的性能。因此进程虽然已经死掉了，但是系统还是会把已经提交到内核的数据刷新到磁盘的，因此表现就是数据不会丢失。但是如果是断电的话，系统也就无能为力了。于是表现就是，越是新的Linux内核版本，反倒越是在异常断电的时候容易丢失数据。
最近服务器上面一直出现Tomcat莫名奇妙的被系统杀掉，后来从系统的日志中找到如下信息：
Oct 10 02:55:16 AY130422143404983ad9 kernel: [451276.905623] Out of memory: Kill process 809 (java) score 241 or sacrifice child Oct 10 02:55:16 AY130422143404983ad9 kernel: [451276.905684] Killed process 809 (java) total-vm:1291052kB, anon-rss:493732kB, file-rss:0kB
原来是系统内存不足，导致进程被杀掉了，网上搜了一下,解决方法有两个
1.限制Tomcat使用的内存
方法如下：
$ sudo vim /usr/share/tomcat7/bin/setenv.sh
在文件尾部增加如下配置：
#防止Tomcat的OOM export JAVA_OPTS="-server -Xms512M -Xmx1024M"
然后重启Tomcat
$ sudo service tomcat7 restart
2.为阿里云服务器增加swap分区/swap文件，来解决物理内存不足的问题
阿里云的服务器默认没有开启交换分区，导致内存极易耗尽导致服务被杀死，解决方法就是手工增加一个交换文件，来解决这个问题。
#如果要修改或者调整交换文件的大小，需要先停止交换文件，然后才能调整 # sudo swapoff -a #创建一个2G的文件,要求每个扇区512个字节 $ sudo dd if=/dev/zero of=/swaps_file bs=512 count=4194308 $ sudo chmod 0644 swaps_file $ sudo mkswap /swaps_file $ sudo swapon /swaps_file $ sudo cp /etc/sysctl.conf /etc/sysctl.conf.bak.old $ sudo sed -i 's/^vm.swappiness[ \t]*=[ \t]*0$/vm.swappiness = 60/g' /etc/sysctl.conf $ sudo cat /proc/sys/vm/swappiness $ sudo sysctl -w vm.swappiness=60 $ sudo cat /proc/sys/vm/swappiness $ sudo sed -i '$a\/swaps_file swap swap defaults,discard 0 0' /etc/fstab $ sudo cp /etc/rc.local /etc/rc.local.bak.old $ sudo sed -i 's/^swapoff[ \t]*-a$/swapon -a/g' /etc/rc.local
在淘宝上买了个Linksys WRT 1900AC是没有外包装的，网上搜了一下，发现存在的V1,V2两个硬件配置版本。
V1的CPU是1.2G带风扇，V2是CPU 1.3G不带风扇，内存V2是512MB ，V1是256MB
详细配置信息如下图：
官方固件下载地址为：
http://www.linksys.com/us/support-article?articleNum=148550
目前最新的官方固件链接：
http://cache-www.belkin.com/support/dl/FW_WRT1900AC_1.1.10.167514_prod.img
本站缓存的Linksys WRT 1900AC V1最新官方固件地址：
fw_wrt1900ac_1-1-10-167514_prod-img
OpenWRT的相关固件下载地址：
https://wiki.openwrt.org/toh/linksys/wrt1x00ac_series#stable
本站缓存的Linksys WRT 1900AC V1的OpenWRT的目前版本的快照：
openwrt-15-05-1-mvebu-armada-xp-linksys-mamba-squashfs-factory-img
最近使用Android中的WebView开发应用，结果在实际使用的时候，前端开发的网页展现的时候，总是什么都看不到，结果跟踪分析发现，页面在加载完成后，就去获取页面的宽高，然后根据页面的宽高进行页面的渲染，但是页面加载完成后JavaScript中得到的页面的宽高都是0，结果就导致整个的页面被渲染成了空页面。
项目是使用一个Dialog里面嵌入WebView的方式进行处理的，当网页加载完成之前，是不显示出来的，只有当网页加载完成后，页面才会展现出来。
实际的情况是，如果先展示Dialog，等整个Dialog已经完全展现出来之后，再去加载页面，这个时候，JavaScript代码是可以获取到正确的宽高的。但是，如果先加载页面，然后等待页面的加载完成通知，再去显示页面的时候，这个时候，由于Dialog还没有显示出来，此时内嵌的WebView并没有得到实际的宽度高度，因此只能获得到0。
示例工程的代码如下：
布局文件layout_webview.xml
<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<WebView
android:id="@+id/web_view"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layerType="software" />
</FrameLayout>
对话框代码WebViewDialog.java
import android.app.Dialog;
import android.content.Context;
import android.os.Handler;
import android.os.Looper;
import android.util.Log;
import android.view.Window;
import android.view.WindowManager;
import android.webkit.JavascriptInterface;
import android.webkit.WebView;
import android.webkit.WebViewClient;
import android.widget.Toast;
public class WebViewDialog extends Dialog {
public WebViewDialog(Context context) {
super(context);
setContentView(R.layout.layout_webview);
Window window = getWindow();
WindowManager.LayoutParams params = window.getAttributes();
params.type = WindowManager.LayoutParams.TYPE_TOAST;
params.height = WindowManager.LayoutParams.MATCH_PARENT;
params.width = WindowManager.LayoutParams.MATCH_PARENT;
window.setAttributes(params);
mWebView = (WebView) findViewById(R.id.web_view);
mWebView.setWebViewClient(mWebViewClientBase);
mWebView.getSettings().setJavaScriptEnabled(true);
mWebView.addJavascriptInterface(new JsBridge(),"JsBridge");
}
public void showWebView(){
final String strHtml = "<html>" +
" <head>" +
" <script>" +
" window.JsBridge.jsGetWindowWithHeight(document.documentElement.clientWidth,document.documentElement.clientHeight);" +
" </script>" +
" </head>" +
"</html>";
mWebView.loadData(strHtml,"text/html","UTF-8");
}
public class JsBridge{
@JavascriptInterface
public final void jsGetWindowWithHeight(int aWidth,int aHeight) {
Log.d("jsGetWindowWithHeight","Width=" + aWidth + " Height=" + aHeight);
Toast.makeText(getContext(),"Width=" + aWidth + " Height=" + aHeight,Toast.LENGTH_LONG).show();
}
}
private class WebViewClientBase extends WebViewClient {
@Override
public void onPageFinished(WebView view, String url) {
mHandler.removeCallbacks(mShowRunnable);
mHandler.post(mShowRunnable);
}
}
private final Runnable mShowRunnable = new Runnable() {
@Override
public void run() {
WebViewDialog.this.show();
}
};
private final WebViewClientBase mWebViewClientBase = new WebViewClientBase();
private WebView mWebView;
private static Handler mHandler = new Handler(Looper.getMainLooper());
}
主界面代码MainActivity.java
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
webViewDialog = new WebViewDialog(this.getApplicationContext());
setContentView(R.layout.activity_main);
Button btn = (Button)findViewById(R.id.btnClick);
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
webViewDialog.showWebView();
}
});
}
private WebViewDialog webViewDialog;
}
主界面布局文件activity_main.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/activity_main"
android:layout_width="match_parent"
android:layout_height="match_parent">
<Button
android:id="@+id/btnClick"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Click" />
</RelativeLayout>
完整运行整个例子，会发现最后输出的屏幕的宽高信息都是0。
这个问题发生的原因是由于界面在页面加载之后才会显示，由于页面还没有显示，因此从JavaScript中获取页面的大小的时候,只能获取到0.
这个问题如果要求页面解决的话，那么编写网页的开发人员，只要监听window.onsize事件即可。
如果要求WebView的开发者来解决的话，则其解决方式如下：
1.修改WebViewDialog初始化网页时候的策略，初始化时候禁止JavaScript执行。WebViewDialog构造函数中的mWebView.getSettings().setJavaScriptEnabled(true);调整成mWebView.getSettings().setJavaScriptEnabled(false);
2.页面加载逻辑照旧执行。
3.实现Dialog的onAttachedToWindow函数，在这个函数中重新加载数据
@Override
public void onAttachedToWindow() {
/*此处我们呼应下面代码中禁用JavaScript的支持的部分代码
* 原因也已经解释的非常详细了
* 但是此处需要注意，就是先reload再次启用JavaScript这个顺序不要乱掉，否则
* 可能还没有调用reload之前，前一个页面已经执行了JavaScript导致页面上面的埋点两次执行。
*
* 关于性能的隐忧，由于我们重新reload了页面，地址链接并没有改变，因此并不会去服务器上面重新获取页面
* 此处的性能隐忧，应该是不存在的
*
* 至于是不是需要手工设置一下Chrome内核的缓存时间，这个在目前的实际实验观察看来，是不需要的。
*
* */
mWebView.reload();
mWebView.getSettings().setJavaScriptEnabled(true);
}
最终的WebViewDialog.Java的代码如下：
import android.app.Dialog;
import android.content.Context;
import android.os.Handler;
import android.os.Looper;
import android.util.Log;
import android.view.Window;
import android.view.WindowManager;
import android.webkit.JavascriptInterface;
import android.webkit.WebView;
import android.webkit.WebViewClient;
import android.widget.Toast;
public class WebViewDialog extends Dialog {
public WebViewDialog(Context context) {
super(context);
setContentView(R.layout.layout_webview);
Window window = getWindow();
WindowManager.LayoutParams params = window.getAttributes();
params.type = WindowManager.LayoutParams.TYPE_TOAST;
params.height = WindowManager.LayoutParams.MATCH_PARENT;
params.width = WindowManager.LayoutParams.MATCH_PARENT;
window.setAttributes(params);
mWebView = (WebView) findViewById(R.id.web_view);
mWebView.setWebViewClient(mWebViewClientBase);
/*此处禁用JavaScript，而是在后面onAttachedToWindow事件中再启用JavaScript的支持，同时强制页面刷新
* 这么处理的原因是由于前端同学在开发页面时候，会使用一个自有的JavaScript框架，这个框架会在页面
* 加载完成后，立即获取页面的宽高，但是此时获取到的宽高都是 0 ,因为此时Chrome还没有完成整个页面的Layout
* 因此我们需要在页面完成Layout后再次加载页面才可以，但是如果此处启用JavaScript的支持会导致埋点数据的意外
* 上行，导致双份的埋点问题，因此，此处强制禁用JavaScript
* */
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.addJavascriptInterface(new JsBridge(),"JsBridge");
}
@Override
public void onAttachedToWindow() {
/*此处我们呼应下面代码中禁用JavaScript的支持的部分代码
* 原因也已经解释的非常详细了
* 但是此处需要注意，就是先reload再次启用JavaScript这个顺序不要乱掉，否则
* 可能还没有调用reload之前，前一个页面已经执行了JavaScript导致页面上面的埋点两次执行。
*
* 关于性能的隐忧，由于我们重新reload了页面，地址链接并没有改变，因此并不会去服务器上面重新获取页面
* 此处的性能隐忧，应该是不存在的
*
* 至于是不是需要手工设置一下Chrome内核的缓存时间，这个在目前的实际实验观察看来，是不需要的。
*
* */
mWebView.reload();
mWebView.getSettings().setJavaScriptEnabled(true);
}
public void showWebView(){
final String strHtml = "<html>" +
" <head>" +
" <script>" +
" window.JsBridge.jsGetWindowWithHeight(document.documentElement.clientWidth,document.documentElement.clientHeight);" +
" </script>" +
" </head>" +
"</html>";
mWebView.loadData(strHtml,"text/html","UTF-8");
}
public class JsBridge{
@JavascriptInterface
public final void jsGetWindowWithHeight(int aWidth,int aHeight) {
Log.d("jsGetWindowWithHeight","Width=" + aWidth + " Height=" + aHeight);
Toast.makeText(getContext(),"Width=" + aWidth + " Height=" + aHeight,Toast.LENGTH_LONG).show();
}
}
private class WebViewClientBase extends WebViewClient {
@Override
public void onPageFinished(WebView view, String url) {
mHandler.removeCallbacks(mShowRunnable);
mHandler.post(mShowRunnable);
}
}
private final Runnable mShowRunnable = new Runnable() {
@Override
public void run() {
WebViewDialog.this.show();
}
};
private final WebViewClientBase mWebViewClientBase = new WebViewClientBase();
private WebView mWebView;
private static Handler mHandler = new Handler(Looper.getMainLooper());
}
Ubuntu 16.04出现“/tmp 容量不够”的提示，当时安装系统的时候/tmp是单独划分出来的，大小被限制为2GB，这个时候尝试用gparted来进行拉大分区的时候，发现由于分区在其他分区中间，导致没办法加大临时分区。
当时划分分区的时候，系统分区的大小是足够的，因此，我们只需要在/etc/fstab中注释掉临时分区即可，此时系统会自动在根分区"/"下面生成临时文件即可了。
$ sudo vim /etc/fstab
注释掉这句话即可：
# /tmp was on /dev/sdc6 during installation UUID=5c6f4b66-0d9c-4da2-9362-4da121fd4657 /tmp btrfs defaults
之后需要重启系统。
在处理完成后，记得修改回原样。
公司的服务器只能通过跳板机的方式来链接，因此在Windows中使用PuTTY连接跳板机，结果实际使用中发现，会频繁被跳板机断开，而如果在目标机器中执行一个ping 127.0.0.1则连接始终不会被断开。那么说明是由于跳板机设置了一段时间如果没有报文通信就断开连接的功能，而且这个时间设置的比较激进。
请教了一下别人，找到如下设置即可解决这个问题：
其实质是开启了TCP的KeepAlive心跳报文。默认这个时间是"0"，也就是TCP链路中不发送心跳报文。把这个时间设置成"1"，也就是每秒都发送一次心跳。