每日新聞摘要

The article introduces Kdrant 2.3.0’s kdrant-mcp, a single static binary that lets an agent talk to Qdrant without spawning a Python runtime, virtualenv, or dependency tree. By default it exposes six read-only MCP tools, while write operations remain disabled unless the server is started with --allow-writes. The piece also explains a Kotlin logging pitfall for MCP servers: anything written to stdout can corrupt the protocol stream, so logs should be redirected to stderr. Beyond the server, it highlights the coroutine-first Kdrant client, its REST and gRPC options, native-image support, and measured performance tradeoffs versus the official client.

文章介绍了 Kdrant 2.3.0 的 kdrant-mcp：它是一个静态二进制文件，可让代理直接访问 Qdrant，而不必反复启动 Python 解释器、virtualenv 和依赖树。默认情况下它只暴露六个只读 MCP 工具，写入与删除操作必须显式开启 --allow-writes。文中还强调，MCP 协议依赖 stdout，Kotlin 的默认日志如果写到标准输出会破坏流，因此应将诊断信息重定向到 stderr。除此之外，作者也说明了 Kdrant Kotlin 客户端、REST/gRPC 选择、原生镜像支持与性能权衡。

Working with Jetpack Compose changed the author’s mindset more than its syntax did. Instead of thinking in terms of finding and mutating views, Compose encourages a state-driven model where UI is a function of state and user actions flow upward as events. The article explains how to model screen state with a single UiState object, why recomposition is expected, and how state ownership should be kept close to where it is needed. It also emphasizes that Compose does not solve architecture problems by itself: developers still need clear separation of concerns and should avoid pushing database, network, and business logic into composables.

作者在接触 Jetpack Compose 后，最大的改变并不是语法，而是对 UI 的思考方式。相比传统以 view 为中心、通过查找并修改组件来更新界面的做法，Compose 更强调以 state 驱动 UI，并让用户操作作为事件向上流动到 ViewModel 和数据层。文章说明了如何用单一的 UiState 表达页面状态、如何理解 recomposition，以及为什么 state 的归属应尽量靠近实际使用位置。作者也强调，Compose 虽然让声明式 UI 更容易实现，但并不会自动解决架构问题，仍需要清晰的职责分离。

AlertSpot is a privacy-first Android transit alarm built to help riders avoid missing their stop. The app uses Kotlin, Jetpack Compose, OSMDroid, and Google Play Services geofencing to deliver alerts when users enter a destination area. To keep costs and power use down, it avoids Google Maps API billing, caches OpenStreetMap tiles locally, and adjusts location polling based on proximity to active geofences. It also combines foreground service behavior, full-screen intents, wake locks, and reboot recovery to improve reliability through Doze mode and device restarts. The project is fully open source, stores data locally, and has no accounts, analytics, or telemetry.

AlertSpot 是一款以隐私优先为核心的 Android 通勤提醒应用，旨在帮助乘客避免坐过站。作者使用 Kotlin、Jetpack Compose、OSMDroid 和 Google Play Services 的地理围栏功能搭建应用，当用户进入目的地范围时触发提醒。为了控制成本和电量消耗，应用改用 OSMDroid 渲染地图、将 OpenStreetMap 图块缓存在本地，并根据与地理围栏的距离动态调整定位轮询频率。它还结合前台服务、全屏 Intent、Wake Lock 和重启后的地理围栏重注册机制，以提升在 Doze 模式和设备重启后的可靠性。

Kotlin 2.4 introduces changes that can simplify Android development, with the article highlighting context parameters as the main reason dependency injection code may shrink. It also notes that the UUID API has been stabilized and that Java 26 is supported. The piece focuses on what these updates mean in practice for Android developers, while avoiding claims beyond the stated language and platform changes.

Kotlin 2.4 为 Android 开发带来几项值得关注的更新，文章特别强调 context parameters 可能让依赖注入代码显著减少。与此同时，UUID API 已稳定，Kotlin 也加入了对 Java 26 的支持。文章主要说明这些变化对 Android 开发者意味着什么，并未引入原文之外的效能数据或比较结果。

The article frames Jetpack Compose 1.12 as an update that addresses several long-standing Android development gaps. It highlights support for mesh gradients and HDR color, adds Credential Manager autofill, and points to startup performance that finally matches traditional Views. The text is a brief teaser rather than a full technical breakdown, but it suggests Compose 1.12 brings both visual capabilities and practical app-launch improvements that Android developers have wanted for years.

