Daily Digest

每日新聞摘要

2026年08月30日

今日總結

內容會跟隨語言切換。

📝 今日焦點：本日聚焦 JSON null、協程取消、SafetyNet 退場與 smart cast，核心都是以可驗證邏輯取代假設，降低跨端與執行期風險。 🔧 效能最佳化：Muffle 以 GeofencingClient 取代高頻定位，透過 loitering delay 與緩衝機制兼顧省電與準確。 🏗 架構設計：ViewModel 解析回 AOSP 生命週期內部機制；Foster 以共享 UI 與 width class 快速支援平板導覽。 🚀 語言演進：Compose Multiplatform 1.12.0 帶來 AI 代理 MCP、Web 字型回退與桌面視窗 API，Kotlin 則持續強調可證明的 smart cast。

📝 Today’s focus: JSON null handling, coroutine cancellation, SafetyNet migration, and smart casts all reinforce Kotlin’s push for verifiable behavior over assumptions. 🔧 Performance: Muffle trades constant location polling for GeofencingClient, using loitering delays and exit buffers to balance battery life and accuracy. 🏗 Architecture: ViewModel is explained through AOSP lifecycle internals, while Foster adds tablet navigation by reusing shared UI and width-class decisions. 🚀 Language evolution: Compose Multiplatform 1.12.0 adds an AI MCP server, web font fallback, and better desktop window APIs, alongside Kotlin’s continued emphasis on provable smart casts.

The Word "null" Is Not a Null: How JSON Nulls Turn Into Text on Android

Dev.to Kotlin 作者：Mahmut Gündüzalp 發布：08-30 10:39

The Word “null” Is Not a Null: How JSON Nulls Turn Into Text on Android

On Android, optString does not return "" for JSON null; it returns the text "null".

重點摘要

JSONObject.NULL is not Java null, so optString can stringify it

JVM json.org and Android org.json can behave differently

Fix both the API boundary and the client helper, not just one side

An Android app displayed “null” in profile fields because JSONObject.optString() turned JSON null into the literal text "null" instead of using the fallback. The article explains that Android’s org.json uses a JSONObject.NULL sentinel, which differs from the JVM json.org implementation, so tests can pass on the desktop but fail on device. It traces the source further back to a PHP API built from LEFT JOINs and aggregates that naturally produced SQL NULLs, which were serialized into JSON nulls. The fix is twofold: normalize or COALESCE values at the server boundary, and stop calling optString directly on the client by wrapping null checks in a helper and enforcing it in review or lint.

“null”这个词不是空值：JSON null 如何在 Android 上变成文本

在 Android 上，optString 遇到 JSON null 不会返回 ""，而是返回字符串 "null"。

重點摘要

JSONObject.NULL 不是 Java null，会被 optString 转成文本

JVM 上的 json.org 与 Android 的 org.json 行为可能不同

应同时修正 API 边界与客户端封装函数

这篇文章说明，Android 应用在个人资料页显示“null”，并不是崩溃或解析失败，而是 JSONObject.optString() 在遇到 JSON null 时，没有返回默认值，而是把它转成了字面字符串 "null"。作者解释，Android 的 org.json 使用 JSONObject.NULL 作为哨兵对象，与 JVM 上的 json.org 实现并不一致，所以同样的断言在电脑端测试可能通过，在设备上却失败。问题根源来自 PHP API：LEFT JOIN 和聚合函数在没有数据时会产生 SQL NULL，随后被序列化成 JSON null。正确做法是两端一起修：服务端在输出边界做归一化或用 COALESCE 处理，客户端则不要直接调用 optString，而应封装带空值判断的 helper。

「null」這個字不是空值：JSON null 在 Android 上如何變成文字

在 Android 上，optString 遇到 JSON null 不會回傳 ""，而是回傳字串 "null"。

重點摘要

JSONObject.NULL 不是 Java null，會被 optString 轉成文字

JVM 上的 json.org 與 Android 的 org.json 行為可能不同

要同時修正 API 邊界與用戶端包裝函式

