Pixel C 也鼓起来了

前两天突然发现,我平时插着电当时钟的 Pixel C 也鼓起来了。具体来说,屏幕隆起来,和背壳中间有了条缝: 看见这个,作为一个已经鼓了两个平板一个手表的人,我迅速做出判断:又一个平板的电池鼓起来了…… 我想能不能拆掉电池,就插电继续当时钟。然而这货并不好拆,iFixit 做过一个拆解,屏幕是用一圈胶黏在背壳(铝合金)上面的,硬掰的话,很容易掰坏屏幕(毕竟是一块玻璃)。 听说点吹风加热能好弄一点,于是我也试了一把,感觉有那么点效果。在拿一个塑料片子折腾了半天之后,终于把鼓得厉害的两条边分离了: 然后继续拿塑料片划拉。屏幕和背壳之间那个胶可以慢慢蹭掉,每次划开一点。因为电池鼓着,所以划开之后基本就不会再合起来了。 蹭了很久之后,终于完全蹭开来了。分开之后是这个样子(有俩排线): 断电之后,下一个问题就是咋拆掉电池。iFixit 的拆解都没拆电池,因为实在是粘得太牢。我拿了几张过期银行卡之类的在底下死命往里划拉,慢慢的还是把电池和背壳分离了开来。最后就是这个样子: 然后插电,发现大功率充电器能够启动到fastboot,然而不能进系统;小功率的根本不亮。简单来说,没电池看来不太行…… 去网上看了眼,很少有卖这个电池的,大概三十一份,倒是不算贵。然而这货我基本也是吃灰状态,买来也没啥用。另外,根据之前 Nexus 7 2013的经验,买来的电池很快也会鼓…… 于是先暂时放着了。不知道这个显示面板能不能插到别的啥上面用用,比如这个 Pine64 之类的。 总的来说,我已经鼓了3个平板了:Pixel 7 2013,Surface Pro 4,以及 Pixel C。Surface Pro 4 微软给换了一个,到目前为止还没鼓起来。Pixel 7 2013 我倒是换过电池,然而没多久又鼓了。 这个 Pixel C 是 2016 年初买的,到现在差不多是4年。看了眼之前的blog,Nexus 7 是2017年买的,差不多也是4年。看来这种平板电池寿命就是4年,如果一直插在上面的话。Surface Pro 4 是18年鼓起来的,16年8月买的,看来是特别不行…… 可能和这货很容易温度特别高(这是个i7……)有关系…… 网上说鼓起来基本是过充,虽然这些电池应该都有智能保护电路,估计一直插着就有这个问题。这样来看,不用的平板一直插着并不是啥好主意。这样的话,需要一直插着电的东西,还是选没电池的比较好。 看了眼现在当媒体播放器的 Pixel Slate,感觉也很危险,看来要考虑换一个设备当播放器了…… 其实我还有个 NVIDIA Shield,然而这货那个 Android TV 并不好用,不如 …

Continue reading ‘Pixel C 也鼓起来了’ »

多设备蓝牙键盘

这东西倒也没啥新鲜的,罗技基本上现在每个都有这个功能。然而家里键盘并不想换,反正还有个扔着没用的 Pine64,就考虑结合一下变成多设备蓝牙键盘…… 输入嘛就靠libinput。这年头拿个输入还是很方便的,拿python的wrapper随便折腾折腾就有了。 蓝牙比较麻烦。本身蓝牙就比较复杂,要先搞 SDP 记录然后再接收连接。参考了网上直接模拟蓝牙键盘的代码,改改 HID 描述符加上鼠标,加上接收多个连接的功能,搞个快捷键切换设备,也就差不多了。 蓝牙键盘鼠标和 USB 的那套差不多,就是 HID 套个壳。这个倒是比较简单,之前也研究过 HID 描述符和 HID 报告的格式,随便折腾一下就能发送报告了。然而被 Python 3 的 bytes/str 坑了一波,最后发现 0xa1 发送成了 0xc2 0xa1 才注意到这个问题…… 目前倒是折腾到能用,然而蓝牙那块还是有一些诡异的问题。比如说,Android 和 Linux 经常连不上来,看上去 bluez 这边发送的回复是说 Connection pending, Authentication pending,过一会就 fail 了,然而有时候又能跑,还需要更多研究…… 至于为啥不直接用 synergy 或者远程跑个服务器然后发数据嘛…… 因为毕竟蓝牙比较通用,远程不需要啥设置,以及折腾折腾比较好玩…… 说起来折腾这货还发现了奇妙的bug。只要(不)恰当地设置 SDP 记录,Windows一连上就会蓝屏…… KERNEL_SECRUITY_CHECK_EXCEPTION来着。 https://github.com/HenryHu/bthub/tree/master/src