这篇文章将 Jetpack Compose 1.12 形容为弥补 Android 开发者多年期待的一项更新。原文提到新版本支持 mesh gradients 和 HDR 色彩，并加入 Credential Manager 自动填充功能；同时也强调启动性能终于可以与传统 Views 看齐。由于正文非常简短，它更像是一段功能亮点预告，但仍清楚传达了 Compose 1.12 在视觉能力与应用启动体验上的改进方向。

The article introduces an enterprise headless Kotlin Multiplatform (KMP) engine designed to support mobile platforms such as Android and iOS. Its main architectural point is that stopping at the Use Case layer, described as a “logic-native-ui” approach, is the sweet spot for enabling mobile applications without compromising the user interface. The piece frames this as an enterprise-oriented strategy for building a shared engine that powers multiple platforms while keeping UI concerns separate.

本文介绍了一种面向企业的无头 Kotlin Multiplatform（KMP）引擎，用于支撑 Android、iOS 等移动平台。文章强调，架构应停在 Use Case 层，即所谓的“logic-native-ui”方式，这样才能在不妥协用户界面的前提下实现移动端赋能。作者将其视为一种适合企业共享引擎的架构思路，使多平台能够复用核心能力，同时保持 UI 的独立性。

The article frames Android Gradle Plugin 9.4 as a small version bump that may still matter for certain projects. It specifically calls out teams using dynamic feature modules or the older Variant API, suggesting they should pay close attention to the update. Rather than announcing broad new capabilities, the piece warns that seemingly minor changes can have practical impact for builds that rely on older integration patterns.

本文将 Android Gradle Plugin 9.4 描述为表面上只是一次小版本升级，实际上却可能对某些项目产生影响。作者特别指出，使用动态功能模块，或仍停留在旧版 Variant API 的开发者，需要认真关注这次更新。文章并未强调新增能力，而是提醒看似轻微的变化，可能会对依赖旧整合方式的构建流程带来实际影响。

This article takes a hands-on look at Google’s new Navigation 3 library and asks whether it is worth migrating away from Navigation Compose. Rather than assuming the new option is automatically better, it frames the question around the real cost of change, the potential migration headache, and whether the update represents meaningful progress or simply more churn. The piece is presented as an evaluation of practical tradeoffs, with the main concern being whether developers should adopt the new library or wait.

本文以实操视角评估 Google 推出的新导航库 Navigation 3，并提出一个关键问题：它是否值得从 Navigation Compose 迁移过去。文章并未默认新方案一定更优，而是围绕迁移所需付出的成本、可能带来的麻烦，以及这次更新究竟是有实质意义的进展，还是又一次技术折腾展开。整体内容是在权衡采用新库与继续观望之间的利弊。

This article describes how an Android app migration can become harder when Java and Kotlin coexist for too long. The author points to nullability, coroutines, Compose, and dependency boundaries as the main sources of migration debt. Rather than treating the move as a simple language switch, the piece shows how mixed codebases can accumulate friction and make later changes more difficult. It frames the lesson as one about planning boundaries and managing Kotlin adoption carefully so that coexistence does not become a long-term problem.

本文讲述了一个 Android 应用在迁移过程中，若 Java 与 Kotlin 长期共存，容易逐步累积迁移债务。作者指出，nullability、coroutines、Compose 以及依赖边界是造成复杂度的主要因素。文章并未把迁移描绘成简单的语言切换，而是强调混合代码库会带来额外摩擦，使后续修改和演进更加困难，因此在引入 Kotlin 时需要更审慎地规划边界与共存方式。

This article reflects on a frustrating debugging session triggered by just four lines of code, which became a lesson in how Ktor, Koin, and Exposed interact in a Kotlin application. Rather than relying on hidden behavior or “magic,” the author uses the experience to argue for a stack that is more explicit and easier to reason about. The piece centers on the practical impact of framework integration and the value of making application wiring clearer.

这篇文章回顾了一次令人沮丧的排查经历：仅仅四行代码，就让作者耗费了整个下午，也因此更深入地理解了 Ktor、Koin 和 Exposed 在 Kotlin 应用中的交互。作者借此反思框架中的“魔法”和隐藏行为，主张技术栈应当更显式、更易推理，让应用的组装方式和依赖关系更加清晰。

The excerpt introduces a Jetpack Compose article comparing @Immutable and @Stable, asking what these annotations are actually telling Compose. However, the provided text contains only the opening sentence and a link to continue reading on Medium, so no deeper technical claims, examples, or conclusions are available in the supplied content. The safest summary is that the article’s focus is on understanding the meaning and use of these Compose annotations, but the excerpt itself does not provide the full explanation.