這篇文章指出，Android App 之所以在個人資料頁顯示「null」，是因為 JSONObject.optString() 遇到 JSON null 時，回傳的不是預設值，而是字面字串 "null"。作者說明 Android 的 org.json 使用 JSONObject.NULL 作為哨兵值，和 JVM 上的 json.org 實作不完全相同，因此桌面測試可能通過、裝置上卻失敗。問題源頭其實來自 PHP API：LEFT JOIN 與聚合函式在沒有資料時會產生 SQL NULL，序列化後變成 JSON null。解法必須雙管齊下：伺服器端在輸出邊界做正規化或以 COALESCE 補值，客戶端則不要直接呼叫 optString，而是包成帶 null 檢查的 helper。

Cooperative by Design: The Deep Mechanics of Kotlin Coroutine Cancellation

Medium Kotlin 作者：Android Expert 發布：08-30 08:24

Cooperative by Design: The Deep Mechanics of Kotlin Coroutine Cancellation

Why job.cancel() doesn’t guarantee cleanup, and the patterns that make cancellation actually safe in production Android apps.

重點摘要

Cancellation in Kotlin coroutines is cooperative, not immediate.

Calling job.cancel() does not automatically guarantee cleanup work will run.

Safe production Android code depends on specific cancellation patterns.

This article explains that Kotlin coroutine cancellation is cooperative by design, meaning a cancelled job must reach a cancellation point before it actually stops. As a result, calling job.cancel() does not guarantee cleanup will happen automatically or immediately. The piece focuses on the practical mechanics behind cancellation and the patterns Android developers should use to make it safe in production apps, emphasizing disciplined handling rather than assuming cancellation alone is enough.

以协作式设计看 Kotlin 协程取消：深层机制解析

为什么 job.cancel() 不能保证清理一定发生，以及让取消在生产级 Android 应用中真正安全的做法。

重點摘要

Kotlin 协程的取消是协作式，而不是立即终止。

调用 job.cancel() 并不意味着清理一定会自动执行。

生产环境中的安全取消需要配合特定模式与实践。

本文说明，Kotlin 协程的取消采用协作式设计，协程必须运行到取消检查点才会真正停止。因此，单独调用 job.cancel() 并不能保证清理工作一定会立即或自动发生。文章着重解析取消背后的机制，以及 Android 开发者在生产环境中应采用哪些模式来确保取消安全，强调不能把取消视为万能方案，而应结合正确的处理方式与设计。

以合作式設計看 Kotlin 協程取消：深入機制解析

為什麼 job.cancel() 不保證清理一定會發生，以及在正式版 Android App 中讓取消真正安全的做法。

重點摘要

Kotlin 協程的取消是合作式，而非立即中止。

呼叫 job.cancel() 不代表清理流程一定會自動執行。

在生產環境中需搭配正確模式，才能讓取消更安全。

本文指出，Kotlin 協程的取消機制是合作式設計，協程必須走到取消檢查點才會真正停止。因此，單純呼叫 job.cancel() 並不保證清理工作會立即或自動完成。文章聚焦於取消背後的實作邏輯，以及 Android 開發者在正式環境中應採用的安全模式，強調不能只依賴取消本身，而要以正確的流程與設計來避免風險。

SafetyNet Is Dead: Detecting Tampered Devices with Play Integrity API

Medium Kotlin 作者：Alim Reshitov 發布：08-30 08:26

SafetyNet Is Dead: Detecting Tampered Devices with Play Integrity API

The migration every banking app was forced to make, and why the client-side token is only half the job.

重點摘要

Banking apps had to migrate away from SafetyNet.

Play Integrity API is used to detect tampered devices.

Client-side tokens alone are not sufficient.

This article focuses on the migration banking apps were forced to make after SafetyNet, and introduces the Play Integrity API as the replacement for detecting tampered devices. It emphasizes that obtaining a client-side token is only part of the security process, implying that additional validation is needed beyond what happens on the device. The piece frames this as a practical shift for banking applications that must protect against device tampering and related risks.

SafetyNet 已死：使用 Play Integrity API 检测被篡改的设备

这是每个银行 App 都被迫完成的迁移，而客户端 token 只完成了一半工作。

重點摘要

银行 App 被迫从 SafetyNet 迁移。

改用 Play Integrity API 检测设备是否被篡改。

仅靠客户端 token 还不够。

