每日新聞摘要

This issue of Java Weekly spotlights the arrival of Java 27 and its headline changes, including post-quantum TLS, G1 as the default collector everywhere, compact object headers by default, and improvements in concurrency, JFR, and the Vector API. It also gathers related articles, webinars, and presentations for readers who want deeper context, along with a broad set of upgrade announcements across the Java ecosystem. The weekly closes with a pick of the week on converting a timestamp into hours, minutes, and seconds.

本期 Java Weekly 聚焦 Java 27 的发布及其主要变化，包括后量子 TLS、G1 在所有环境中成为默认收集器、默认启用紧凑对象头，以及并发、JFR 和 Vector API 的改进。文章还汇总了相关阅读、网络研讨会和演讲，方便读者进一步了解；同时列出多个 Java 生态项目的升级信息。最后的本周精选介绍了如何更快地将时间戳转换为时、分、秒。

This article introduces a practical framework for deciding between SharedPreferences, DataStore, Room, and file-based storage before writing data in an Android app. It frames the choice as a set of questions to answer early, with the goal of preventing avoidable production issues later. The piece emphasizes that storage selection should be guided by real app needs and tradeoffs rather than habit, and it positions the framework as field-tested guidance for making a safer architectural decision.

本文提出一套实用框架，帮助 Android 开发者在写入数据之前，先判断该选择 SharedPreferences、DataStore、Room，还是文件存储。作者把存储方案的选择整理成一组需要先回答的问题，目的在于尽早厘清需求与取舍，避免日后在生产环境中付出修正成本。文章强调，存储设计应根据应用场景决定，而不是沿用习惯或直觉。

The article points out that the UI layer has its own attack surface, even though it may not look like a security decision at first glance. Based on the available text, it frames Compose security concerns around FLAG_SECURE, Layout Inspector, and a PIN field that does not leak sensitive input. The excerpt does not provide further implementation details or claims, so the core message is simply that UI behavior can carry security implications and should be treated accordingly.

本文指出，UI 层本身也存在攻击面，只是因为它看起来不像安全性决策，所以很容易被忽视。就目前可见内容来看，文章围绕 Compose 的几个安全主题展开，包括 FLAG_SECURE、Layout Inspector，以及如何避免 PIN 输入框泄露敏感信息。由于原文只给出摘要片段，没有更多实现细节，因此能够确认的核心信息是：界面行为同样会带来安全影响，设计时不能忽略。

This article argues that CompositionLocal should not be treated as a dependency injection mechanism. The author warns that using it as a stand-in for DI may seem convenient at first, but it can create problems later in maintenance and architecture. The piece frames the topic as a cautionary note for Kotlin/Compose developers, emphasizing that CompositionLocal serves a different purpose than application-wide dependency provisioning.

本文主张 CompositionLocal 不应被视为依赖注入机制。作者提醒，如果一开始把它当作 DI 的替代方案，虽然看起来方便，但日后可能在维护和架构上引发问题。文章以提醒 Kotlin/Compose 开发者为主，强调 CompositionLocal 的用途与应用程序级别的依赖提供并不相同，两者不宜混为一谈。

The article argues that the UI layer is made up of two distinct halves and that problems begin when developers merge them into a single unit. According to the title and framing, this design choice is what leads screens to become difficult or impossible to test. No further technical details, examples, or implementation specifics are provided in the supplied text, so the safe takeaway is the article’s core claim about separating UI responsibilities to preserve testability.

文章指出，UI 层可以被看作由两个不同半部组成，而问题出现在开发者将它们合并成一个整体。根据标题和文章主旨，这种设计会让屏幕逐渐变得难以测试，甚至失去可测试性。由于提供的正文只有标题和导读，没有更多技术细节、实现示例或数据，因此能够确认的结论仅是作者强调应分离 UI 职责，以维持测试能力。

The article introduces the importance of building a robust, scalable network layer in modern Android development and frames Kotlin with Ktor as the technology stack for that goal. Based on the available excerpt, it emphasizes resilience and readiness for growth, but the full implementation details are not shown in the provided text.

文章开头指出，在现代 Android 开发中，构建稳健且可扩展的网络层非常重要，并以 Kotlin 与 Ktor 作为技术背景。根据目前可见内容，重点在于提升网络层的韧性与面向增长的准备度；但由于未提供全文，无法确认更具体的实现细节或设计方案。

