joy keeps flowin’ - 什么都想写点
ADB README
说明 # 网上太多文章写ADB，不尽详细，大多一知半解，干脆找来官方文件。 你最好按照下面的顺序阅读： adb overview adb readme adb service adb protocol 三篇都是复制自AOSP13源码，无修改，请放心阅读。 原文 # ADB Internals # If you are new to adb source code, you should start by reading OVERVIEW.TXT which describes the three components of adb pipeline.
ADB OVERVIEW
说明 # 网上太多文章写ADB，不尽详细，大多一知半解，干脆找来官方文件。 你最好按照下面的顺序阅读： adb overview adb readme adb service adb protocol 三篇都是复制自AOSP13源码，无修改，请放心阅读。 原文 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 Implementation notes regarding ADB. I. General Overview: The Android Debug Bridge (ADB) is used to: * keep track of all Android devices and emulators instances connected to or running on a given host developer machine * implement various control commands (e.g. "adb shell", "adb pull", etc.) for the benefit of clients (command-line users, or helper programs like DDMS). These commands are called 'services' in ADB. As a whole, everything works through the following components: 1. The ADB server This is a background process that runs on the host machine. Its purpose is to sense the USB ports to know when devices are attached/removed, as well as when emulator instances start/stop. It thus maintains a list of "connected devices" and assigns a 'state' to each one of them: OFFLINE, BOOTLOADER, RECOVERY or ONLINE (more on this below). The ADB server is really one giant multiplexing loop whose purpose is to orchestrate the exchange of data (packets, really) between clients, services and devices. 2. The ADB daemon (adbd) The 'adbd' program runs as a background process within an Android device or emulated system. Its purpose is to connect to the ADB server (through USB for devices, through TCP for emulators) and provide a few services for clients that run on the host. The ADB server considers that a device is ONLINE when it has successfully connected to the adbd program within it. Otherwise, the device is OFFLINE, meaning that the ADB server detected a new device/emulator, but could not connect to the adbd daemon. The BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode. 3. The ADB command-line client The 'adb' command-line program is used to run adb commands from a shell or a script. It first tries to locate the ADB server on the host machine, and will start one automatically if none is found. Then, the client sends its service requests to the ADB server. Currently, a single 'adb' binary is used for both the server and client. this makes distribution and starting the server easier. 4. Services There are essentially two kinds of services that a client can talk to. Host Services: These services run within the ADB Server and thus do not need to communicate with a device at all. A typical example is "adb devices" that is used to return the list of currently known devices and their states. There are a few other services, though. Local Services: These services either run within the adbd daemon, or are started by it on the device. The ADB server is used to multiplex streams between the client and the service running in adbd. In this case its role is to initiate the connection, then of being a pass-through for the data. II. Protocol details: 1. Client <-> Server protocol: This section details the protocol used between ADB clients and the ADB server itself. The ADB server listens on TCP:localhost:5037. A client sends a request using the following format: 1. A 4-byte hexadecimal string giving the length of the payload 2. Followed by the payload itself. For example, to query the ADB server for its internal version number, the client will do the following: 1. Connect to tcp:localhost:5037 2. Send the string "000Chost:version" to the corresponding socket The 'host:' prefix is used to indicate that the request is addressed to the server itself (we will talk about other kinds of requests later). The content length is encoded in ASCII for easier debugging. The server should answer a request with one of the following: 1. For success, the 4-byte "OKAY" string 2. For failure, the 4-byte "FAIL" string, followed by a 4-byte hex length, followed by a string giving the reason for failure. Note that the connection is still alive after an OKAY, which allows the client to make other requests. But in certain cases, an OKAY will even change the state of the connection. For example, the case of the 'host:transport:<serialnumber>' request, where '<serialnumber>' is used to identify a given device/emulator; after the "OKAY" answer, all further requests made by the client will go directly to the corresponding adbd daemon. The file SERVICES.TXT lists all services currently implemented by ADB. 2. Transports: An ADB transport models a connection between the ADB server and one device or emulator. There are currently two kinds of transports: - USB transports, for physical devices through USB - Local transports, for emulators running on the host, connected to the server through TCP In theory, it should be possible to write a local transport that proxies a connection between an ADB server and a device/emulator connected to/ running on another machine. This hasn't been done yet though. Each transport can carry one or more multiplexed streams between clients and the device/emulator they point to. The ADB server must handle unexpected transport disconnections (e.g. when a device is physically unplugged) properly.
解决系统界面高度变化——WindowInsets
Android开发中，输入框作为最最基础的View之一，使用的频率是非常非常高的。 有输入框的地方就有软键盘，我知道有softinputmode可以设置软键盘弹起的行为，这只能响应软键盘弹起后整个Activity的应对行为。如果我想要拿到软键盘高度呢，这是softinputmode做不到的。你可能已经想到了监听View的变化，得到一个高度值，超过了某个阈值就认为软键盘已经弹起了。没错，这是之前常用的方式，要是我想软键盘高度会改变，怎么办？
软路由安装OpenWrt
软路由机器是一台J4125的小主机，只作为路由器运行。常年运行esir的固件，也是用OpenClash科学上网。大概是DNS设置的有问题，只有在fake ip模式下打开TUN时才能访问网络，挨个查原因估计要更麻烦，索性直接重装。 用人编译好的固件总是不能满足需求，要么是有多余的插件，安装之后从来不打开，要么是安装一个使用频率很高的插件，却只能跟固件一起更新，综合考虑决定安装immortalWrt。好处是内核用原版OpenWrt的，只有核心的插件，其他的根据需要安装。
不要给View加context类型参数
工作的这几年，看见过很多次这种写法，很不爽，想吐槽。 明明View里就有个Context的变量，还要画蛇添足，再加个参数保存Context，这个Context很大概率是Activity。 恐怕是忘了传入View里的这个Context就是Activity本人吧。
Ubuntu编译AOSP
起因 # 网上有这么多相似的文章，还要再写这个的原因有两个： 纸上得来终觉浅。从去年就尝试按着网上的文章编译，总也不能通过，各种各样的问题； 记录一下过程，避免踩相同的坑，也好给其他的朋友一点参考。 准备 # 环境 # 先后尝试过用Windows、Mac编译，推荐直接用Linux，不管是不是Ubuntu。
Mac上制作Window启动盘
周二早上想看硬件有哪些，记得Windows电脑上有个AIDE，费了一顿劲找着，点了电脑直接蓝屏了，再进发现UEFI干没了😅。刚好手头又没有pe启动盘，倒是有U盘和Mac电脑，记录下用Mac制作Windows启动盘的过程。
理解Kotlin协程
记下自己的一点浅薄的理解，想要更深入学习的朋友推荐阅读霍老的破解 Kotlin 协程 使用 # 1 2 3 4 5 6 7 8 9 10 11 12 public fun CoroutineScope.launch( context: CoroutineContext = EmptyCoroutineContext, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> Unit ): Job { val newContext = newCoroutineContext(context) val coroutine = if (start.isLazy) LazyStandaloneCoroutine(newContext, block) else StandaloneCoroutine(newContext, active = true) coroutine.start(start, coroutine, block) return coroutine } 启动时包含三个参数： 协程上下文 启动模式 执行方法 协程上下文 # CoroutineContext中定义了get、plus、minusKey方法。类似list。
FreshRSS api配置
不喜欢新闻客户端里带有政治倾向和无关紧要的娱乐新闻，诸如某某明星跌倒之类。日常都用rss阅读，可以阅读我常看的内容，FreshRSS又是可以自己部署的非常好用的服务，理所当然的用上了。 最近组了一台主机，重新安装FreshRSS之后总是也在reeder（iOS平台RSS阅读软件）上配置不了，记录一下。
Jetpack系列之ViewModel
ViewModel和架构MVVM中的VM（ViewModel）同名，但并不是一个东西，架构中的ViewModel是和View双向绑定的，这里的ViewModel只能做到利用LiveData更新。 为什么用ViewModel呢？一是把网络请求和数据库读取的逻辑从Activity中放到了ViweModel，分担了一部分Activity的压力；另一个原因是可以在Activity或Fragment重建时保存数据，不会丢失。今天探讨的时第二个问题。