本文讨论了银行应用在 SafetyNet 退场后被迫进行的迁移，并介绍如何借助 Play Integrity API 来检测设备是否遭到篡改。文章指出，获取客户端 token 只是整个安全流程的一部分，不能把它当作完整的信任依据；为了确保设备与请求的真实性，仍需要结合更多验证措施。整体上，这是一篇面向金融类 Android 应用安全实践的说明。

SafetyNet 已死：使用 Play Integrity API 偵測被竄改的裝置

這是每個銀行 App 都被迫進行的遷移，而客戶端 token 只完成了一半工作。

重點摘要

銀行 App 被迫從 SafetyNet 轉移。

改以 Play Integrity API 偵測裝置是否被竄改。

客戶端 token 並不足以完成整個驗證流程。

本文聚焦於銀行 App 在 SafetyNet 退場後被迫進行的遷移，並以 Play Integrity API 作為偵測裝置是否遭竄改的替代方案。文章強調，取得客戶端 token 只是安全流程的一部分，真正的驗證仍需要更多後端或額外檢查，不能只依賴裝置端回傳的結果。這反映出金融應用在裝置完整性防護上的實務轉變。

Under the Hood of Android ViewModel: How State Survives Orientation Changes & Building Your Own…

Medium Kotlin 作者：Aslam Hossin 發布：08-30 15:02

Inside Android ViewModel: How State Survives Orientation Changes and Building Your Own

A source-guided deep dive into Android runtime internals, AOSP ActivityThread, and the NonConfigurationInstances mechanism.

重點摘要

Explains how Android ViewModel preserves state across configuration changes

Explores runtime internals, including AOSP ActivityThread and NonConfigurationInstances

Provides an educational path for understanding and building a similar mechanism

This article offers a source-guided deep dive into Android runtime internals to explain how ViewModel survives orientation changes. It examines the AOSP ActivityThread and the NonConfigurationInstances mechanism as the core pieces behind state retention, then uses that understanding to build an educational version of the idea. The piece is framed as a technical exploration of how Android manages lifecycle changes without losing important state, making it useful for readers who want to understand the platform beneath the ViewModel abstraction.

深入 Android ViewModel：状态如何在屏幕旋转时保持，以及如何自己实现

一篇以源码为线索的深度解析，探讨 Android 运行时内部、AOSP ActivityThread 与 NonConfigurationInstances 机制。

重點摘要

说明 Android ViewModel 如何在配置变更中保留状态

解析 Android 运行时内部与 NonConfigurationInstances 机制

以教学方式展示如何理解并构建类似机制

本文以源码为线索，深入解析 Android 运行时内部运作，说明 ViewModel 为什么能在屏幕旋转等配置变更时保持状态。文章聚焦 AOSP ActivityThread 和 NonConfigurationInstances 机制，将它们视为状态延续的关键，并在理解这些基础后进一步构建一个具有教学意义的实现。整体内容适合希望从底层理解 ViewModel 与 Android 生命周期关系的读者。

深入 Android ViewModel：狀態如何在螢幕旋轉時保存，以及如何自行實作

一篇以原始碼為線索的深度解析，探討 Android 執行階段內部、AOSP ActivityThread 與 NonConfigurationInstances 機制。

重點摘要

說明 Android ViewModel 如何在設定變更中保留狀態

解析 Android 執行階段內部與 NonConfigurationInstances 機制

以教學角度示範如何理解並建立類似機制

本文以原始碼為線索，深入解析 Android 執行階段內部運作，說明 ViewModel 為何能在螢幕旋轉等設定變更時保留狀態。文章聚焦於 AOSP ActivityThread 與 NonConfigurationInstances 機制，將其視為狀態延續的關鍵，並在理解這些基礎後，進一步建立一個具教育意義的實作。整體內容適合想從底層理解 ViewModel 與 Android 生命週期關係的讀者。

Engineering Geofencing: Trading Battery for Precision in Android

Dev.to Kotlin 作者：Haseeb 發布：08-30 02:27

Engineering Geofencing: Trading Battery for Precision in Android

I had to choose between battery life and location precision, and geofencing offered the best balance.

重點摘要

Muffle was built to prevent embarrassing sound mishaps by automating audio profiles based on location.