This short Medium post says the author found a note in their vault about Kotlin.Result that included a `when` statement which had never compiled. The piece highlights a mismatch between the note and Kotlin’s actual Result API, and the title emphasizes that Kotlin.Result has no success branch. Based on the provided excerpt, the article is a brief observation about an incorrect code note rather than a detailed explanation or implementation guide.

这篇 Medium 短文提到，作者在自己的笔记库中发现一条关于 Kotlin.Result 的笔记，其中包含一个实际上从未能够编译通过的 `when` 写法。文章重点在于指出笔记内容与 Kotlin.Result 的真实用法不符，标题也直接说明 Kotlin.Result 没有 success 分支。就目前提供的内文来看，这篇文章更像是对错误笔记的简短更正，而不是完整的技术讲解。

Rather than framing the choice as Kotlin versus Flutter, the article argues that the better question is how much of the platform you want to own. It suggests that the decision should start with your app’s needs and the degree of control or responsibility you want over the platform, instead of treating the framework as the main issue. The piece is short and serves as a reminder to rethink the criteria used when evaluating mobile development options.

文章认为，与其讨论 Kotlin 还是 Flutter，真正该先问的是：你想拥有多少平台控制权。作者指出，选择应从应用需求、对平台的掌控程度以及愿意承担的责任出发，而不是把框架本身当作唯一重点。本文篇幅很短，主要是在提醒读者重新思考评估移动开发方案时应采用的标准。

The article says the author wanted a WishKit-style feedback board for Android. It describes WishKit as a pleasant Swift package that needs only one configuration call, shows a list of wishes, and lets users vote directly inside the iOS app. The provided excerpt is brief and does not include further implementation details or results.

文章表示作者想在 Android 上实现一个类似 WishKit 的反馈看板。文中将 WishKit 形容为一个不错的 Swift 包，只需一次配置调用即可展示愿望列表，并允许用户在 iOS 应用内直接投票。所给内容非常简短，没有提供更多实现细节或最终结果。

This article is presented as a practical Kotlin and Jetpack Compose guide for mobile engineers who want to understand UI and presentation architecture beyond the classic Gang of Four. It introduces seven patterns: MVC, MVP, Passive View, Presentation Model, MVVM, MVI, and Unidirectional Data Flow. The provided text does not include the full article, so the scope is limited to what the title and excerpt confirm: a broad overview of these patterns for mobile UI design and presentation-layer structure.

本文被介绍为一份面向移动工程师的实用指南，用 Kotlin 和 Jetpack Compose 帮助理解 UI 与展示层架构，范围超出传统的 Gang of Four。文中列出的模式包括 MVC、MVP、Passive View、Presentation Model、MVVM、MVI 以及单向数据流。由于可用内容只有标题和摘要，因此只能确认这是一篇关于这些模式的概览文章，无法推断更多未提供的细节。

The article describes the challenge of building a simple Android app that helps users hear surrounding sounds more clearly through a phone and headphones or earbuds. Although the basic idea is straightforward—microphone input, audio processing, and output—the author notes that making it work well in real time introduces engineering difficulties, especially around latency. The post outlines a simplified audio pipeline from microphone capture to gain, processing, and playback, and mentions the author’s ongoing app, Sound Amplifier: Hear Better, which is currently available on Google Play for testing and feedback.

本文介绍作者想开发一款简单的 Android 应用，让用户借助手机和耳机或耳塞更清楚地听见周围声音。虽然整体思路很直观——麦克风输入、音频处理、再输出，但要把它做成真正可用的实时功能，会遇到不少工程难题，尤其是延迟。文章还用简化流程说明了从麦克风采集、增益、处理到播放的音频管线，并提到作者正在开发的 Sound Amplifier: Hear Better，目前已可在 Google Play 下载体验并提供反馈。

JetBrains has released Ktor 3.6.0, a major update to the Kotlin web framework that adds experimental HTTP/3 support for Netty, a typed OpenID Connect authentication module, and several routing and client-side improvements. The release aims to make modern API development simpler and safer by reducing setup work and runtime mistakes. Ktor’s maintainers say the new version gives developers out-of-the-box tools for secure, high-performance services, while the roadmap points toward a future 4.0 release with greater HTTP/3 stability and broader platform support.

