joy keeps flowin'

joy keeps flowin’ - 什么都想写点

2024年终总结

2025年01月12日

我没有忘写年终总结，但是忘了去年写在哪，今天才找到。按照惯例总结下去年在各方面，写下新一年的目标。工作 # 23年11月份入职，到元旦一年出头，时间算不上长。与之前相比，感受最明显的还是流程，在上一家需求评审完了就可以开始干活了，在这里才刚开始。到真的开始写需求，需要经过预沟通（和领导们，没我什么事）、需求评审、技术预审、技术内审、技术外审后才是真的开始写代码。这背后的是对风险的把控，时间都是算好的，每一个齿轮都要按照争取的节奏转动。

Context是什么

2025年01月05日

Context是什么？这是从我开始学习Android就有的疑问，刚入行时找了无数的文章，也没有谁能解答我的疑问，有的是不断的告诉我Context是上下文，这不废话吗，我查不到Context的意思是上下文吗？我的意思是什么的上下文。

Android代码混淆

2025年01月05日

在Android应用开发完成，上架前，一般是要经过加固和混淆两个步骤的，加固的原理我不懂，整理了混淆相关的知识和文档。供自己和有需要的朋友查阅。目的 # 一定是有什么作用，否则是不会加入的。混淆的作用是什么呢？

View的焦点

2025年01月04日

本篇内容探讨View的焦点。怎么算有焦点，同一时间有几个View有焦点，焦点的分发又是怎么回事。焦点 # View有个方法叫hasFocus，返回值是boolean类型的，用来判断View是否有焦点。hasFocus只做了简单的一件事，判断flag中是否包含PFLAG_FOCUSED。

ADB protocol

2025年01月04日

