joy keeps flowin’ - 什么都想写点
ADB SERVICES
说明 # 网上太多文章写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 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 This file tries to document all requests a client can make to the ADB server of an adbd daemon. See the OVERVIEW.TXT document to understand what's going on here. HOST SERVICES: host:version Ask the ADB server for its internal version number. host:kill Ask the ADB server to quit immediately. This is used when the ADB client detects that an obsolete server is running after an upgrade. host:devices host:devices-l Ask to return the list of available Android devices and their state. devices-l includes the device paths in the state. After the OKAY, this is followed by a 4-byte hex len, and a string that will be dumped as-is by the client, then the connection is closed host:track-devices This is a variant of host:devices which doesn't close the connection. Instead, a new device list description is sent each time a device is added/removed or the state of a given device changes (hex4 + content). This allows tools like DDMS to track the state of connected devices in real-time without polling the server repeatedly. host:emulator:<port> This is a special query that is sent to the ADB server when a new emulator starts up. <port> is a decimal number corresponding to the emulator's ADB control port, i.e. the TCP port that the emulator will forward automatically to the adbd daemon running in the emulator system. This mechanism allows the ADB server to know when new emulator instances start. host:transport:<serial-number> Ask to switch the connection to the device/emulator identified by <serial-number>. After the OKAY response, every client request will be sent directly to the adbd daemon running on the device. (Used to implement the -s option) host:transport-usb Ask to switch the connection to one device connected through USB to the host machine. This will fail if there are more than one such devices. (Used to implement the -d convenience option) host:transport-local Ask to switch the connection to one emulator connected through TCP. This will fail if there is more than one such emulator instance running. (Used to implement the -e convenience option) host:transport-any Another host:transport variant. Ask to switch the connection to either the device or emulator connect to/running on the host. Will fail if there is more than one such device/emulator available. (Used when neither -s, -d or -e are provided) host-serial:<serial-number>:<request> This is a special form of query, where the 'host-serial:<serial-number>:' prefix can be used to indicate that the client is asking the ADB server for information related to a specific device. <request> can be in one of the format described below. host-usb:<request> A variant of host-serial used to target the single USB device connected to the host. This will fail if there is none or more than one. host-local:<request> A variant of host-serial used to target the single emulator instance running on the host. This will fail if there is none or more than one. host:<request> When asking for information related to a device, 'host:' can also be interpreted as 'any single device or emulator connected to/running on the host'. <host-prefix>:get-product XXX <host-prefix>:get-serialno Returns the serial number of the corresponding device/emulator. Note that emulator serial numbers are of the form "emulator-5554" <host-prefix>:get-devpath Returns the device path of the corresponding device/emulator. <host-prefix>:get-state Returns the state of a given device as a string. <host-prefix>:forward:<local>;<remote> Asks the ADB server to forward local connections from <local> to the <remote> address on a given device. There, <host-prefix> can be one of the host-serial/host-usb/host-local/host prefixes as described previously and indicates which device/emulator to target. the format of <local> is one of: tcp:<port> -> TCP connection on localhost:<port> local:<path> -> Unix local domain socket on <path> the format of <remote> is one of: tcp:<port> -> TCP localhost:<port> on device local:<path> -> Unix local domain socket on device jdwp:<pid> -> JDWP thread on VM process <pid> vsock:<CID>:<port> -> vsock on the given CID and port or even any one of the local services described below. <host-prefix>:forward:norebind:<local>;<remote> Same as <host-prefix>:forward:<local>;<remote> except that it will fail it there is already a forward connection from <local>. Used to implement 'adb forward --no-rebind <local> <remote>' <host-prefix>:killforward:<local> Remove any existing forward local connection from <local>. This is used to implement 'adb forward --remove <local>' <host-prefix>:killforward-all Remove all forward network connections. This is used to implement 'adb forward --remove-all'. <host-prefix>:list-forward List all existing forward connections from this server. This returns something that looks like the following: <hex4>: The length of the payload, as 4 hexadecimal chars. <payload>: A series of lines of the following format: <serial> " " <local> " " <remote> "\n" Where <serial> is a device serial number. <local> is the host-specific endpoint (e.g. tcp:9000). <remote> is the device-specific endpoint. Used to implement 'adb forward --list'. LOCAL SERVICES: All the queries below assumed that you already switched the transport to a real device, or that you have used a query prefix as described above. shell:command arg1 arg2 ... Run 'command arg1 arg2 ...' in a shell on the device, and return its output and error streams. Note that arguments must be separated by spaces. If an argument contains a space, it must be quoted with double-quotes. Arguments cannot contain double quotes or things will go very wrong. Note that this is the non-interactive version of "adb shell" shell: Start an interactive shell session on the device. Redirect stdin/stdout/stderr as appropriate. Note that the ADB server uses this to implement "adb shell", but will also cook the input before sending it to the device (see interactive_shell() in commandline.c) remount: Ask adbd to remount the device's filesystem in read-write mode, instead of read-only. This is usually necessary before performing an "adb sync" or "adb push" request. This request may not succeed on certain builds which do not allow that. tcp:<port> Tries to connect to tcp port <port> on localhost. tcp:<port>:<server-name> Tries to connect to tcp port <port> on machine <server-name> from the device. This can be useful to debug some networking/proxy issues that can only be revealed on the device itself. local:<path> Tries to connect to a Unix domain socket <path> on the device localreserved:<path> localabstract:<path> localfilesystem:<path> Variants of local:<path> that are used to access other Android socket namespaces. framebuffer: This service is used to send snapshots of the framebuffer to a client. It requires sufficient privileges but works as follow: After the OKAY, the service sends 16-byte binary structure containing the following fields (little-endian format): depth: uint32_t: framebuffer depth size: uint32_t: framebuffer size in bytes width: uint32_t: framebuffer width in pixels height: uint32_t: framebuffer height in pixels With the current implementation, depth is always 16, and size is always width*height*2 Then, each time the client wants a snapshot, it should send one byte through the channel, which will trigger the service to send it 'size' bytes of framebuffer data. If the adbd daemon doesn't have sufficient privileges to open the framebuffer device, the connection is simply closed immediately. jdwp:<pid> Connects to the JDWP thread running in the VM of process <pid>. track-jdwp This is used to send the list of JDWP pids periodically to the client. The format of the returned data is the following: <hex4>: the length of all content as a 4-char hexadecimal string <content>: a series of ASCII lines of the following format: <pid> "\n" This service is used by DDMS to know which debuggable processes are running on the device/emulator. Note that there is no single-shot service to retrieve the list only once. sync: This starts the file synchronization service, used to implement "adb push" and "adb pull". Since this service is pretty complex, it will be detailed in a companion document named SYNC.TXT reverse:<forward-command> This implements the 'adb reverse' feature, i.e. the ability to reverse socket connections from a device to the host. <forward-command> is one of the forwarding commands that are described above, as in: list-forward forward:<local>;<remote> forward:norebind:<local>;<remote> killforward-all killforward:<local> Note that in this case, <local> corresponds to the socket on the device and <remote> corresponds to the socket on the host. The output of reverse:list-forward is the same as host:list-forward except that <serial> will be just 'host'.
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阅读软件）上配置不了，记录一下。