JetBrains 于 2026 年 9 月 18 日发布 Ktor 3.6.0，为这个基于 Kotlin 的开源 Web 框架带来重要更新。新版本加入 Netty 的实验性 HTTP/3 支持、类型化 OpenID Connect 认证模块，以及多项路由和客户端改进，旨在简化现代 API 开发并降低配置与运行时错误。Ktor 维护者表示，这些能力能帮助开发者更快速地构建安全、高性能的服务；文章也提到，后续 4.0 版本预计会进一步聚焦 HTTP/3 稳定性与更广泛的平台支持。

Native Android “OTA” is not a single mechanism but a set of different update paths with different risk profiles. The article argues that teams should first classify what needs to change after release, then choose the smallest safe update surface: Play In-App Updates for new signed binaries, remote configuration for runtime switches, APIs for content changes, and constrained server-driven UI only when dynamic composition is truly needed. It warns against downloading replacement Kotlin, DEX, or native code, noting Android security guidance and Google Play policy limits. The overall recommendation is a layered architecture that improves rollback, testing, and release control instead of trying to patch everything remotely.

原生 Android 所谓的“OTA”并不是单一机制，而是多种更新路径的总称，适用范围和风险都不同。文章建议先判断发布后到底要改什么，再选择最小且安全的更新面：新签名二进制可用 Play In-App Updates；运行时切换可用远程配置；内容变更可交给 API；只有在产品确实需要动态组合时，才考虑受限的 server-driven UI。文中也强调，不应从远端下载替换 Kotlin、DEX 或原生代码，因为这会触及 Android 安全指南和 Google Play 政策限制。整体思路是采用分层架构，以提升回滚、测试和发布控制能力。

An Android-recorded MP4 does not contain a frame-rate value; it stores a timescale and per-sample durations, from which playback timing is derived. The article traces how Android documents MediaFormat.KEY_FRAME_RATE as an advisory encoder hint that does not travel to MediaMuxer, while MediaCodec.BufferInfo and MediaMuxer.writeSampleData() rely on per-frame presentation timestamps instead. It also explains that Camera2 can legitimately vary capture spacing through AE target FPS ranges, and that the final sample’s duration is inferred at the file boundary. The practical takeaway is to measure real footage, because seeking, file sizing, and time-of-day inference depend on the actual deltas written into the file.

Android 录制的 MP4 不会直接保存帧率，而是通过 timescale 和每个样本的持续时间来构建时间轴。文章引用 Android 文档说明，MediaFormat.KEY_FRAME_RATE 只是给编码器的建议值，不会传递到 MediaMuxer；真正写入文件的是每帧的 presentation timestamp。它还指出，Camera2 的 AE 目标 FPS 范围本来就允许调整采集间隔，因此录制过程可能并非等间距。最后一帧的时长则会在文件边界按惯例补齐。作者因此建议，不要依赖名义 FPS 推算，应该直接测量实际视频。

KeyTab’s optional typing trail keeps the last key tinted as you type, and its correction trace shows which letters autocorrect would replace or accept. During a design review, the author realized this visual feedback can become a side channel: if someone can see or record the screen, they may reconstruct typed input even when a password field displays only dots. To prevent that leak, KeyTab suppresses the trail in two cases only: password fields and when IME_FLAG_NO_PERSONALIZED_LEARNING is set. There is no setting to disable it, and four unit tests protect the rule. The correction trace remains read-only and never commits text, so the same trick does not work there.

KeyTab 有一个可选功能叫 typing trail，会在持续输入时让最后按下的键保持着色并逐步淡出；还有 correction trace，会用颜色显示自动更正会替换哪些字母、字典接受哪些字母。作者在设计评审中意识到，这种视觉反馈可能成为侧信道：只要有人能看见或录下屏幕，即使输入框本身只显示圆点，也可能根据颜色信息还原输入内容。为避免泄露，系统只在密码字段或设置 IME_FLAG_NO_PERSONALIZED_LEARNING 时关闭轨迹，而且这条规则写进代码，不提供开关，并由四个单元测试保护。