关于一堆可疑的SNMP包

很久以前,我系的CRF(管理计算机资源的)来找过我,说我机子被黑了。我观察之后没啥症状,就问他们为啥那么说。 他们拿出来一个单子,说你机子往外发可疑的包,只有被黑了才发这种包。 我看了一眼,貌似我的机子在广播SNMP包。我觉得这事情也不是那么奇怪,毕竟一堆程序依赖snmp库,但是他们觉得有问题。 于是我在防火墙加了个规则,说如果有这种包就记录一下并且扔掉。其他还干了很多事情,例如换私钥之类,总之很麻烦。之后,他们就不来找我了…… 系统里的确偶尔会记录下这种包的发送记录。那时候尝试看了一眼,没看出为啥,也就没有管。 过了很久之后,一天我看着这些记录,觉得很烦躁,想着干脆研究清楚为啥会发这些破包。 首先,那些个记录里记录了发包者的UID。在我的机子上,记录的UID是colord的UID。 colord是啥呢?可以参见http://www.freedesktop.org/software/colord/intro.html。基本上是个管理色彩配置的东西,如果你不是特别关心你颜色显示得是否准确,其实有没有都无所谓。 colord发SNMP包还是很难让人理解。ldd看一眼,发现colord并没有链接libnetsnmp,net-snmp也不是他的依赖。 观察一下colord的依赖,其他貌似都挺无辜,但是有个可选依赖是sane。我机子上恰好也装了sane。 sane是啥呢?参见http://www.sane-project.org/,Scanner Access Now Easy(这Now是硬插进去的吧!),是个管扫描仪的东西。 sane倒是依赖net-snmp,所以多半是它干的好事。 之后把colord和sane代码扒下来看一眼,大概知道是怎么回事情了。 说colord有个sane插件,嘛大概扫描仪也需要色彩配置。这个插件会启动一个叫colord-sane的程序,这个程序链接到了libsane。sane有个插件叫magicolor,管理Konika Minolta的一个系列的扫描仪。 colord因为某些原因要更新设备列表,于是调进那个插件。插件启动colord-sane,导致sane也让他的插件们更新设备列表。那个magicolor系列扫描仪估计比较高级,能够联网。magicolor插件更新设备列表就去群发SNMP包,在本地网上找这个扫描仪。这个包被CRF看见了…… 其实也怪那个SNMP请求范围太广。他发的SNMP包基本上就是让本地所有的SNMP设备向他报告自己是啥设备,有啥功能之类。这看上去当然挺危险…… 最后说这个过程是怎么触发的。在开始打记录之后,我发现当我插拔手机/平板的时候,那个记录会一起出现。这种事情很容易联想到UDEV,sane和colord其实都装了UDEV规则,而这里引起问题的是colord的规则。那个规则说,只要USB设备插入/拔出,并且有gphoto支持,就给colord发个通知。Android的手机/平板当然在这个范围,于是引发了一系列事件,最后SNMP包就发出去了…… 总体现象是你插拔手机会发SNMP包,谁知道里面有这么一个过程…… 如果有个工具,能够告诉他触发条件和结果,问他中间的因果关系,倒是会方便不少。好像也不是搞不出来,不过貌似没啥学术价值……

在bsd上跑ndk-build

