自己动手，丰衣足食

最近虾米Android用得不甚顺畅。主要问题是，拿着虾米Android听电台，听着听着，自动就关了……
一般都是在启动别的程序的时候挂掉。各种程序都可能引发，用内存多的概率更大。有时候没动手机也会自己挂掉。
之前就怀疑是Android低内存自动杀进程功能干的。近日研究了一下：

首先，用ps | grep xiami列xiami进程。每次挂掉之后，列进程可以发现com.xiami那个进程不见了。过一会儿，这进程又会被重新启动起来。但是音乐播放不会自动恢复。
看系统信息里面，虾米总共开了俩服务，一个是push message receiver，对应ps里面那个com.xiami:push。另一个就是music play service，对应那个被干掉的com.xiami。

我印象里，Android里面开了服务，就不应该会被干掉，至少会比那些后台程序更晚被干掉。利用adb shell dumpsys meminfo，可以发现后台还有好多进程啊……
仔细看一眼dumpsys meminfo的输出，可以发现当从xiami切到别的程序之后，xiami被列在了Background分类里，而其他的还有A Services和B Services。xiami占的内存也不少，系统想杀进程的时候，挑大的杀，于是就杀了虾米……

于是首先是这么个问题：既然xiami开了服务，为啥会被扔到Background里去？继续观察，可以发现xiami被杀并重启之后，居然跑到了A Services分类里…… 这样就不会被杀了，问题是音乐也停了……
为了研究到底杀了重启是啥样的过程，我去网上找了个ServiceDemo。实验后发现，对于一个普通程序，就算开了服务，切到后台也是Background。等到内存不够，系统会先杀了你，之后再启动一个进程来仅仅跑服务。这样或许Activity那边的内存就能释放了？一般杀之前不调onDestroy()，杀完重启的时候调onCreate()和onStart()。所以要适应这种情况，可以在onStart()里处理被杀了重启的情况，并且继续之前的工作。

但是我觉得其他音乐播放器不是这样啊…… 于是随便找了个音乐播放器，开了之后切到别的程序，再看meminfo。这样可以注意到，那个程序并没有被扔到Background里，而是在Perceptible里面……
于是去网上看啥样的程序会变成Perceptible。虽然找到了ActivityManager里面IMPORTANCE_PERCEPTIBLE这个常数定义，但是没有哪儿告诉我咋样可以变成Perceptible。
既然这样…… 只能看代码了。正好机子上有之前下下来的Android 4.0代码，在里面找PERCEPTIBLE，于是在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java里面找着了。
貌似成为PERCEPTIBLE的条件是，某调整值>=PERCEPTIBLE_APP_ADJ。但是继续看代码，发现这个调整值会因为各种理由而决定……
通过继续研究dumpsys，发现还可以dump别的，例如dumpsys activity就可以dump出activitymanager这边的信息。在这个信息中，就包括了调整值设置的原因。观察那个靠谱的音乐播放器，发现他Perceptible的理由是foreground-service。

其实如果熟悉Android Service的话，或许已经知道这是啥了。但是我不太熟嘛…… 继续看ActivityManagerService，发现这个原因的触发条件是有foregroundServices，而这个值唯一会变成true的地方只有updateServiceForegroundLocked(true)。而这个东西会在setServiceForeground()里被调用。这个东西貌似只有外部引用。到这里我终于跑到网上去搜foreground service…… 发现Service类有个startForeground()方法，那基本上就是这个了……

根据Android的描述，普通Service还是会被干掉的，只是日后由内存了可能会重开你。但是Foreground Service是这种只要你一干掉用户立马会有反应的，所以会尽可能不去干他。
我在ServiceDemo里加了startForeground()调用，果然他也成了Perceptible，咋样都没被干掉……
那，虾米是不是没有调用这个startForeground()呢？我跑去搞了个最近看见的Android反编译器，ded，是PSU的人做的…… 反编译出来，貌似的确没有startForeground()。但是有一个对setForeground()的调用，可惜是false。另外，在新版Android里，setForeground()已经没用了……

这样就知道是虾米写得烂了，我试了几个音乐播放器，都会变成foreground service…… 不过倒是有个也败了的，那就是豆瓣……
既然如此嘛，要不改虾米，要不改系统。我尝试修改了/proc//oom_adj，但是貌似系统不care这个。我尝试修改了/sys/modules/lowmemorykiller/parameters/minfree，改小了点，希望系统不要没事情杀进程。但是问题依旧，而且chrome启动还更卡了……
那只好改虾米。那个ded貌似反编译有些问题，编译回去也不太行。上网上找找apk反编译，找到了apktool。
这个东西能够把apk完整的反编译成dalvik VM的汇编码，还能编译回去，真是不错……