The author describes why they built and open-sourced @vijeshkr/react-native-biometric-auth for React Native. Existing biometric solutions felt cumbersome, relied on legacy Java-based dependencies, or required more setup than desired. To keep the module lightweight, they created an Android-focused library in Kotlin using AndroidX Biometric. The package supports biometric authentication with optional device credential fallback, exposes a simple Promise-based API, and includes TypeScript definitions. The article also explains the basic usage flow—check availability first, then call authenticate()—and notes that the project is currently centered on Android, with future improvements and broader platform support under consideration.

作者介绍了自己为何为 React Native 开发并开源 @vijeshkr/react-native-biometric-auth。现有生物识别方案要么回退支持繁琐，要么依赖较旧的 Java 实现，或者配置过重，因此他选择用 Kotlin 和 AndroidX Biometric 构建一个更轻量的 Android 原生模块。该库支持生物识别认证，并可按需回退到设备凭证，提供简洁的 Promise 风格 API，同时附带 TypeScript 定义。文章还说明了先检查可用性、再调用 authenticate() 的基本使用方式，并提到项目目前聚焦 Android，后续会继续改进功能、文档、测试和可能的平台扩展。

The article describes how the author built Muffle, an Android app that automates sound profiles while keeping all logic entirely on-device. Rejecting cloud-based geofencing and opaque third-party services, the author chose a privacy-first architecture using FusedLocationProviderClient, a foreground service, and local routines for location checks. Because GPS can drift in large buildings, the implementation adds cooldowns and a sliding window average to avoid unstable toggling. The piece also emphasizes that simple UI, clear activity logs, and honest background behavior are key to user trust, battery respect, and dependable automation.

作者介绍了 Muffle 的设计与实现：这是一款在 Android 上根据情境自动调整声音模式的应用，但其全部逻辑都运行在设备本地，完全不依赖云端。为了贯彻隐私优先原则，他没有采用标准的 GeofencingClient，而是使用 FusedLocationProviderClient、前台服务和本地数据库来处理位置触发。考虑到大型建筑内 GPS 容易漂移，方案加入了冷却时间与滑动窗口平均，减少频繁切换的问题。文章最后强调，透明的后台行为、清晰的活动日志以及对电池和用户意图的尊重，是建立自动化系统信任的关键。

In the third part of the Kotlin/Wasm authentication series, the focus shifts to phone sign-in. The article warns about three Firebase console pitfalls: phone auth now requires the Blaze plan, SMS region policy blocks all regions by default, and reCAPTCHA tokens can be used only once. On the Kotlin side, the implementation is small but requires new bindings for RecaptchaVerifier, PhoneAuthProvider, and signInWithCredential, plus a DOM container for the captcha. The flow is split into verifying the phone number, then exchanging the verification ID and SMS code for a signed-in user. For testing, Firebase’s fictional phone numbers and app verification bypass can eliminate real SMS and captcha usage, but should never be shipped enabled.

本文是 Kotlin/Wasm 认证系列的第三部分，主题是手机号码登录。作者先提醒 Firebase 控制台的三个坑：手机认证现在要求 Blaze 套餐，SMS 区域政策默认会拒绝所有区域，且 reCAPTCHA token 只能使用一次。Kotlin 侧需要补充 RecaptchaVerifier、PhoneAuthProvider 和 signInWithCredential 的外部定义，并为验证码创建一个实际的 DOM 容器。登录流程分为两步：先验证手机号并保存 verification id，再用短信验证码换取已登录用户。开发测试时可使用 Firebase 的虚拟号码和验证开关，但正式发布绝不能开启。

Full Compose does not remove the Android Lifecycle, but Composables have their own lifetime in the Composition. The article argues that many cases handled with LifecycleEventObserver are better expressed with simpler Compose APIs: use DisposableEffect for work tied to a Composable’s presence, LaunchedEffect for coroutines, collectAsStateWithLifecycle() for Flow collection, and LifecycleEventEffect when a specific lifecycle event is actually required. LifecycleEventObserver is still useful for more complex observation or integration with APIs that expect a Lifecycle, but it should not be the default choice when the intent is simply tied to a Composable’s lifetime.