这段内容只展示了文章开头，主题是 Jetpack Compose 中的 @Immutable 与 @Stable，以及它们实际上在告诉 Compose 什么。由于目前给出的文本只有一句引言和“继续在 Medium 阅读”的链接，无法得知作者后续的技术说明、示例或结论。因此，可以确认文章关注的是理解这两个注解在 Compose 中的含义与用途，但摘录本身不足以还原完整论点。

Jackson may fail to deserialize JSON into a class even when the field names match, if it cannot determine how to create the target instance. This article reproduces the InvalidDefinitionException with an immutable Notification class and shows several fixes: add a default constructor for mutable types, annotate a constructor or factory method with @JsonCreator and @JsonProperty, or let Jackson infer constructor parameter names via ParameterNamesModule or ParanamerModule in Jackson 2.x. It also notes that Jackson 3.x supports parameter-name discovery by default and that Paranamer is limited to Jackson 2.x.

即使 JSON 属性与类字段一致，Jackson 也可能因为无法判断如何创建目标对象而在反序列化时抛出 InvalidDefinitionException。本文以不可变的 Notification 类复现该错误，并给出多种解决方案：为可变类添加默认无参构造函数；使用 @JsonCreator 和 @JsonProperty 注解构造函数或静态工厂方法；或者在 Jackson 2.x 中通过 ParameterNamesModule、ParanamerModule 让 Jackson 推断构造参数名。文中同时说明，Jackson 3.x 已默认支持参数名发现，而 Paranamer 仅支持 Jackson 2.x。

The author describes building Muffle, an Android app designed to silence a phone automatically without sending location data to the cloud. To support overlapping rules and background reliability, the system uses GeofencingClient, a local Room database, a ForegroundService, and reboot re-registration via ACTION_BOOT_COMPLETED. Because GPS alone can fail indoors, the design also combines geofencing with prayer-time calculations from the Adhan library. The article emphasizes that reliability and privacy are more important than clever features, and that keeping data local helps build user trust.

作者介绍了为 Muffle 设计 Android 自动静音功能的过程，重点是不把定位数据上传到云端，而是让整套系统完全在设备端运行。为了处理多重且可能重叠的规则，他采用 GeofencingClient、本地 Room 数据库、ForegroundService，并在 ACTION_BOOT_COMPLETED 后重新注册地理围栏。由于单靠 GPS 可能在清真寺内失准，作者又加入 Adhan 库计算祷告时间，形成更稳健的混合方案。文章强调，可靠性和隐私比“聪明”功能更重要，而数据留在本地本身就是信任的一部分。

On-device AI on Android should not be treated as always available. The article explains that many devices lack the right chipset, OS version, provisioning, or Google support, so apps that assume Gemini Nano can run locally often crash or fail silently. Instead of wrapping calls in try/catch, developers should model capability as explicit state, detect features before building UI, and distinguish unsupported devices from those that only need a download. The article also recommends a thoughtful fallback strategy: use cloud inference only for user-initiated requests, not background speculation, and re-check availability because the device state can change while the app is running.

Android 端侧 AI 不能默认可用。文章指出，许多设备会因为芯片不匹配、系统版本过旧、AICore 未预配，或尚未进入 Google 支持名单，而无法运行 Gemini Nano；如果应用直接假定本地推理可用，就可能崩溃或静默失效。作者建议不要只用 try/catch，而应在构建 UI 前先做功能检测，并用封装状态区分“永远不可用”和“下载后可用”。同时，云端回退只适用于用户明确需要立即响应的场景，后台推理则不应悄悄变成云端成本。

The article introduces an animated speed dial floating action button pattern for modern mobile apps built with Compose Multiplatform. It frames the topic around a common mobile constraint: limited screen space and the need for a clean interface while keeping actions easy to reach. Based on the available text, the piece appears to present a UI approach for Android and iOS rather than broader platform claims or performance comparisons. The excerpt does not provide implementation details, benchmark data, or specific Kotlin advantages, so the summary stays limited to the stated topic and context.

本文介绍了在 Compose Multiplatform 中实现动画式 speed dial 浮动操作按钮的思路，适用于 Android 和 iOS。文章从移动应用的常见限制切入：屏幕空间有限，用户希望界面简洁，同时又需要便捷的操作入口。由于当前可见内容仅包含标题与开头摘要，未提供具体实现细节、性能数据或比较结果，因此摘要只忠于已知信息，保留其作为跨平台 UI 设计主题的语境。