于是反编译出来，找合适的地方加。因为startForeground()还需要提供一个Notification，而虾米本身就会显示Notification，我希望最好还是用虾米原来的。
找了一下，发现虾米的Notification都是NotificationsUtil管的。里面有个notifyOnGoing()，貌似就是显示平时歌曲信息那个Notification的。于是我篡改了NotificationsUtil.notifyOnGoing()里面显示Notification那句。startForeground()是Service类的函数，需要Service对象，正好MusicPlayService被传了进来，于是我直接把

    invoke-virtual {v2, p3, v3}, Landroid/app/NotificationManager;->notify(ILandroid/app/Notification;)V

改成了

    invoke-virtual {p0, p3, v3}, Lcom/xiami/service/MusicPlayService;->startForeground(ILandroid/app/Notification;)V

其中，p0是函数第0个参数，v2, v3都是dalvik的寄存器。恰好notify()的参数含义和startForeground()匹配，我就直接用了……

用apktool再打包，签名，装进去…… 挂了，说verify失败：Context类对象不是MusicPlayService……
其实是因为MusicPlayService作为p0传进来的时候进行了向上转换，变成了Context对象，直接在上面调MusicPlayService的方法是不行的……
往上看几行，看见一个到NotificationManager的类型转换。恰好我拿来用：把

    check-cast v2, Landroid/app/NotificationManager;

改成

    check-cast p0, Lcom/xiami/service/MusicPlayService;

再打包扔进去，居然就好了…… 而且com.xiami也是Perceptible的了！试了一下，咋搞都没被杀掉，看来是搞成了。

总结
1. 如果是需要一直活着的服务，例如音乐播放器，那么要调用startForeground()。或者好好处理onStart()。 另外，setForeground()已经没用了，源代码里就是个空函数，还附带一堆comment说为啥弄成了空的。
2. 虾米的Android版很烂，本来就觉得听电台听个10首就开始循环就令人不爽了，还有这种毛病。 源代码里还随处可见调试信息拼写错误，当然，这是另外的事情了。
3. Android的反编译/编译很简单，工具也易于获得。基于寄存器的dalvik VM的汇编很容易理解，也很容易改。看来改一下打个病毒或者广告进去也很容易，而且貌似已经有人这么干了。
4. 我仍旧觉得，虽说符合说明，但是含有Service的进程优先级还是应该比普通的高一些的，不应该杀进程的时候和别的进程一样对待。 貌似我老手机上的CM7就会区分？如果Android能改改倒是不错。
5. dumpsys功能强大，貌似还有很多没发现的功能。直接运行能出来好多好多东西。

PS. 我发了之后，xiami那边说下个版本就会修这个…… 所以就不提供修改版了……
PPS. 我觉得一时半会下个版本出不来。 115网盘

忘了重定向stderr导致的某问题

最近某python程序常常抛exception。而且比较神奇的是，貌似这个exception是一层层抛出来的。
先是最内层except块打的log，然后是次外层，然后是再外面……
我本来写的代码并不会重抛异常，所以这很神奇……
except块大约是这样的：

except Exception as e:
    Log.error("send error: %r" % e)
    traceback.print_exc()

能看见第一行的log，但是之后print_exc()的结果就没了。下一行log是更外面的except块的log……

于是这个大概就是print_exc()抛的异常，但是这个东西能抛啥……
之后想了一下，就算是异常一路抛到最外面，也应该有个backtrace，而log里啥都没有……
想想backtrace是打到stderr的，难道stderr没有重定向……
之后再看了一眼，log是打到stdout的…… 再去看启动python程序的脚本，貌似只重定向了stdout，忘了重定向stderr了……

难道断了的stderr不能写？我又写了个小程序ssh到服务器上跑：

#!/usr/bin/env python
 
import sys
import time
 
time.sleep(10)
 
try:
    sys.stderr.write('test\n')
except Exception as e:
    print "Exception: %r" % e

用

python test.py > tmp.txt &

跑，跑起来就断ssh。过会上去一看，果然出了个Exception，IOError(5, ‘Input/Output error’)……

到这儿差不多就弄清楚了。因为我是ssh到服务器跑程序，所以弄了个脚本重定向输出的log文件里。、
但是脚本写错了，没有重定向stderr。所以stderr接到了console上。
等我把ssh一断，stderr另一头就断了。
过了若干时间之后，程序出了个exception。在print_exc()的时候，程序尝试写stderr。但是因为stderr挂了，抛了个IOError。
因为每层except都调了print_exc()，每层都抛出了个新的IOError给下一层……
于是就一路抛到了最外面……

既然知道了就好修。
首先嘛，自然要修正脚本，把stderr一起重定向了。
其次嘛，虽说不是必要，不用print_exc()转而用format_exc()然后扔给Log.error()了。
理论上log都应该直接打到文件，或者至少错误类消息应该打到stderr去。不过反正是服务器程序，stdout也没啥用，再说……

当然，这些都没修正根本问题。其实最初的exception是意料之中的，不过还是应该修正一下让它不抛才是……

Android 3.0+的MTP，以及USB debugging