GeofencingClient was chosen over manual polling because it is more battery-efficient, despite some latency.

The app adds reboot recovery, GPS drift buffering, and Wi‑Fi-based validation to improve reliability.

This article explains how the Muffle Android app uses geofencing to automatically switch sound profiles in places like meetings, libraries, and religious services. The author chose Google Play Services’ GeofencingClient over constant LocationManager polling to reduce battery drain, accepting some latency in exchange for efficiency. To improve accuracy, the implementation uses a 60-second loitering delay, re-registers geofences after reboot, and adds a five-minute buffer before restoring audio on exit. The article concludes that no single sensor is enough for dependable context-aware automation; practical background features should balance convenience, battery life, and real-world signal unreliability.

Android 地理围栏工程：用电量换取精度

我必须在电池续航和定位精度之间做出取舍，而 geofencing 提供了最佳平衡。

重點摘要

Muffle 的目标是在会议、图书馆或宗教场合自动切换静音，避免误响带来的尴尬。

作者选择 GeofencingClient 而不是持续轮询定位，因为它更省电，但会带来一定延迟。

通过开机重注册、GPS 漂移缓冲和 Wi‑Fi 网络名辅助判断，提升了可靠性。

本文讲述作者开发 Muffle 的过程：通过地理围栏在特定地点自动切换手机音量，减少在会议、图书馆或宗教活动中误响的尴尬。由于 Android 上高精度定位会严重耗电，作者选择 Google Play Services 的 GeofencingClient 来让系统承担更多工作，接受一定延迟以换取更好的续航。实现中还加入了 60 秒 loitering delay、设备重启后的 geofence 重新注册，以及在退出区域后延迟恢复音量的缓冲机制，以减少 GPS 漂移导致的误判。作者总结，情境自动化不能只信任单一传感器，必须通过多层验证平衡便利性与稳定性。

Android 地理圍欄工程：以電量換取精準度

我必須在電池續航與定位精準之間取捨，而 geofencing 提供了最佳平衡。

重點摘要

Muffle 旨在避免在會議、圖書館或宗教場合誤響，並自動切換音量模式。

作者選擇 GeofencingClient 取代持續輪詢，因為它更省電，但會帶來些許延遲。

為了提升可靠性，加入開機重註冊、GPS 漂移緩衝與 Wi‑Fi 網路名稱輔助判斷。

本文分享作者打造 Muffle 的經驗：透過地理圍欄，在會議、圖書館或宗教場合自動切換手機音量。由於 Android 持續高精度定位非常耗電，作者改採 Google Play Services 的 GeofencingClient，以較低功耗換取可接受的觸發延遲，並設定 60 秒 loitering delay 確認使用者真的停留在現場。為避免 GPS 漂移造成誤判，系統在退出後還會加入緩衝時間，且會在開機後重新註冊 geofence。作者強調，情境自動化不能只依賴單一感測器，必須用多層驗證來兼顧便利與穩定。

How we adapted our bottom navigation into a navigation rail in KMP

Dev.to Kotlin 作者：Arfin Hosain 發布：08-30 03:47

How We Adapted Our Bottom Navigation into a Navigation Rail in KMP

Going from phone-only to phone-and-tablet cost us one new container file and one small shared function — not a second codebase.

重點摘要

One shared width check decides whether to show the bottom bar or the rail.

The rail reuses the same destinations, tab items, animations, and haptics.

KMP and Compose Multiplatform kept the phone and tablet layouts in one shared codebase.

Foster, a relationship check-in app built with Kotlin Multiplatform and Compose Multiplatform, needed a tablet-friendly navigation pattern when the phone-style bottom bar looked stretched on larger screens. The team added a navigation rail with minimal new code: one app-shell check chooses between bottom bar and rail, while a shared width-class function determines when the window is “tablet-sized.” Most of the rail reuses the existing bottom navigation logic, including destinations, visuals, animations, and haptics. The article argues that with shared UI and logic, adapting to a new device size is mostly a matter of reusing decisions already made rather than building a separate implementation.

我们如何在 KMP 中将底部导航改造成 Navigation Rail

从仅支持手机到同时支持手机和平板，只增加了一个容器文件和一个小型共享函数。