This article introduces the idea that Android apps can behave differently across phones because OEMs fork AOSP and change it in ways that may break assumptions developers make. The short excerpt does not provide technical details, examples, or specific issues, but it clearly frames the topic as the relationship between OEM customizations and app behavior. Readers are directed to continue reading on Medium for the full explanation.

文章开头指出，Android 应用在不同手机上表现不一致，与各家 OEM 对 AOSP 的分支和修改有关，这些改动可能打破开发者原本的假设。由于原文只提供了简短片段，没有给出具体案例或技术细节，但主题已经明确聚焦于 OEM 定制如何影响应用行为。作者也引导读者前往 Medium 继续阅读完整内容。

A bug report about a Compose slider stayed in the backlog for seven months before being fixed. According to the article’s brief description, the fix took only a day, removed a third of the slider’s logic, and was nearly shipped in its flawed state. The post promises an anatomy of the bug rather than a full technical breakdown in the excerpt, highlighting how long-standing issues can persist before a relatively small but impactful correction is made.

这篇文章讲述一个 Compose 滑块的 bug 报告在 backlog 中搁置了七个月，随后修复只用了一天，并删除了滑块三分之一的逻辑。根据摘要，这个修复几乎在问题未完全厘清前就要被发布。文章重点是对该 bug 的经过进行剖析，呈现一个长期存在的问题如何通过一次较为精简的修正得到处理。

A seven-month-old bug in a custom Compose slider made the thumb move ahead of the user’s finger during slow drags. The cause was not a random defect but a behavior faithfully ported from the old View-based slider: snapping to the nearest tick during drag. By removing mid-drag snapping and moving all snapping to gesture end, the fix deleted a large amount of code and eliminated a related race condition. The article also describes a separate reset bug caused by re-keying remembered state without re-keying a LaunchedEffect, which an AI code reviewer caught in the diff. The story argues for porting intent rather than implementation and for preferring one source of truth over coordinated state.

一个在 backlog 里放了七个月的 Compose 滑块 bug，表现为用户缓慢拖动时，拇指会跑到手指前面。根因并不是偶发故障，而是从旧版 View 滑块完整移植了“拖动过程中吸附到最近刻度”的行为。作者将吸附改为在手势结束时执行，删除了大量中间状态、动画和协程相关代码，也消除了一个伴随的竞态问题。文章还讲到一个重置后 remembered state 与 LaunchedEffect 脱节的隐藏 bug，最终由 AI code reviewer 在 diff 中发现。整篇文章强调：要移植意图，不要照搬实现；最好的一类修复，往往是删代码。

This entry is labeled “Part 9 — Networking” in an Android interview preparation series by AB nay. The available content does not include the full article; it only shows the series index line “Android Interview Prep — Complete Index” and a prompt to continue reading on Stackademic. As a result, the post’s substantive networking discussion is not present in the provided text, and no additional technical claims can be confirmed from this excerpt.

这篇文章标记为 AB nay 的 Android 面试准备系列中的〈第 9 部分——网络连接〉。目前给出的正文并不包含完整文章，只能看到“Android Interview Prep — Complete Index”以及前往 Stackademic 继续阅读的提示。因此，无法从这段摘录确认具体的网络连接技术内容，也不能推断原文未明确说明的细节。

This article explains the build-layer changes needed to make a Compose Multiplatform fork work on tvOS. The author describes how targets and source sets were wired so tvOS could compile alongside iOS, using a shared uiKitMain layer to minimize duplication while keeping tvOS-specific code isolated. It also covers buildSrc and build-fork.gradle mechanics, which let the fork preserve upstream build files and reduce rebase conflicts. On the helper-library side, the Xcode project and Gradle configuration were adjusted for tvOS SDKs, destinations, and linker settings. Finally, the Compose Gradle plugin was updated to decode tvOS resources and recognize tvOS targets. The post closes by noting that the build now compiles, and the next work is rendering.

本文介绍了在 Compose Multiplatform 的 fork 中让 tvOS 可用所需的构建层改动。作者先配置 tvOS targets 和 source sets，并以 uiKitMain 作为 iOS 与 tvOS 共享的 UIKit 层，以减少重复实现，同时保留平台专属逻辑。文章还说明了 buildSrc 与 build-fork.gradle 的机制，使 fork 能尽量保留上游构建文件，降低 rebase 冲突。随后，Xcode 工程与 Gradle 配置被调整，以支持 tvOS 的 SDK、目标设备和 linker 参数；Compose Gradle 插件也更新为能识别 tvOS 资源与目标。最后作者指出，构建已经能通过，下一步将进入 rendering。

