joy keeps flowin'

joy keeps flowin’ - 什么都想写点

Android WebView addJavaScriptInterface的实现

在工作中有和前端混合开发的项目（前端的代码运行在Webview中），混合开发涉及到前端和客户端之间方法的调用，花了点时间弄明白是实现调用的。 实现 # 我们都知道是通过WebView的addJavaScript方法将Android的方法添加进Webview，之后前端才可以调用到的，因此入口从它开始。

Android插件化

12年我还在上初中，AndroidDynamicLoader已经只吃了Fragment的插件化实现。之后不断演变，从dynamic-load-apk，到DroidPlugin，再到Atlas。 说来惭愧，时至今日才有机会接触到，不禁想一探究竟。

Serializable和Parcelable

从开始学习Android，到现在看过很多次有人争论Android为什么用Parcelable，而不是Java提供的Serializable接口。 除了使用两者的方式不同外，国内（大陆）目前最普遍的观点是认为Serializable用了大量的反射，导致速度要比Parcelable慢。

Mac终端中使用VS Code打开文件

最近排查ANR日志，用grep找到包含特定内容的日志后，还要找文件在哪再打开，觉得很繁琐，简单搜了下，还有平时常用的命令，一并记录下来以便后续用到查找。 1 2 3 4 5 6 7 8 9 10 11 # 用特定软件打开某个文件 open -a "软件名称" path/file # finder中打开当前文件夹 open . # grep递归匹配特定内容 grep -r "特定内容" # grep递归匹配特定内容，只显示文件名 grep -rl "特定内容"

DialogFragment中取消弹窗

某天（周六）测试反馈一个本该不能用返回取消的弹窗，是可以用返回手势取消的。心中满是疑惑，代码中已经写了dialog?.setCanceledOnTouchOutside(false)怎么不生效呢？ 带着关键字查Google，都说用setCancelable(false)就可以了，大为震惊。日思夜想睡不着，今天一定要查个明白。

2024年终总结

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

Context是什么

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

Android代码混淆

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

View的焦点

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

ADB protocol

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