完整的 Compose 并不会移除 Android Lifecycle，但 Composable 也有自己在 Composition 中的生命周期。文章指出，许多原本用 LifecycleEventObserver 处理的场景，其实更适合用更简单的 Compose API 来表达：与 Composable 存在期间绑定的工作用 DisposableEffect，协程用 LaunchedEffect，Flow 状态收集用 collectAsStateWithLifecycle()，如果确实需要特定生命周期事件，则使用 LifecycleEventEffect。LifecycleEventObserver 并不是坏 API，但当需求只是跟 Composable 的生命周期一致时，不必先引入 Android Lifecycle。

Live Lens is an experimental Android demo that combines Agora Conversational AI, Gemini Live, Gemini Vision, and Jetpack Compose to build a realtime assistant that can listen, speak, and understand camera context. The app keeps Android focused on media and interaction: it requests permissions, opens an RTC camera preview, starts a voice session, and exposes controls such as mute, torch, zoom, and end session. A small Python backend owns credentials, token generation, agent lifecycle, and Gemini configuration, while camera snapshots are summarized and injected back into the live voice conversation. The article emphasizes practical architecture choices, state-driven Compose UI, and keeping secrets off-device.

Live Lens 是一个实验性的 Android 演示，结合 Agora Conversational AI、Gemini Live、Gemini Vision 和 Jetpack Compose，构建一个能够聆听、回应并理解摄像头上下文的实时助手。Android 端专注于媒体与交互：申请权限、打开 RTC 摄像头预览、启动语音会话，并提供静音、闪光灯、缩放和结束会话等控制。一个小型 Python 后端负责凭据、token 生成、代理生命周期和 Gemini 配置；摄像头快照先由 Gemini Vision 进行摘要，再注入正在进行的语音对话。文章重点说明了可行的架构分工、以状态驱动的 Compose UI，以及将密钥保留在设备外的重要性。

This article points readers toward the subjects that matter most for an Android fintech interview, emphasizing how such interviews differ from generic Android loops. It frames the discussion around the topics that separate fintech-specific rounds from standard Android interviews and highlights where candidates commonly struggle. Based on the available text, the piece serves as a concise guide to what applicants should study in advance, without adding unsupported details about particular technologies, questions, or company practices.

本文指出，Android 金融科技面试与普通 Android 面试的区别，关键在于那些能拉开差距的主题，以及候选人实际最常失败的环节。就现有文字来看，文章更像是一份面试准备指南，帮助读者明确在面试前应重点学习哪些方向。由于原文未展开具体技术点、题目类型或公司案例，因此不应擅自补充未提及的内容。

The article points to a few core areas to study for a POS Android interview: hardware integration, offline settlement, and the differences between building a payment terminal app and a banking app. Its brief note suggests that POS work involves constraints and responsibilities that are not the same as typical financial software. The emphasis is on understanding the specialized nature of payment terminals rather than assuming general Android or banking-app experience is enough.

文章指出，准备 POS Android 面试时，应重点学习硬件集成、离线结算，以及支付终端和银行 App 之间的区别。这段简短内容强调，POS 开发面对的限制和职责，与一般金融软件并不相同。核心在于理解支付终端的专业性，而不是简单沿用通用 Android 或银行 App 的经验。

This article introduces the problem of persistent background work in Android apps, especially when an app is no longer in the foreground, has been closed, or the device has rebooted. The title suggests a cheat sheet for WorkManager, but the provided text only states that background work becomes more complicated in these situations. Based on the available content, the piece appears to be a brief entry pointing readers to the full article on Medium rather than a detailed technical guide.

本文提到，Android 应用的持久化后台工作在应用离开前台、被关闭或设备重启后会变得更复杂。标题显示内容与 WorkManager 速查表有关，但目前可见正文只有一句概述，没有展开具体实现、配置或使用方法。根据现有信息，这更像是一段引导读者前往 Medium 完整文章的简介，而不是完整的技术说明。

This article notes that the first OpenID Connect implementation in Siere KMP Auth was initially built for Kotlin/JVM desktop. It opened the system browser and started a temporary flow as part of the sign-in process. The excerpt does not provide additional implementation details, performance claims, or comparisons, so the scope is limited to the desktop-focused beginning of the project.