This article points to new Kotlin features that developers may have been waiting for, with a brief teaser mentioning Kotlin 2.4.20 and its collection-related changes, as well as compiler updates in Kotlin 2.2. The wording is playful, but the core message is that recent Kotlin releases are bringing noteworthy improvements to both collections and the compiler. The excerpt does not provide technical details beyond that high-level preview.

这篇文章用轻松的口吻预告 Kotlin 的一些新功能，提到 Kotlin 2.4.20 为集合带来了相关变化，以及 Kotlin 2.2 的编译器更新。虽然正文只是一段简介，没有展开具体技术细节，但可以看出文章关注的是近期 Kotlin 版本中备受期待的改进，重点落在集合与编译器两个方面。

This third part of the KMP Starter Kit series explains how to get an app ready for Google Play and the App Store, and how to publish it from GitHub without a Mac. It frames release work as a checklist, with scripts that verify privacy links, contact emails, AI keys, configuration, signing, icons, screenshots, and other store requirements. The post also covers store account setup, immutable app IDs, Android keystore handling, iOS signing through GitHub Actions and fastlane match, and the store-specific metadata each platform asks for. Finally, it shows how tagged releases trigger automated builds and uploads, and notes common issues such as Google sign-in fingerprints and review rejections.

本文是 KMP Starter Kit 系列的第三篇，介绍如何把已完成的 App 准备上架到 Google Play 和 App Store，并可在没有 Mac 的情况下通过 GitHub 发布。作者将发布流程视为一份检查清单，套件提供脚本用来检查隐私政策、联系邮箱、AI 密钥、配置、签名、图标和截图等常见项目。文章还整理了两大商店所需的账号、不可更改的 App ID、Android keystore、iOS 签名与 fastlane match 的设置方式，以及各平台要求的商店信息。最后说明通过 git tag 触发 GitHub Actions 自动构建与上传，并提醒 Google 登录 fingerprint 和审核被拒等常见问题。

This article explains why LiteRT-LM is useful for running LLMs fully on-device, especially for multi-turn chat, streaming responses, and explicit CPU/GPU selection. It contrasts the runtime with cloud APIs, emphasizing privacy, offline operation, and the tradeoff that developers must manage sampling, token budgets, and prompt formatting themselves. The post then walks through the Engine/Session model, warns about a native library collision that can trigger SIGSEGV if the wrong .so is packaged, and shows how to implement streaming generation, system prompts, tool calling, multimodal input, and thinking mode. It also covers CPU-versus-GPU benchmarking, common anti-patterns, and ends with a developer-friendliness rating.

本文介绍 LiteRT-LM 适合在设备端运行 LLM 的原因，尤其是多轮对话、流式输出，以及按设备显式选择 CPU 或 GPU。作者对比云端 API，强调其优点是离线、隐私和无需网络依赖，但代价是开发者要自行管理 sampling、token 预算和提示格式。文章随后解释 Engine/Session 的工作方式，提醒一个原生库冲突可能因打包错误引发 SIGSEGV，并示范了流式生成、系统提示、工具调用、多模态输入与 thinking mode 的实现。最后还总结了 CPU/GPU 基准测试、常见反模式以及开发者友好度评分。

Kotlin 2.4.20 adds allDistinctBy and allEqualBy, which make common collection checks shorter and clearer than mapping, deduplicating, and comparing sizes. These APIs work with Iterable, Sequence, and arrays, use structural equality, and remain experimental. The article also revisits context-sensitive resolution, introduced experimentally in Kotlin 2.2, which lets the compiler infer enum or sealed-type members in when expressions and omit type qualifiers. It can improve readability, but it is still experimental, may introduce ambiguity, and is best suited to projects that are comfortable adopting Kotlin’s newer compiler features.

Kotlin 2.4.20 引入 allDistinctBy 和 allEqualBy，使常见的集合检查不必再先映射、去重并比较大小，表达更直接。它们可用于 Iterable、Sequence 和数组，采用结构相等判断，目前仍属于实验性 API。文章还介绍了 Kotlin 2.2 实验加入的 context-sensitive resolution，编译器可依据上下文推断 when 中的枚举或 sealed 类型成员，从而省略类型限定名。不过该特性仍可能出现歧义，更适合在能接受实验功能的项目中尝试。