Android到了3.0+有个地方特别弱智，就是USB连上显示出来不是U盘设备，而是个MTP设备……

其他系统的MTP问题

首先这个MTP一开始就是Microsoft自己搞出来的东西，主要是Windows Media Player支持这个东西，日后才被USB那啥论坛搞成一种正式的USB类。应该是因为这个，别的系统下的支持都不怎么样。

别的系统基本上都用了libmtp库，而这个库最弱智的地方，就是刚连上的时候，会扫描所有文件做个索引…… 如果只是个音乐播放器可能还好，文件不多，但是现在是一个Android设备，那里边乱七八糟的可多了…… 于是这个索引要做个4,5分钟。想想你插上一个设备，过个四五分钟才能显示内容，那不是很sx么…… Windows下，MTP文件连上后，过一会就可以看见内容了……

读了代码，发现他是自己递归做索引的，而且好多接口函数都会去确保这个索引存在，不在就建出来……
根据MTP的规范，其实每次请求一个目录也就列出它的子文件和子目录。也就是说，按照规范来说，并没有啥一定要一次性拿到所有文件的必要性。看windows那边的实现也可以说明这一点。或许本来它是考虑搞个缓存提高之后速度，但是这个初次访问速度实在不能忍。而且之后访问慢慢建出来索引也可以，没必要非要一开是就建出全部的索引。

但是USB的传输速度又比较快。理论上wifi也很快，但是我拿scp也好ftp也好adb也好，速度都最多1M多，还不清楚哪儿sx了…… 所以还是要想办法搞定这个事情，难道要重写libmtp么……

Win下的MTP问题

于是我想别的系统MTP支持糟糕，Win总该不错吧？于是打开WinXP虚拟机，嘿，这个MTP还没有驱动……

上网查，说要装WMP10，装完还是不行。再查，说可以装WMP11，装完还是不行。再查，说有个MTP Porting Kit的东西，里面有驱动。下下来装好，里里外外翻了一遍，还是没有驱动…… 后来从WMP11的wmfdist11.exe，也就是Window Media Format 11 Runtime那一部分里，翻出来若干inf以及相关文件，貌似是MTP驱动。但是手动指定到这儿，倒好像装上去了，但还是不行……

到此基本没法，上网继续查。在查了好久之后，终于有个地方说可能和USB debugging有关系。遂关掉USB debugging，立马就好了…… 自动装好驱动，啥都能访问。一开，又不成……

继续观察，发现不开的时候，只有一个设备，VID_22B8&PID_70A8。这个设备的兼容类型里包括了USB\MS_COMP_MTP，所以驱动匹配上了。开了之后，这个设备变成了一个复合设备，VID_22B8&PID_70A9，很神奇的就是PID加了一，估计是为了和原来的区别开来。这个东西下有俩子设备，VID_22B8&PID_70A9&MI_00和VID_22B8&PID_70A9&MI_01。后一个在装了Moto的驱动之后，显示出来是个ADB设备，也就是USB debugging用的…… 前一个名称是MTP，估计就是MTP设备，但是兼容类型里没有USB\MS_COMP_MTP！于是驱动挂不上…… 就弱智了……

解决方法其实很简单，只要改windows\inf下的wpdmtp.inf，在匹配段里面，在

%GenericMTP.DeviceDesc%=MTP, USB\MS_COMP_MTP

之后，加上

%GenericMTP.DeviceDesc%=MTP, USB\VID_22B8&PID_70A9&MI_00

，一切都搞定了……

于是我很难理解，到底是哪里脑残了导致开了USB debugging就不说自己是MTP设备了…… 蛋疼啊……

为啥Google要用MTP……

虽说Google那边说MTP有诸多好处，例如提高了抽象层次，使得一个文件对Android和电脑都可见啦之类（老的方式系统看见了一大块数据，里面有几个分区，所以如果允许两边都看见，那只要有改动，就会导致元数据不一致…… 新的方法等于系统看见了一堆抽象的文件和目录等，所以所有操作都要告诉那边才能做…… Android那边维持着一致性……），但是选MTP这个标准真是蛋疼，你大不了Google自己搞一套+开源实现也不难啊！MTP就不是给你做任意类型文件传输的么！

bug备忘

今儿搞定了俩bug，系统能正常通过test suite了，备忘一下。
1. 拷贝构造器漏拷了某field
这个的确很弱智…… 但是拷贝构造器在每次增减field的时候都要手动改，这个真麻烦……
就不能提供一个只要我没动的都自动拷一遍的拷贝构造器么……

2. 拷贝构造器中，成员变量中的父指针没有指向新对象
简单来说，就是

class A;
class B {
  A *parent;
};
class A {
  B b;
}

A在拷贝的时候，应该吧b这个成员的parent指针指向新的A……

A::A(const A& other)
: b(other.b) ...
{
 ...
  b.setParent(this);
 ...
}

不过实际上好像父指针不是一个好的模式？但是不用这个用啥呢…… 或者就注意点吧……