文章摘录说明，Siere KMP Auth 的第一个 OpenID Connect 实现最初是为 Kotlin/JVM 桌面端准备的。它会打开系统浏览器，并启动一个临时流程来完成登录。由于正文仅提供这段简短内容，没有更多实现细节、性能数据或对比结果，因此可确认的信息只限于项目早期的桌面端起点。

The article introduces a comparison between Kotlin 2.4 and Swift 6.4, framing them as two ecosystems shaped by different philosophies. It says the piece looks at what has changed under the hood and why those changes matter for the next app you build. No specific technical details are provided in the excerpt, so the content mainly sets up a broader discussion rather than making concrete claims about features or performance.

这篇文章以 Kotlin 2.4 和 Swift 6.4 的对比为主线，将它们视为代表不同哲学的两个生态系统。文中表示，内容会讨论底层发生了哪些变化，以及这些变化为什么会影响你下一款 App 的开发。由于摘录没有提供更多技术细节，因此这里只能看出它是在为后续更深入的功能与演进讨论做铺垫，并未具体给出任何性能或支持结论。

This article offers a practical overview of using the Android CLI for testing workflows. It describes how the command-line interface can be used to deploy apps, inspect UI state, interact with devices, run Journeys, and analyze failures. The piece focuses on hands-on testing scenarios rather than abstract theory, framing the CLI as a tool for working through unit tests, UI tests, device interaction, and troubleshooting in a more direct way.

本文从实用角度介绍 Android CLI 在测试流程中的用途，说明可以通过命令行部署应用、检查 UI 状态、与设备交互、运行 Journeys，并进一步分析失败原因。文章聚焦实际测试场景，而不是抽象理论，展示 CLI 如何帮助完成单元测试、UI 测试、设备操作和故障排查。

The source text introduces Android CLI as Google’s agent-first tool for Android development and stresses that it is not a replacement for Android Studio. Instead, it is described as creating a new interface between Android development and AI agents. The provided excerpt is brief and functions mainly as a teaser, with the rest of the article available on Medium. No additional technical claims, performance data, or support details are given in the excerpt.

原文说明，Android CLI 是 Google 推出的代理优先型 Android 开发工具，但它并不是用来取代 Android Studio。文章强调，它更像是在 Android 开发与 AI 代理之间建立一层新的交互界面。由于提供的正文仅是一段简短导语，内容没有进一步展开技术细节、功能范围或支持状态，只提示读者到 Medium 继续阅读完整文章。

The author says a personal vault note about extension functions contained a bug and remained unnoticed for three months. Based on the provided text, the article appears to focus on the idea that extension functions resolve their target at compile time. No additional technical details are available in the excerpt, so the summary is limited to the facts explicitly stated in the source.

作者提到，自己关于 extension functions 的笔记里存在一个 bug，而且这个问题整整过了三个月才被发现。就目前提供的正文来看，文章重点在于说明扩展函数的目标会在编译时被选定。由于可用信息有限，摘要仅忠实保留原文明确给出的事实，不额外补充未提供的技术细节。

The article centers on WebSockets as used on Android, with emphasis on the protocol and framing layers, as well as the problems that can appear in mobile contexts. From the provided text alone, it is clear the piece aims to explain the topic in detail and highlight what commonly goes wrong on mobile, but no further technical claims or implementation details are available in the excerpt.

这篇文章聚焦于 Android 上的 WebSockets，重点涉及协议与分帧层面的细节，以及在移动场景中可能出现的问题。就现有摘录来看，文章旨在对该主题进行深入说明，并强调在手机等移动设备上常会出错的地方，但并未提供更多技术实现或结论信息。

The article introduces GraphQL on Android and frames the discussion around three core ideas: the type system, the execution model, and the trade-offs that arise when GraphQL is used to solve other problems. The provided text is brief and does not include implementation details, performance claims, or platform-specific guidance beyond the topic itself. It mainly signals that the full article will examine GraphQL in detail rather than present a tutorial or concrete results.

这篇文章以 Android 上的 GraphQL 为主题，围绕三个核心点展开：类型系统、执行模型，以及在用 GraphQL 解决其他问题时可能产生的取舍。由于目前可见正文非常简短，没有提供具体实现、性能数据或平台层面的细节，只能确认作者意在对 GraphQL 进行深入讨论，而不是直接给出教程或实测结论。