重點摘要

通过一次共享的宽度判断，决定显示底部导航栏还是侧边 rail。

Rail 几乎完全复用了既有的目的地、动画、颜色和触觉反馈。

KMP 与 Compose Multiplatform 让手机和平板布局共用同一套代码。

Foster 是一款使用 Kotlin Multiplatform 和 Compose Multiplatform 开发的关系打卡应用。它在平板上测试时，原本的手机式底部导航栏显得过于拉伸，因此团队以很少的新代码加入了侧边 navigation rail。应用外壳只需一次宽度判断，就能在底部导航栏和 rail 之间切换；共享模块中的 width size class 函数则统一决定何时算作平板尺寸。大部分 rail 逻辑直接沿用现有导航栏，包括目的地、视觉样式、动画和触觉反馈。文章强调，在共享 UI 和逻辑的前提下，支持新的设备尺寸更多是复用既有决策，而不是重做一个版本。

我們如何在 KMP 中將底部導覽改造成 Navigation Rail

從僅支援手機到同時支援手機與平板，只多了一個容器檔案和一個小型共享函式。

重點摘要

用一次共享的寬度判斷，決定顯示底部導覽列或側邊 rail。

Rail 幾乎完全重用既有的目的地、動畫、顏色與觸覺回饋。

KMP 與 Compose Multiplatform 讓手機和平板版面共用同一套程式碼。

Foster 是一款以 Kotlin Multiplatform 與 Compose Multiplatform 開發的關係打卡應用。當它在平板上測試時，原本的手機式底部導覽列顯得過度拉伸，因此團隊以極少的新程式碼加入側邊 navigation rail。應用外殼只需一次寬度判斷，即可在底部導覽列與 rail 間切換；共享模組中的 width size class 函式則統一決定何時視為平板尺寸。大部分 rail 邏輯直接沿用既有導覽列，包括目的地、樣式、動畫與觸覺回饋。文章強調，在共享 UI 與邏輯下，支援新裝置尺寸多半只是重用既有決策，而非重做一個版本。

Kotlin Weekly #526

Kotlin Weekly 作者：發布：08-30 05:58

Kotlin Weekly #526

JetBrains has rolled out version 1.12.0, featuring an experimental MCP server for AI coding agents in Compose Hot Reload, automatic font fallback for web targets, and a v2 API providing finer control over desktop window and dialog states.

重點摘要

Compose Multiplatform 1.12.0 adds experimental AI-agent MCP support in Hot Reload

Articles cover jOOQ code generation from Flyway migrations and a compile-safe mobile mock server

The issue also highlights Android build optimization, Kotlin talks, and new KMP libraries

Kotlin Weekly #526 (30 August 2026) highlights Compose Multiplatform 1.12.0, which introduces an experimental MCP server for AI coding agents in Compose Hot Reload, automatic font fallback for web targets, and a v2 API for more precise desktop window and dialog control. The issue also links to practical articles on generating jOOQ code from Flyway migration files without a live database and building a compile-safe mock server for mobile apps. Additional sections cover Android optimization case studies, Kotlin videos on AI-era teaching and multiplatform integration, and a wide range of new libraries for serialization, UI protection, architecture analysis, secrets detection, and KMP graphics.

Kotlin Weekly #526

JetBrains 发布了 1.12.0 版本，包含面向 Compose Hot Reload 的 AI 编码代理实验性 MCP 服务器、Web 目标的自动字体回退，以及用于更细致控制桌面窗口和对话框状态的 v2 API。

重點摘要

Compose Multiplatform 1.12.0 为 Hot Reload 增加了面向 AI 代理的实验性 MCP 支持

文章涵盖从 Flyway migration 生成 jOOQ 代码，以及适用于移动端的编译安全 mock server

本期还包括 Android 优化案例、Kotlin 相关视频和多款新的 KMP 库