说明 # 网上太多文章写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 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 --- a replacement for aproto ------------------------------------------- When it comes down to it, aproto's primary purpose is to forward various streams between the host computer and client device (in either direction). This replacement further simplifies the concept, reducing the protocol to an extremely straightforward model optimized to accomplish the forwarding of these streams and removing additional state or complexity. The host side becomes a simple comms bridge with no "UI", which will be used by either commandline or interactive tools to communicate with a device or emulator that is connected to the bridge. The protocol is designed to be straightforward and well-defined enough that if it needs to be reimplemented in another environment (Java perhaps), there should not problems ensuring perfect interoperability. The protocol discards the layering aproto has and should allow the implementation to be much more robust. --- protocol overview and basics --------------------------------------- The transport layer deals in "messages", which consist of a 24 byte header followed (optionally) by a payload. The header consists of 6 32 bit words which are sent across the wire in little endian format. struct message { unsigned command; /* command identifier constant (A_CNXN, ...) */ unsigned arg0; /* first argument */ unsigned arg1; /* second argument */ unsigned data_length; /* length of payload (0 is allowed) */ unsigned data_crc32; /* crc32 of data payload */ unsigned magic; /* command ^ 0xffffffff */ }; Receipt of an invalid message header, corrupt message payload, or an unrecognized command MUST result in the closing of the remote connection. The protocol depends on shared state and any break in the message stream will result in state getting out of sync. The following sections describe the six defined message types in detail. Their format is COMMAND(arg0, arg1, payload) where the payload is represented by a quoted string or an empty string if none should be sent. The identifiers "local-id" and "remote-id" are always relative to the *sender* of the message, so for a receiver, the meanings are effectively reversed. --- CONNECT(version, maxdata, "system-identity-string") ---------------- Command constant: A_CNXN The CONNECT message establishes the presence of a remote system. The version is used to ensure protocol compatibility and maxdata declares the maximum message body size that the remote system is willing to accept. Currently, version=0x01000000 and maxdata=256*1024. Older versions of adb hard-coded maxdata=4096, so CONNECT and AUTH packets sent to a device must not be larger than that because they're sent before the CONNECT from the device that tells the adb server what maxdata the device can support. Both sides send a CONNECT message when the connection between them is established. Until a CONNECT message is received no other messages may be sent. Any messages received before a CONNECT message MUST be ignored. If a CONNECT message is received with an unknown version or insufficiently large maxdata value, the connection with the other side must be closed. The system identity string should be "<systemtype>:<serialno>:<banner>" where systemtype is "bootloader", "device", or "host", serialno is some kind of unique ID (or empty), and banner is a human-readable version or identifier string. The banner is used to transmit useful properties. --- STLS(type, version, "") -------------------------------------------- Command constant: A_STLS The TLS message informs the recipient that the connection will be encrypted and will need to perform a TLS handshake. version is the current version of the protocol. --- AUTH(type, 0, "data") ---------------------------------------------- Command constant: A_AUTH The AUTH message informs the recipient that authentication is required to connect to the sender. If type is TOKEN(1), data is a random token that the recipient can sign with a private key. The recipient replies with an AUTH packet where type is SIGNATURE(2) and data is the signature. If the signature verification succeeds, the sender replies with a CONNECT packet. If the signature verification fails, the sender replies with a new AUTH packet and a new random token, so that the recipient can retry signing with a different private key. Once the recipient has tried all its private keys, it can reply with an AUTH packet where type is RSAPUBLICKEY(3) and data is the public key. If possible, an on-screen confirmation may be displayed for the user to confirm they want to install the public key on the device. --- OPEN(local-id, 0, "destination") ----------------------------------- Command constant: A_OPEN The OPEN message informs the recipient that the sender has a stream identified by local-id that it wishes to connect to the named destination in the message payload. The local-id may not be zero. The OPEN message MUST result in either a READY message indicating that the connection has been established (and identifying the other end) or a CLOSE message, indicating failure. An OPEN message also implies a READY message sent at the same time. Common destination naming conventions include: * "tcp:<host>:<port>" - host may be omitted to indicate localhost * "udp:<host>:<port>" - host may be omitted to indicate localhost * "vsock:<CID>:<port>" * "local-dgram:<identifier>" * "local-stream:<identifier>" * "shell" - local shell service * "upload" - service for pushing files across (like aproto's /sync) * "fs-bridge" - FUSE protocol filesystem bridge --- READY(local-id, remote-id, "") ------------------------------------- Command constant: A_OKAY The READY message informs the recipient that the sender's stream identified by local-id is ready for write messages and that it is connected to the recipient's stream identified by remote-id. Neither the local-id nor the remote-id may be zero. A READY message containing a remote-id which does not map to an open stream on the recipient's side is ignored. The stream may have been closed while this message was in-flight. The local-id is ignored on all but the first READY message (where it is used to establish the connection). Nonetheless, the local-id MUST not change on later READY messages sent to the same stream. --- WRITE(local-id, remote-id, "data") --------------------------------- Command constant: A_WRTE The WRITE message sends data to the recipient's stream identified by remote-id. The payload MUST be <= maxdata in length. A WRITE message containing a remote-id which does not map to an open stream on the recipient's side is ignored. The stream may have been closed while this message was in-flight. A WRITE message may not be sent until a READY message is received. Once a WRITE message is sent, an additional WRITE message may not be sent until another READY message has been received. Recipients of a WRITE message that is in violation of this requirement will CLOSE the connection. --- CLOSE(local-id, remote-id, "") ------------------------------------- Command constant: A_CLSE The CLOSE message informs recipient that the connection between the sender's stream (local-id) and the recipient's stream (remote-id) is broken. The remote-id MUST not be zero, but the local-id MAY be zero if this CLOSE indicates a failed OPEN. A CLOSE message containing a remote-id which does not map to an open stream on the recipient's side is ignored. The stream may have already been closed by the recipient while this message was in-flight. The recipient should not respond to a CLOSE message in any way. The recipient should cancel pending WRITEs or CLOSEs, but this is not a requirement, since they will be ignored. --- SYNC(online, sequence, "") ----------------------------------------- Command constant: A_SYNC *** obsolete, no longer used *** The SYNC message was used by the io pump to make sure that stale outbound messages are discarded when the connection to the remote side is broken. It was only used internally to the bridge and never valid to send across the wire. * when the connection to the remote side goes offline, the io pump sends a SYNC(0, 0) and starts discarding all messages * when the connection to the remote side is established, the io pump sends a SYNC(1, token) and continues to discard messages * when the io pump receives a matching SYNC(1, token), it once again starts accepting messages to forward to the remote side --- message command constants ------------------------------------------ #define A_SYNC 0x434e5953 #define A_CNXN 0x4e584e43 #define A_AUTH 0x48545541 #define A_OPEN 0x4e45504f #define A_OKAY 0x59414b4f #define A_CLSE 0x45534c43 #define A_WRTE 0x45545257 #define A_STLS 0x534C5453 --- implementation details --------------------------------------------- The core of the bridge program will use three threads. One thread will be a select/epoll loop to handle io between various inbound and outbound connections and the connection to the remote side. The remote side connection will be implemented as two threads (one for reading, one for writing) and a datagram socketpair to provide the channel between the main select/epoll thread and the remote connection threadpair. The reason for this is that for usb connections, the kernel interface on linux and osx does not allow you to do meaningful nonblocking IO. The endian swapping for the message headers will happen (as needed) in the remote connection threadpair and that the rest of the program will always treat message header values as native-endian. The bridge program will be able to have a number of mini-servers compiled in. They will be published under known names (examples "shell", "fs-bridge", etc) and upon receiving an OPEN() to such a service, the bridge program will create a stream socketpair and spawn a thread or subprocess to handle the io. --- simplified / embedded implementation ------------------------------- For limited environments, like the bootloader, it is allowable to support a smaller, fixed number of channels using pre-assigned channel ID numbers such that only one stream may be connected to a bootloader endpoint at any given time. The protocol remains unchanged, but the "embedded" version of it is less dynamic. The bootloader will support two streams. A "bootloader:debug" stream, which may be opened to get debug messages from the bootloader and a "bootloader:control", stream which will support the set of basic bootloader commands. Example command stream dialogues: "flash_kernel,2515049,........\n" "okay\n" "flash_ramdisk,5038,........\n" "fail,flash write error\n" "bogus_command......" <CLOSE> --- future expansion --------------------------------------------------- I plan on providing either a message or a special control stream so that the client device could ask the host computer to setup inbound socket translations on the fly on behalf of the client device. The initial design does handshaking to provide flow control, with a message flow that looks like: >OPEN <READY >WRITE <READY >WRITE <READY >WRITE <CLOSE The far side may choose to issue the READY message as soon as it receives a WRITE or it may defer the READY until the write to the local stream succeeds. A future version may want to do some level of windowing where multiple WRITEs may be sent without requiring individual READY acks. ------------------------------------------------------------------------ --- smartsockets ------------------------------------------------------- Port 5037 is used for smart sockets which allow a client on the host side to request access to a service in the host adb daemon or in the remote (device) daemon. The service is requested by ascii name, preceeded by a 4 digit hex length. Upon successful connection an "OKAY" response is sent, otherwise a "FAIL" message is returned. Once connected the client is talking to that (remote or local) service. client: <hex4> <service-name> server: "OKAY" client: <hex4> <service-name> server: "FAIL" <hex4> <reason>

ADB SERVICES

2025年01月04日

说明 # 网上太多文章写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

2025年01月04日

说明 # 网上太多文章写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.

joy keeps flowin'

2024年终总结

Context是什么

Android代码混淆

View的焦点

ADB protocol

ADB SERVICES

ADB README

ADB OVERVIEW

解决系统界面高度变化——WindowInsets

软路由安装OpenWrt