bsd一直是个官方不咋支持的Android开发平台…… 不过靠着linux兼容层,还是可以混混的…… 首先是ndk-build会报不支持的os(FreeBSD)和arch(amd64),而且ndk-build并不会使用环境变量里定义的值。所以有两个办法: 1. 直接调用gmake env HOST_OS=linux HOST_ARCH=x86 gmake -f $NDK_DIR/build/core/build-local.mk 这样啥都不用改。 2. 修改ndk-build 把HOST_OS设置成linux,HOST_ARCH设置成x86,并且export出来。 再把GNUMAKE设置成gmake,否则会调自带的linux版gmake导致一些麻烦的事情…… 然后直接跑就行了。 跑了之后会碰到一个问题:ld会segmentation fault。看系统log可能是因为fallocate和fstatfs64系统调用没有实现的关系。 解决办法是,到ndk目录里的toolchains/*/prebuilt/linux-x86/…/bin/,如果有ld.gold,那把老的ld干掉,改成到ld.bfd的符号链接。老的ld就是ld.gold…… 其实就是gold那个新的ld调了一些新的bsd还没实现的linux的system call…… 用老的bfd里的ld就没事了……

Xoom更新4.1.1

之前听说Android 4.1.1在Xoom上公开测试了,昨儿听说已经OTA了,于是去系统设置里检查更新,没有…… 去网上看,说可以清除Google Service Framework的数据再试。试了一次,果然刷出来一个更新,4.1.1的。Google这是故意的么…… 下完之后,更新,刚过百分之十几,就成了个倒了的Android的样子,上面还有个红色三角。 根据经验,反正是升级败了。重启,去/cache,发现recovery目录里有last_log。看最后说啥验证失败。 E: failed to verify whole-file signature E: signature verification failed Installation aborted 我一开始以为是更新包验证败了,但是弄到电脑上,能正常解开……(更新包就在/cache里,一个zip) 那估计和上次一样,因为这是个补丁包,所以要先验证源文件正确,才能打补丁,而某些文件可能被改过了,在Root或者别的时候。 这时候我想起来,上次见到过一个叫OTA RootKeeper的东西,可以在更新后保留Root,就去装了一个,打开之后,选保留Root以及暂时unroot。 然后重启到EOS Recovery,尝试装那个zip,果然有apply_patch_check失败的,首先是/system/bin/gzip。进去一看,貌似被改成了到busybox的链接…… 大约是哪个busybox安装器干的好事。从网上下了一个4.0.4的完整镜像,从里面扒出gzip换掉系统里那个符号链接,再试,这次换成了ip。重复操作,搞定了ping和toolbox之后,这次是boot分区校验和挂了…… 重启到fastboot,刷那个4.0.4镜像里的,再更新,还是不行…… 想想大概是4.0.4那个镜像的boot改过了,去下载的地方,发现是root过的镜像…… 搜了一圈,就是找不到没root过的4.0.4 boot分区。 网上的恢复办法都是刷回3.x然后一路更新上来,好像很麻烦…… 我想,可以弄来3.x的boot.img和之后所有的补丁,一路打上来,弄到一个4.0.4的boot.img,再刷进去…… 在xda的http://forum.xda-developers.com/showthread.php?t=1597609这个帖子里有个网站,里面有3.0.1的原始镜像和所有升级包。把镜像里的boot.img和升级包里的所有boot.img.p扒出来,然后就是咋打补丁的问题了。 我记得android里有applypatch,于是去android source里面找,果然有这个东西。尝试编译一份主机可用的,居然成功了,命令如下: 在applypatch目录里 gcc utils.c imgpatch.c bspatch.c freecache.c bsdiff.c main.c applypatch.c -o applypatch -I../../../system/core/include/ -I../ ../minelf/Retouch.c -lbz2 -lz ../../bootloader/legacy/libc/sha.c ../mtdutils/mtdutils.c 然后跑,发现命令格式挺简单,就是 applypatch …

Continue reading ‘Xoom更新4.1.1’ »