Kotlin Weekly #526（2026 年 8 月 30 日）重点介绍 Compose Multiplatform 1.12.0：新增面向 AI 编码代理的实验性 MCP server、Web 目标的自动字体回退，以及可更精细控制桌面窗口和对话框状态的 v2 API。期刊还推荐了两篇实用文章：一篇讲解如何直接基于 Flyway SQL migration 生成 jOOQ 代码，避免依赖真实数据库；另一篇介绍为移动应用构建编译安全的 mock HTTP server。除此之外，还有 Android 构建优化案例、KotlinConf 相关视频，以及覆盖序列化、界面保护、架构规则、密钥检测和 KMP 图形封装等主题的多个新库。

Kotlin Weekly #526

JetBrains 釋出 1.12.0，包含為 Compose Hot Reload 的 AI 程式代理提供的實驗性 MCP 伺服器、Web 目標的自動字型回退，以及可更細緻控制桌面視窗與對話框狀態的 v2 API。

重點摘要

Compose Multiplatform 1.12.0 新增 Hot Reload 的 AI 代理實驗性 MCP 支援

文章涵蓋以 Flyway migration 產生 jOOQ 程式碼，以及可編譯安全的行動端 mock server

本期也收錄 Android 效能優化案例、Kotlin 講座與多個新 KMP 函式庫

Kotlin Weekly #526（2026 年 8 月 30 日）重點介紹 Compose Multiplatform 1.12.0：新增供 AI 程式代理使用的實驗性 MCP server、Web 目標的自動字型回退，以及可更精細控制桌面視窗與對話框狀態的 v2 API。內容同時收錄實務文章，包含如何直接從 Flyway SQL migration 產生 jOOQ 程式碼而不必依賴正式資料庫，以及為行動應用打造可編譯安全的 mock 伺服器。另有 Android 最佳化案例、AI 時代的 Kotlin 教學影片與多款涵蓋序列化、UI 保護、架構分析、密鑰掃描和 KMP 圖形的函式庫介紹。

Kotlin Doesn’t Distrust Your Variable. It Refuses to Trust Assumptions It Cannot Prove.

Medium Kotlin 作者：Ahmed Elkrrai 發布：08-30 00:07

Kotlin Doesn’t Distrust Your Variable. It Refuses to Trust Assumptions It Cannot Prove.

Smart casts are one of Kotlin’s most elegant features.

重點摘要

Kotlin smart casts are highlighted as an elegant language feature.

The article’s theme is Kotlin’s insistence on provable assumptions.

The piece frames type safety as the reason Kotlin avoids blind trust.

The article centers on Kotlin’s smart casts and the philosophy behind them. Rather than “distrusting” variables, Kotlin only accepts assumptions it can verify, which helps preserve safety and clarity in code. The headline emphasizes that the language’s behavior is rooted in provable guarantees, not suspicion. Even from the brief excerpt, the core message is that Kotlin’s design favors explicit, checkable logic over unsafe convenience.

Kotlin 不是不信任你的变量，而是拒绝相信无法证明的假设。

Smart cast 是 Kotlin 最优雅的特性之一。

重點摘要

Kotlin 的 smart cast 被认为是极具优雅性的语言特性。

文章强调 Kotlin 只接受能够被证明的假设。

这种设计体现了 Kotlin 对类型安全的重视。

本文围绕 Kotlin 的 smart cast 及其背后的语言理念展开。Kotlin 并不是“怀疑”变量，而是只接受它能够验证的假设，从而维护代码的安全性与清晰度。标题进一步点出，这种行为并非出于不信任，而是基于可证明的保证。就现有内容而言，文章核心是在说明 Kotlin 倾向于用明确、可检查的逻辑，取代不安全的便利写法。

Kotlin 並不是不信任你的變數，而是拒絕相信無法證明的假設。

Smart cast 是 Kotlin 最優雅的特性之一。

重點摘要

Kotlin 的 smart cast 被視為非常優雅的語言特性。

文章主旨在於：Kotlin 只接受能被證明的假設。

這種設計反映出 Kotlin 對型別安全的重視。

本文聚焦於 Kotlin 的 smart cast，以及其背後的語言設計哲學。Kotlin 並非「不信任」變數，而是只接受自己能夠驗證的假設，藉此維持程式碼的安全與清晰。標題強調，這不是懷疑，而是建立在可證明保證上的行為。從目前可見的內容來看，文章核心是在說明 Kotlin 如何以明確、可檢查的方式取代不安全的便利性。