每日新聞摘要 - 2026年04月05日

01

Gemma 4 on Android: Complete Developer Guide to On-Device AI

Dev.to Kotlin 作者：rahul patwa 發布：04-05 08:33

Gemma 4 on Android: Complete Developer Guide to On-Device AI

Gemma 4 E2B (2.58 GB) runs under 1.5 GB active memory and streams at 52.1 decode tokens/sec on an S26 Ultra GPU, enabling on-device inference with no API key and no data leaving the device.

重點摘要

E2B fits devices with 6 GB+ RAM; E4B needs 8 GB+ and gives stronger reasoning

Five-step Kotlin integration: Gradle dep, download to filesDir, initialize engine, create conversation, stream via Flow

Choose CPU/GPU/NPU per tradeoffs; implement thermal fallback and watch SamplerConfig Double vs Float and cumulative streaming output

Gemma 4, released April 2, 2026 under Apache 2.0, makes practical on-device LLMs feasible on Android. The E2B variant (2.58 GB) keeps active memory under 1.5 GB and achieves 52.1 decode tokens/sec on an S26 Ultra GPU, so it runs on most devices with 6 GB+ RAM; E4B is larger (3.65 GB), requires 8 GB+ and improves reasoning. Integration is five steps in Kotlin: add com.google.ai.edge.litertlm:litertlm-android, download the model into filesDir, initialize the Engine (blocking call), create a Conversation (SamplerConfig values are Double), and stream responses with sendMessageAsync (emits cumulative text). Backend choice matters: GPU gives peak speed but throttles thermally, NPU offers steadier long-session performance, and CPU works universally. Production gotchas include memory-order init, APK size limits, thermal management, and context-window battery costs. Recommended use cases: private assistants, code review, document Q&A, accessibility, and offline translation.

Gemma 4 在 Android 上：完整开发者指南（设备端 AI）

Gemma 4 E2B（2.58 GB）在 S26 Ultra GPU 上解码速率 52.1 tok/s，主动内存低于 1.5 GB，可在 6 GB+ 设备上实现本地推理且数据不离开设备。

重點摘要

E2B 适配多数 6 GB+ 设备；E4B 提升推理能力但需 8 GB+

Kotlin 五步骤整合：Gradle 依赖、下载到 filesDir、初始化引擎、创建 Conversation、用 Flow 串流响应

后端选择权衡：GPU 峰值快但会热降频，NPU 长时表现稳，SamplerConfig 为 Double，sendMessageAsync 输出为累计文本

本文提供在 Android 上使用 Gemma 4 与 LiteRT‑LM 实现设备端 LLM 的完整指南。Gemma 4 于 2026 年 4 月发布（Apache 2.0），E2B 变体文件 2.58 GB、主动内存低于 1.5 GB，在 S26 Ultra GPU 上可达 52.1 decode tok/s，适用于 6 GB 及以上设备；E4B 文件更大、推理能力显著更强但需要至少 8 GB 内存。整合流程简化为五步：添加 com.google.ai.edge.litertlm 依赖、首次启动下载模型到 filesDir、在后台初始化 Engine（阻塞）、创建 Conversation（注意 SamplerConfig 参数为 Double）、用 sendMessageAsync 通过 Kotlin Flow 串流并注意其累计输出。文章还讨论了 CPU/GPU/NPU 的性能与热管理策略、生产环境陷阱（内存顺序、APK 大小、热降频和上下文窗口电量增长）以及适合的应用场景，如私有助理、代码审查、文档问答与离线翻译。

Gemma 4 在 Android 上：完整開發者指南（離線 AI）

Gemma 4 E2B（2.58 GB）在 S26 Ultra GPU 上解碼速率為 52.1 tok/s、主動記憶體低於 1.5 GB，能在 6 GB+ 設備上實現真正的本地推論且資料不出裝置。

重點摘要

E2B 適合大多數 6 GB+ 裝置，E4B 提升推理但需 8 GB+

五步 Kotlin 整合：Gradle 依賴、下載到 filesDir、初始化 Engine、建立 Conversation、以 Flow 串流回應

後端取捨關鍵：GPU 快但熱降頻，NPU 長時穩定，SamplerConfig 用 Double，sendMessageAsync 回傳累積文字

本文說明如何在 Android 上以 Gemma 4 + LiteRT‑LM 建置可上線的本地 LLM。作者指出 E2B 變體檔案 2.58 GB、主動記憶體 <1.5 GB，可在 6 GB 以上裝置運行並在 S26 Ultra GPU 達到 52.1 tok/s；E4B 檔案更大（3.65 GB）、記憶體約 2 GB、但推理品質顯著提升。整合流程可在數小時內完成：加入 litertlm-android 依賴、於首次啟動下載模型到 filesDir、在背景執行初始化（為阻塞呼叫）、以 Conversation + SamplerConfig（參數為 Double）建立會話，並以 sendMessageAsync 透過 Flow 串流回應（每次發射為累積文字）。實務注意事項包括記憶體初始化順序、APK 大小限制、熱降頻處理與長對話電量增長，適合隱私敏感且需低延遲的應用場景。

02

Robust BLE: Preventing Disconnections and Implementing Auto-Reconnect on Android 12+ with Foreground Services

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:21

Robust BLE: Preventing Disconnections and Implementing Auto-Reconnect on Android 12+ with Foreground Services

Use a Foreground Service (connectedDevice type) plus a manual auto-reconnect loop to keep BLE connections alive on Android 12+.

重點摘要

Use a Foreground Service with connectedDevice type and a persistent notification to reduce OS kills.

Implement manual reconnects with connectGatt(autoConnect=false), backoff and max attempts; close stale GATTs first.

Declare and request Android 12+ permissions (BLUETOOTH_SCAN, BLUETOOTH_CONNECT) and handle BluetoothAdapter state changes.

Android 12+ tightens background execution and can silently kill background processes, causing critical BLE connections to drop. This article shows how to maintain reliable BLE links by running your BLE logic inside a Foreground Service (foregroundServiceType=connectedDevice) with a persistent notification so the OS treats the work as user-perceivable. It details required manifest entries and runtime permissions (BLUETOOTH_SCAN/BLUETOOTH_CONNECT), and provides a Kotlin BleConnectionService example that starts in foreground, manages BluetoothGatt instances, and implements a manual auto-reconnect loop using connectGatt with autoConnect=false, linear backoff, and a maximum number of attempts. Key practices include closing and nulling old GATTs before reconnecting, checking status codes in onConnectionStateChange, listening for BluetoothAdapter state changes, using ContextCompat.startForegroundService and START_REDELIVER_INTENT, and exposing connection state to the UI (LiveData/SharedFlow) for production-ready IoT reliability.

稳健的 BLE：在 Android 12+ 使用前台服务防止断连并实现自动重连

透过 connectedDevice 类型的 Foreground Service 和主动重连逻辑，可在 Android 12+ 背景下维持可靠的 BLE 连接。

重點摘要

前台服务（connectedDevice）加固定通知可降低系统终止后台进程的风险。

采用 connectGatt(autoConnect=false)，在关闭旧 GATT 后以重试与退避策略主动重连。

声明并申请 Android 12+ 的 BLUETOOTH_SCAN/BLUETOOTH_CONNECT 权限，並监听蓝牙适配器状态。

Android 12+ 加强了背景执行限制，系统可能在后台静默终止进程导致 BLE 连接断开。文章建议将 BLE 逻辑放在前台服务（foregroundServiceType=connectedDevice）并显示持续通知，使系统将任务视为用户可感知；示例以 Kotlin 实现 BleConnectionService，展示如何启动前台服务、管理 BluetoothGatt、在断开时关闭旧 GATT、并使用 connectGatt(autoConnect=false) 配合线性退避与最大重试次数进行主动重连。文中还说明必须在 Manifest 与运行时处理 BLUETOOTH_SCAN/BLUETOOTH_CONNECT 权限、使用 ContextCompat.startForegroundService 与 START_REDELIVER_INTENT，并建议将连接状态透过 LiveData/SharedFlow 通知 UI 以提升 IoT 应用的生产可靠性。

強固的 BLE：在 Android 12+ 使用前景服務防止斷線並實作自動重連

以 connectedDevice 類型的 Foreground Service 加上主動重連機制，可在 Android 12+ 背景下維持穩定的 BLE 連線。

重點摘要

前景服務（connectedDevice）與固定通知可降低系統終止背景程序的機率。

使用 connectGatt(autoConnect=false) 並在關閉舊 GATT 後以重試/退避策略主動重連。

在 Manifest 與執行時處理 BLUETOOTH_SCAN、BLUETOOTH_CONNECT 權限並監控藍牙狀態變更。

Android 12 之後對背景執行限制更嚴格，App 背景進程可能被系統終止，導致 BLE 連線無預警斷開。文章建議以 Foreground Service（foregroundServiceType=connectedDevice）並顯示固定通知，讓系統不易殺掉服務；同時在 Kotlin 範例中示範如何管理 BluetoothGatt、關閉舊 GATT、在 onConnectionStateChange 檢查 status、用 connectGatt(autoConnect=false) 實作主動重連與線性退避與最大重試次數。並說明 AndroidManifest 與執行時 BLUETOOTH_SCAN/BLUETOOTH_CONNECT 權限、使用 ContextCompat.startForegroundService 與 START_REDELIVER_INTENT，以及建議透過 LiveData/SharedFlow 回報連線狀態以利 UI 顯示與生產環境可靠性。

03

Mastering Android 12+ BLE Permissions in Kotlin: The `BLUETOOTH_SCAN`/`CONNECT` Dance and Common Gotchas

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:23

Mastering Android 12+ BLE Permissions in Kotlin: BLUETOOTH_SCAN, BLUETOOTH_CONNECT and Common Pitfalls

Android 12 decouples BLE from location: use BLUETOOTH_SCAN/CONNECT/ADVERTISE as runtime permissions and add neverForLocation to avoid unnecessary location prompts.

重點摘要

Android 12+ replaces ACCESS_FINE_LOCATION for BLE with BLUETOOTH_SCAN, BLUETOOTH_CONNECT and BLUETOOTH_ADVERTISE

Declare permissions in the manifest (use neverForLocation for BLUETOOTH_SCAN) and request them at runtime

Keep targetSdk >= 31, check Bluetooth state and device Location Services, and request only needed permissions

This article walks through the Android 12+ BLE permission changes and how to implement them in Kotlin. Prior to API 31 many BLE operations relied on ACCESS_FINE_LOCATION; Android 12 introduced granular runtime permissions—BLUETOOTH_SCAN (discover devices), BLUETOOTH_CONNECT (connect), and BLUETOOTH_ADVERTISE (advertise)—so apps can avoid requesting sensitive location access when it’s not needed. Key implementation notes include declaring both legacy and new permissions in AndroidManifest.xml, using android:usesPermissionFlags="neverForLocation" for BLUETOOTH_SCAN when your app does not derive location, and updating targetSdk to 31+ so the new model applies. At runtime, check and request the appropriate permissions per OS version, verify Bluetooth is enabled, and on some devices also require device Location Services. Best practices: request only the permissions you need, show rationale when appropriate, detect persistent denials and guide users to settings, and thoroughly test across Android versions and OEMs.

掌握 Android 12+ 的 BLE 权限（Kotlin）：BLUETOOTH_SCAN/CONNECT 的使用与常见坑点

Android 12 将 BLE 功能与位置权限分离：在 Manifest 与运行时使用 BLUETOOTH_SCAN/CONNECT/ADVERTISE，并为 BLUETOOTH_SCAN 添加 neverForLocation。

重點摘要

Android 12+ 用 BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE 取代多数 BLE 的 ACCESS_FINE_LOCATION

在清单中声明新权限并在运行时请求；若不使用位置功能，BLUETOOTH_SCAN 应加 neverForLocation

确保 targetSdk >= 31、检查蓝牙与设备位置服务，并只请求确实需要的权限

本文解析 Android 12 及以上版本对 BLE 权限的调整，并提供 Kotlin 实作步骤。过去 BLE 扫描常依赖 ACCESS_FINE_LOCATION，Android 12 引入更细化的权限（BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE），使应用可在不要求敏感定位权限的前提下执行蓝牙操作。要点包括在 AndroidManifest 中同时兼容旧版与新版权限、为 BLUETOOTH_SCAN 添加 android:usesPermissionFlags="neverForLocation"、并将 targetSdk 提升到 31+ 以启用新模型。运行时需根据系统版本请求相应权限、确认蓝牙已启用并在必要时提示开启设备位置服务。最佳实践是仅请求必需权限、提供清晰理由并在用户持久拒绝时引导到应用设置。

精通 Android 12+ 的 BLE 權限（Kotlin）：BLUETOOTH_SCAN／CONNECT 的變化與常見陷阱

Android 12 將 BLE 操作從位置權限中拆分出來：在 Manifest 與執行時使用 BLUETOOTH_SCAN/CONNECT/ADVERTISE，並對 BLUETOOTH_SCAN 加上 neverForLocation。

重點摘要

Android 12+ 用 BLUETOOTH_SCAN/CONNECT/ADVERTISE 取代多數 BLE 的 ACCESS_FINE_LOCATION

在 Manifest 宣告新權限並於執行時請求；BLUETOOTH_SCAN 建議加上 neverForLocation

務必將 targetSdk 設為 31+、檢查藍牙與裝置位置服務，並僅請求必要權限

本文說明 Android 12（API 31）後 BLE 權限模型的改變與 Kotlin 實作要點。過去多數 BLE 操作倚賴 ACCESS_FINE_LOCATION，但 Android 12 引入更細緻的 BLUETOOTH_SCAN（掃描）、BLUETOOTH_CONNECT（連線）與 BLUETOOTH_ADVERTISE（廣播）等執行時權限，能避免不必要的地理位置授權。在 Manifest 中需兼顧舊版與新版權限，對 BLUETOOTH_SCAN 使用 android:usesPermissionFlags="neverForLocation" 以明確宣示不取位址。此外必須把 targetSdk 提升到 31+ 才會套用新模型；執行時依系統版本請求權限、檢查藍牙狀態與裝置位置服務，並採取最小授權、提供適當說明與前往設定的引導以改善使用者體驗。

04

Mastering Disconnection Handling in Android BLE: Robust Strategies for Reconnection and Error Recovery

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:27

Mastering Disconnection Handling in Android BLE: Robust Strategies for Reconnection and Error Recovery

Learn how to detect disconnection types, implement intelligent reconnection strategies, manage GATT resources, and gracefully recover from common BLE errors.

重點摘要

Inspect onConnectionStateChange status codes to determine disconnection causes.

Always call BluetoothGatt.close() and null references to avoid leaks and stale caches.

Use a clear state machine plus exponential backoff retries with a maximum attempt limit.

Bluetooth Low Energy (BLE) on Android is fragile; unexpected disconnects from range, power-off, OS kills or stack bugs cause app failures. This article explains how to diagnose disconnections via BluetoothGattCallback.onConnectionStateChange, emphasizing the status code (e.g., 0, 19 for clean disconnects; 133 for unexpected errors) and how interpreting it informs recovery. It details proper GATT resource cleanup—calling BluetoothGatt.close() and nulling references to avoid leaks and stale caches—and recommends using a clear state machine to avoid race conditions. For reconnection, implement intelligent retries with exponential backoff, a max-attempt limit, and avoid autoConnect=true for immediate foreground reconnection. It also covers permission requirements across Android versions and common pitfalls (ignoring status codes, not closing GATT, misusing autoConnect, poor state management, and lack of backoff). Following these strategies produces more resilient, production-ready BLE apps.

掌握 Android BLE 断线处理：重连与错误恢复的稳健策略

了解如何检测断线类型、实现智能重连策略、管理 GATT 资源，并从常见 BLE 错误中优雅恢复。

重點摘要

在 onConnectionStateChange 中解析 status 代码以判断断线类型与恢复策略。

断线时调用 BluetoothGatt.close() 并将引用设为 null，避免资源泄漏与缓存问题。

使用明确定义的状态机并以指数回退和最大尝试次数实现重连。

Android 上的 BLE 连接容易因超出范围、外设断电、系统终止或蓝牙堆栈问题而中断。本文说明如何在 BluetoothGattCallback.onConnectionStateChange 中解析 status 代码（例如 0、19 表示正常断开；133 常为意外），并据此制定恢复策略；强调断线时调用 BluetoothGatt.close() 并将引用设为 null 以避免资源泄漏和缓存问题；建议以明确定义的状态机避免竞态，并以指数回退与最大尝试次数实现重连。文中亦覆盖不同 Android 版本的权限要求与常见陷阱，帮助构建更稳健的 BLE 应用。

掌握 Android BLE 斷線處理：重連與錯誤復原的穩健策略

學會偵測斷線類型、實作智慧重連策略、妥善管理 GATT 資源，並從常見 BLE 錯誤中優雅復原。

重點摘要

在 onConnectionStateChange 中解析 status 代碼以判斷斷線原因。

斷線時務必呼叫 BluetoothGatt.close() 並將參考設為 null 避免資源外洩與快取問題。

以明確狀態機避免競態，並用指數回退與最大嘗試次數實作重連。

Android 上的 BLE 連線易受範圍、裝置斷電、系統終止或藍牙堆疊錯誤影響而中斷。本文說明如何在 BluetoothGattCallback.onConnectionStateChange 中判讀 status 代碼（例如 0、19 為乾淨斷線；133 表示異常）以決定復原策略；強調在斷線時呼叫 BluetoothGatt.close() 並將參考設為 null 以避免資源外洩與快取混亂；建議以明確的狀態機避免競態，並用指數回退（exponential backoff）與最大嘗試次數實作重連。還涵蓋不同 Android 版本的權限需求與常見陷阱，幫助把 BLE 應用打造得更穩健、實務可用。

05

Mastering `BluetoothGatt` Lifecycle: Preventing Memory Leaks and Stale Connections in Android Kotlin BLE

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:29

Mastering BluetoothGatt Lifecycle: Preventing Memory Leaks and Stale Connections in Android Kotlin BLE

Disconnect() ends the logical connection, but close() must be called to release native BluetoothGatt resources and avoid leaks and stale callbacks.

重點摘要

Always call BluetoothGatt.close() and nullify references to release native resources

Validate the BluetoothGatt instance in every callback to ignore stale/rogue callbacks

Use autoConnect=false for user-initiated connections and ensure main-thread/thread-safety

Android's BluetoothGatt represents the GATT client and holds native system resources; mismanaging its lifecycle leads to memory leaks, phantom callbacks, and unreliable reconnections. This article clarifies the crucial difference between disconnect() (a graceful logical disconnection) and close() (the mandatory resource deallocation), and demonstrates a Kotlin BleConnectionManager that maintains a single active BluetoothGatt, validates incoming callbacks against the current instance, and performs deterministic cleanup by calling gatt.close() and clearing references. It also emphasizes threading rules (invoke GATT operations on the main thread or a dedicated handler), careful use of autoConnect (prefer false for active, user-initiated connections), and correct runtime permissions. Following these practices prevents stale connections and hard-to-debug errors, making BLE interactions more robust for production IoT apps.

精通 BluetoothGatt 生命周期：在 Android Kotlin BLE 中防止内存泄漏与过期连接

disconnect() 负责逻辑断连，而 close() 必须调用以释放 BluetoothGatt 的原生资源，否则会导致泄漏和陈旧回调。

重點摘要

对每个 BluetoothGatt 实例务必调用 close() 并清除引用

在回调中验证 gatt 实例以忽略过期或非当前管理的回调

在主线程或专用 Handler 执行 GATT 操作，用户触发连接建议 autoConnect=false

BluetoothGatt 在 Android 中表示 GATT 客户端并持有底层原生资源，若生命周期处理不当会引发内存泄漏、幻影回调和无法重连的问题。本文阐明 disconnect()（逻辑断连）与 close()（释放资源）之间的关键差别，展示一个 Kotlin 的 BleConnectionManager：维护单一 BluetoothGatt 实例、在回调中校验实例、在断开或发生错误时调用 close() 并将引用设为 null，同时强调主线程调用 GATT 操作、谨慎使用 autoConnect 和申请运行时权限。遵循这些原则可避免资源滞留与不稳定行为，提高 BLE 应用在生产环境中的健壮性。

精通 BluetoothGatt 生命週期：在 Android Kotlin BLE 中預防記憶體洩漏與過期連線

disconnect() 處理邏輯斷線，close() 則必須呼叫以釋放 BluetoothGatt 的原生資源，否則會造成洩漏與過期回呼。

重點摘要

對每個 BluetoothGatt 實例務必呼叫 close() 並清除參考

在每個回呼中驗證 gatt 實例以忽略過期或非管理中的回呼

主要執行緒呼叫 GATT 操作，且對 user-initiated 連線建議使用 autoConnect=false

BluetoothGatt 在 Android 中代表 GATT 客戶端並持有原生系統資源，若未正確管理會導致記憶體洩漏、幽靈回呼及重連失敗。本文說明 disconnect()（邏輯斷線）與 close()（釋放資源）間的關鍵差別，並提供 Kotlin 的 BleConnectionManager 範例：維持單一 BluetoothGatt 實例、在回呼內驗證 gatt、於斷線或錯誤時呼叫 close() 並將引用設為 null，同時強調主線程或專用 Handler 執行 GATT 操作、謹慎使用 autoConnect 與處理執行時權限。採用這些做法可避免資源無法回收與不穩定的 BLE 行為，提升 IoT 應用的可靠性。

06

Why Your Android BLE Advertisements Silently Fail in the Background on Android 12+ and How to Fix It

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:31

Why Android BLE Advertisements Stop Silently in Background on Android 12+ and How to Fix It

BLUETOOTH_ADVERTISE grants advertising ability but does not exempt you from Android 12+ background execution limits—use a Foreground Service and correct permissions to keep advertising reliably.

重點摘要

Android 12+ enforces stricter background execution limits that can silently stop BLE advertising

BLUETOOTH_ADVERTISE is a new runtime permission but does not override background throttling or OEM-only exemptions

Use a Foreground Service, correct manifest/runtime permissions, low-power advertise settings, and lifecycle handling

Modern Android (12+) tightens background execution and can silently stop BluetoothLeAdvertiser when an app is backgrounded. The new runtime permissions (BLUETOOTH_ADVERTISE, BLUETOOTH_CONNECT, BLUETOOTH_SCAN) are required but do not exempt apps from system background limits; OEM/system permissions (SYSTEM_EXEMPT_FROM_BG_RESTRICTIONS, USE_BLUETOOTH_ADVERTISE_ALWAYS) are not available to ordinary apps. The reliable fix is to target API 31+, declare required permissions (including FOREGROUND_SERVICE and foregroundServiceType on Android 14+), request Bluetooth permissions at runtime, and host advertising in a Foreground Service with a persistent notification. Use low-power advertise modes and low TX power in background, implement robust AdvertiseCallback handling and lifecycle management, monitor Bluetooth state, and attempt restarts when needed. Following these practices significantly improves BLE advertising persistence on modern Android devices.

为什么你的 Android BLE 广播在 Android 12+ 后台会悄然失败，以及如何修复

BLUETOOTH_ADVERTISE 授予广播权限但不能免除 Android 12+ 的后台执行限制——必须使用前台服务并正确处理权限与生命周期，才能保持可靠广播。

重點摘要

Android 12+ 收紧后台执行，系统可能在后台静默停止 BLE 广播

BLUETOOTH_ADVERTISE 是新的运行时权限，但不等于可永远在后台广播

通过前台服务、低功耗广播设置和完整的生命周期与权限管理来提高可靠性

从 Android 12（API 31）起，系统为节省电量与保护隐私收紧了后台执行策略，导致 BluetoothLeAdvertiser 在应用进入后台后可能被系统静默终止。新的运行时权限（BLUETOOTH_ADVERTISE、BLUETOOTH_CONNECT、BLUETOOTH_SCAN）需要在运行时申请，但并不会绕过后台限制；SYSTEM_EXEMPT_FROM_BG_RESTRICTIONS 与 USE_BLUETOOTH_ADVERTISE_ALWAYS 属于系统/OEM 特权，普通应用无法获取。要确保后台广播稳定，需将 targetSdkVersion 提升到 31+，在清单中声明所有权限与 FOREGROUND_SERVICE（Android 14+ 指定 foregroundServiceType），在前台服务中管理 BluetoothLeAdvertiser、使用低功耗与低发射功率参数，并加强 AdvertiseCallback、蓝牙状态监听与重启机制，从而显著提升现代 Android 设备上的 BLE 广播可靠性。

為何你的 Android BLE 廣播在 Android 12+ 背景下會悄然失效，以及如何修正

即便獲得 BLUETOOTH_ADVERTISE 權限也不會免除 Android 12+ 的背景限制；必須搭配前景服務與正確權限與設定，才能穩定在背景廣播。

重點摘要

Android 12+ 強化背景執行限制，系統可能在背景終止廣播

BLUETOOTH_ADVERTISE 是必要的執行時權限，但不等於可持續背景廣播

用前景服務、低功耗廣播參數與完整的權限與生命週期管理來提高穩定性

在 Android 12（API 31）以後，系統為了省電與隱私收緊背景執行，導致 BluetoothLeAdvertiser 在應用進入背景時可能被系統靜默停止。新引入的 BLUETOOTH_ADVERTISE、BLUETOOTH_CONNECT、BLUETOOTH_SCAN 等執行時權限須申請，但無法取代前景服務或 OEM 等級的例外權限。對於一般開發者，正確作法是設定 targetSdkVersion 至 31 以上、在 AndroidManifest 宣告所有必要權限（並於 Android 14+ 指定 foregroundServiceType）、在前景服務中管理廣播、以 ADVERTISE_MODE_LOW_POWER/低功率輸出在背景廣播，並加強 AdvertiseCallback、權限檢查與藍牙狀態監控與重啟策略，以避免廣播悄然中止。

07

Solving the Android BLE GATT Race Condition: Reliable Sequential Operations with Kotlin Coroutines

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:33

Solving the Android BLE GATT Race Condition with Kotlin Coroutines

Enforce strict sequential GATT operations with a coroutine-driven queue to eliminate intermittent BLE failures caused by Android's asynchronous BluetoothGatt API.

重點摘要

BluetoothGatt methods are non-blocking and can cause race conditions if invoked concurrently

Use a single queued processor (Channel) and suspendCancellableCoroutine to serialize operations

Implement timeouts, resource cleanup, and unique IDs to robustly map callbacks to requests

Android's BluetoothGatt API issues (non-blocking read/write/notify calls) often produce intermittent, non-deterministic failures because the stack cannot safely handle concurrent operations. The recommended solution is to serialize every GATT transaction: encapsulate commands as discrete GattOperation objects, enqueue them on a single Channel, and process them one at a time. Bridge callback-based results to coroutines using suspendCancellableCoroutine and CompletableDeferred, letting callers suspend until the BluetoothGattCallback completes each operation. Add per-operation timeouts, explicit disconnect/close handling, and clear error propagation to avoid hangs and leaked resources. For reliability, queue descriptor writes, treat unsolicited notifications separately (SharedFlow), and assign unique IDs to operations to correctly match callbacks. This coroutine-driven queue converts flaky asynchronous BLE interactions into predictable, sequential operations suitable for production use.

使用 Kotlin Coroutines 解决 Android BLE GATT 竞态问题

用协程驱动的串行队列强制 GATT 操作逐一执行，以消除因 Android BluetoothGatt 异步行为导致的间歇性故障。

重點摘要

BluetoothGatt 的读写与通知设置为非阻塞，快速连续调用会引发竞态

以 Channel 串行化操作，并用 suspendCancellableCoroutine 将回调桥接为协程

设置超时、正确释放 GATT 资源并为操作加唯一 ID 可提升鲁棒性

Android 的 BluetoothGatt 方法是非阻塞且由系统内部队列异步执行，若在前一操作完成前发出后续命令，会导致操作被丢弃、回调错配或连接异常。文章提出以 GattOperation 封装每个蓝牙操作，使用单一 Channel 排队并在协程中按序执行，通过 suspendCancellableCoroutine 与 CompletableDeferred 将回调结果转换为可等待的协程返回值。务必为每次操作设置超时、在断连时正确调用 disconnect/close 并完成未决操作，另外将通知事件（onCharacteristicChanged）作为独立流处理，并建议为操作分配唯一标识以可靠匹配回调。此模式能将不确定的 BLE 行为转为可预测的顺序操作，显著提高稳定性。

以 Kotlin Coroutines 解決 Android BLE GATT 競態條件

透過協程驅動的序列化操作隊列，避免 Android BluetoothGatt 非同步呼叫導致的間歇性 BLE 失敗。

重點摘要

BluetoothGatt 的讀寫與設定皆為非阻塞，並可能引發競態條件

以 Channel 與 suspendCancellableCoroutine 將 GATT 操作排成單一序列處理

加入逾時、資源正確釋放與操作唯一識別以確保可靠性

Android 的 BluetoothGatt API 為非同步、非阻塞設計，若在前一個操作尚未完成時又發出新的讀寫或設定命令，容易造成操作被丟棄、內部狀態錯亂或連線斷開。文章建議以 GattOperation 封裝每個操作，使用單一 Channel 作為隊列，並在協程中逐一執行，透過 suspendCancellableCoroutine 與 CompletableDeferred 將 callback 轉為可掛起的協程呼叫。另需實作每次操作逾時、防止資源漏失的 disconnect/close 邏輯、錯誤傳遞機制，以及為操作加上唯一 ID 以正確對應回撥。將非同步 BLE 流程序列化後，可顯著提升穩定性並簡化程式邏輯。

08

Mastering Reliable BLE Characteristic Notifications on Android (Kotlin): Avoiding Missed Updates and Connection Drops

Dev.to Kotlin 作者：Ble Advertiser 發布：04-05 10:35

Mastering Reliable BLE Characteristic Notifications on Android (Kotlin)

Reliable notifications require both enabling local notifications via setCharacteristicNotification and writing the CCCD on the peripheral—missing the descriptor write is a common cause of sporadic updates.

重點摘要

Enable notifications locally AND write the CCCD on the remote device

Request larger MTU early to reduce fragmentation and improve throughput

Persist and re-enable subscriptions after reconnects; manage GATT lifecycle robustly

This article explains how to implement dependable BLE characteristic notifications in Android (Kotlin) by going beyond setCharacteristicNotification. The critical two-step process is emphasized: call BluetoothGatt.setCharacteristicNotification(characteristic, true) and then write BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE to the characteristic's CCCD on the peripheral. It covers the GATT lifecycle and asynchronous callbacks, recommends requesting a larger MTU (to reduce fragmentation and improve throughput), and shows a BleNotificationManager example that stores subscribed UUIDs to re-enable notifications after reconnects. Best practices include robust connection-state management (retries, distinguishing intentional vs. unexpected disconnects, and proper gatt.close()), CCCD write error handling with retries or cleanup, and throttling high-frequency onCharacteristicChanged events to avoid UI freezes. Applying these patterns reduces missed updates and connection drops for more stable IoT apps.

在 Android (Kotlin) 上掌握可靠的 BLE 特征通知

可靠的通知需要两步：对本地调用 setCharacteristicNotification，并向远端特征的 CCCD 写入启用值，忽略任何一步都会导致通知间歇性中断。

重點摘要

本地启用通知并写入远端 CCCD 才能确保外设发送更新

连接后尽早协商更大 MTU 以减少分片并提升吞吐

保存订阅特征并在重连后重新启用通知，妥善管理 GATT 生命周期

本文解析在 Android（Kotlin）中实现可靠 BLE 特征通知的关键点，强调启用通知是两步过程：先在 BluetoothGatt 端调用 setCharacteristicNotification，再向特征的 CCCD 写入 ENABLE_NOTIFICATION_VALUE 才能让外设真正发送数据。文章介绍了 GATT 的异步回调流程、建议在连接建立后立即 requestMtu 以减少数据分片，并以 BleNotificationManager 示例说明如何在 onServicesDiscovered 中依据保存的 UUID 列表重新启用通知。最佳实践包括实现稳健的连接管理（区分主动/非主动断开、重试与 gatt.close() 资源释放）、处理 descriptor 写入错误并重试或回滚，以及对高频 onCharacteristicChanged 事件做去抖或限速，以防止 UI 卡顿与数据丢失，提升物联网应用的稳定性。

在 Android (Kotlin) 上穩定掌握 BLE 特徵通知

在 Android 上可靠接收通知需要兩個步驟：在本地呼叫 setCharacteristicNotification，並向遠端特徵的 CCCD 寫入啟用值，遺漏任一者會造成通知不穩定。

重點摘要

本地啟用通知並寫入 CCCD 才能真正讓外設發送更新

連線後立即協商較大 MTU 以減少分段並提升效率

維持訂閱清單並在重連後重新啟用通知，妥善管理 GATT 生命週期

本文聚焦於在 Android（Kotlin）中建立可靠的 BLE 特徵通知，指出常見錯誤為只呼叫 setCharacteristicNotification 而忘記寫入 CCCD（Client Characteristic Configuration Descriptor）。文章說明 GATT 與 BluetoothGattCallback 的非同步流程，建議在連線後盡早 requestMtu 以降低封包分段，並示範一個 BleNotificationManager 範例：儲存想要訂閱的特徵 UUID，於 onServicesDiscovered 時重啟通知流程。實務要點還包括實作健全的連線狀態機（重試與資源釋放）、處理 descriptor write 的錯誤與重試邏輯，以及對高頻通知做去抖或限速，以避免 UI 卡頓與資料遺失，從而提升 IoT 應用的穩定性與使用者體驗。

09

Why I Killed My DSL Parser for Raw DEX Compilation

Dev.to Kotlin 作者：Elimihele God's favour 發布：04-05 14:38

Why I Killed My DSL Parser for Raw DEX Compilation

Instead of faking it with a DSL, I decided to compile the actual Kotlin code and stream raw DEX to the device for instant injection.

重點摘要

Initial DSL approach mapped Kotlin-like syntax to Compose via JSON but proved too limiting.

New pipeline compiles .kt to .class with kotlinc + Compose plugin, then uses d8 to produce classes.dex.

Base64 DEX is pushed over WebSocket and loaded by a custom ClassLoader for instant recompose without reinstall.

The author replaced a brittle DSL-based workflow for JetStart with true Kotlin compilation and raw DEX injection. The DSL initially parsed Kotlin-like syntax into JSON to render Compose UI, but it blocked real-world use cases like custom state, advanced animations, and third-party Compose libraries. The new architecture compiles .kt files with kotlinc and the Compose compiler plugin into .class files, converts them to classes.dex using Android's d8 tool, and streams the base64-encoded DEX to devices over a custom WebSocket. A device-side ClassLoader loads the classes instantly so the UI recomposes without a full rebuild or re-installation. The result is genuine @Composable support and near-instant hot reload (sub-100ms) while developers write ordinary Android code instead of a custom DSL.

为什么我放弃了 DSL 解析器而改用原始 DEX 编译

我没有再用脆弱的 DSL，而是编译真实的 Kotlin 代码，将原始 DEX 流式传输到设备并即时加载。

重點摘要

最初用 DSL 把 Kotlin 风格语法映射为 JSON 渲染 Compose，但过于受限。

新流程用 kotlinc + Compose 插件将 .kt 编译为 .class，再用 d8 生成 classes.dex。

将 base64 DEX 通过 WebSocket 推送到设备，由自定义 ClassLoader 即时加载并触发重组，无需重建或重装。

作者为 JetStart 放弃了基于 DSL 的方案，因为它在使用自定义状态、复杂动画或第三方 Compose 库时显得脆弱且受限。新的架构直接编译 Kotlin 源码：用 kotlinc 与 Compose 编译器插件将 .kt 编译成 .class 文件，再用 Android 的 d8 工具生成 classes.dex，将其 base64 编码并通过自定义 WebSocket 协议推送到连接的 Android 设备。设备端的自定义 ClassLoader 即时加载新类，UI 随之重组，实现无需完整重建或重新安装的即时注入，支持任意有效的 @Composable 并达到亚百毫秒的热重载体验。

為何我放棄 DSL 解析器改用原始 DEX 編譯

我沒有再用脆弱的 DSL，而是編譯實際的 Kotlin 程式，將原始 DEX 串流到裝置並即時載入。

重點摘要

最初用 DSL 把 Kotlin 樣式語法轉成 JSON 渲染 Compose，但太侷限。

新流程用 kotlinc 與 Compose 插件編譯 .kt 成 .class，再用 d8 產生 classes.dex。

將 base64 DEX 經 WebSocket 推送至裝置，由自訂 ClassLoader 即時載入並觸發重組，無須重建或重裝。

作者為 JetStart 放棄了以 DSL 為核心的實作，因為該方法在處理自定義 state、複雜動畫或第三方 Compose 函式庫時太脆弱且受限。新的架構直接編譯開發者的 Kotlin 程式：使用 kotlinc 與 Compose 編譯器插件將 .kt 編成 .class，透過 Android 的 d8 工具產出 classes.dex，再將其 base64 編碼後以自訂 WebSocket 協定推送至連線的 Android 裝置。裝置上的自訂 ClassLoader 即時載入新類別，UI 隨之重組，達到真實的 @Composable 支援與近乎即時（亞百毫秒）的熱重載體驗，開發者寫的是純 Android 程式而非專有 DSL。

10

Android Emulator vs Physical Device: Picking Your Development Target

Dev.to Kotlin 作者：Elimihele God's favour 發布：04-05 15:05

Android Emulator vs Physical Device: Choosing Your Development Target

JetStart lets you hot-reload Kotlin Compose UIs either directly on a physical Android device or via a high-performance Android Emulator.

重點摘要

Physical device hot reload uses a custom injection pipeline to push DEX bytecode into a running app for true, state-preserving updates.

JetStart integrates AVD management and provides pre-configured, optimized emulators controllable from the CLI for fast local development.

An experimental Web Emulator transpiles Compose to JavaScript for quick browser-based UI scaffolding when device or emulator isn't available.

JetStart offers three development targets for hot-reloading Kotlin Compose UIs: a physical device, an Android Emulator, and an experimental Web Emulator. For the most accurate experience, JetStart implements a custom injection architecture that intercepts file edits, compiles with kotlinc and d8, and pushes raw DEX bytecode over WebSocket to a ClassLoader in the running app, preserving state and delivering genuine device performance. If you lack a physical device, JetStart’s CLI manages Android Virtual Devices, creates JetStart-optimized emulators, auto-detects running instances and establishes the hot-reload connection. The Web Emulator is a tactical fallback that transpiles Compose to ES modules for browser rendering—fast and light but not a full Android replacement. The recommended workflow: use physical devices for final polish, emulators for daily development, and the Web Emulator when resources or mobility demand it.

Android 模拟器 vs 真机：选择你的开发目标

JetStart 允许你按偏好对 Kotlin Compose UI 进行热重载：直接到真机或使用高性能的 Android 模拟器。

重點摘要

真机热重载采用自定义注入架构，将 DEX 字节码通过 WebSocket 注入运行中的应用以保留状态并实时更新。

JetStart CLI 完全整合 AVD 管理，可创建预配置的优化模拟器并自动安装客户端建立热重载连接。

实验性 Web 模拟器将 Compose 转译为 JavaScript，在浏览器快速渲染，适合作为轻量级 UI 快速搭建方案。

JetStart 为热重载提供三条路径：真机、Android 模拟器和实验性的 Web 模拟器。为在真机上实现实时且保留状态的更新，作者开发了自定义注入管线，监控文件变更后后台运行 kotlinc 与 d8，并将原始 DEX 字节码通过 WebSocket 推送到运行中应用的 ClassLoader，从而在真实设备上得到准确的色彩、动画与触控延迟表现。若没有真机，JetStart 的 CLI 可管理 AVD，创建“JetStart 优化”模拟器并在运行时自动检测、安装客户端和建立热重载连接。Web 模拟器作为战术性后备，将 Compose 转为 ES modules 在浏览器打开，启动快但无法替代完整的 Android 环境。总体建议：最终优化用真机、日常开发用模拟器、移动或省资源时用 Web 模拟器。

Android 模擬器 vs 真機：選擇你的開發目標

JetStart 讓你能以偏好方式對 Kotlin Compose UI 進行熱重載：直接到真機或使用高效能的 Android 模擬器。

重點摘要

真機熱重載採用自訂注入架構，編譯並透過 WebSocket 將 DEX 推到執行中應用的 ClassLoader。

CLI 整合 AVD 管理，可建立 JetStart 優化的模擬器並自動安裝客戶端與建立熱重載連線。

實驗性 Web 模擬器會將 Compose 轉譯為 JavaScript，於瀏覽器快速呈現，適合輕量 UI 骨架開發。

JetStart 提供三種熱重載路徑：真機、Android 模擬器與實驗性 Web 模擬器。為了在真機上達到即時且保留狀態的更新，作者建立了自訂注入流程，監測檔案變更後在背景執行 kotlinc 和 d8，並透過 WebSocket 將原始 DEX bytecode 推送到正在執行的應用內 ClassLoader，保留觸控回饋與顏色等真實體驗。若沒有真機，JetStart CLI 可管理 AVD，建立預設為快速優化的模擬器並自動偵測與連線。Web 模擬器作為戰術性備援，將 Compose 轉為 ES modules 在瀏覽器呈現，雖然快速但無法完全取代原生 Android 環境。建議：最終測試用真機、日常開發用模擬器、外出或省資源時用 Web 模擬器。

11

Kotlin Weekly #505

Kotlin Weekly 作者：發布：04-05 07:49

Kotlin Weekly #505

Issue 505 (5 April 2026) highlights Amper 0.10 with automatic JDK provisioning and a Maven-to-Amper converter, a new OpenTelemetry Kotlin SDK, several in-depth articles (Koog AI agents, Koin compiler testing, BoM for Android libraries), videos, and new libraries.

重點摘要

Amper 0.10: automatic JDK provisioning, Maven converter, custom compiler plugin support

New OpenTelemetry Kotlin SDK: multiplatform, mobile-friendly tracing and logging

Featured articles: Koog AI agents, Koin compiler via unit tests, BoM for multi-module Android libraries

Kotlin Weekly #505 (5 April 2026) collects notable ecosystem updates: JetBrains’ Amper 0.10 adds automatic JDK provisioning, a Maven-to-Amper converter, support for custom Kotlin compiler plugins, and improved IDE integration for Ktor and profiling. The issue highlights a new OpenTelemetry Kotlin SDK that offers a unified, multiplatform API for tracing and logging across Android, iOS, JVM, and JS. Featured articles include building reliable AI agents with Koog, mastering Koin annotations and the Koin Compiler through unit tests, and configuring a Bill of Materials for multi-module Android libraries. Other items include an experimental GC for Android CI (ImNotOkay), several instructional videos (AGP 9.0 migration, Firebase AI Logic KSP, Kotlin 2.3.20 and Android benchmarks), a set of new libraries (Maryk, RikkaUI, Kotauth, cryptography-kotlin, WiretapKMP, koog-compose), sponsored learning resources, and contributor information.

Kotlin Weekly #505

第505期（2026-04-05）聚焦 Amper 0.10（自动 JDK 配置与 Maven 转换器）、新的 OpenTelemetry Kotlin SDK，以及多篇深度文章与视频资源。

重點摘要

Amper 0.10：自动 JDK 配置、Maven-to-Amper 转换器、支持自定义编译器插件

OpenTelemetry Kotlin SDK：多平台、面向移动设备的追踪与日志统一 API

重点文章：Koog 构建 AI 代理、用单元测试掌握 Koin 编译器注解、为多模块 Android 配置 BoM

Kotlin Weekly 第505期（2026年4月5日）汇总了 Kotlin 生态的重要新闻与资源。Amper 0.10 带来自动 JDK 配置、Maven 到 Amper 的转换器、对自定义 Kotlin 编译器插件的支持及对 Ktor 与性能分析的 IDE 集成改进；同时推出了新的 OpenTelemetry Kotlin SDK，提供覆盖 Android、iOS、JVM 和 JS 的统一、多平台追踪与日志 API。专题文章包括用 Koog 构建可靠的 AI 代理、通过单元测试掌握 Koin 编译器注解、以及为多模块 Android 库配置 BoM。此外还列出 Android CI 的 GC 实验、若干教学视频、多个新库（如 Maryk、RikkaUI、Kotauth 等）、赞助信息与投稿方式。

Kotlin Weekly #505

第505期（2026-04-05）重點包括 Amper 0.10（自動 JDK 配置與 Maven 轉換器）、新的 OpenTelemetry Kotlin SDK，以及多篇技術文章與教學影片。

重點摘要

Amper 0.10：自動 JDK 配置、Maven-to-Amper 轉換器、支援自訂編譯器外掛

OpenTelemetry Kotlin SDK：跨平台、針對行動友善的追蹤與日誌 API

重點文章：Koog 建構 AI 代理、以單元測試掌握 Koin 編譯器、為多模組 Android 設定 BoM

Kotlin Weekly 第505期（2026年4月5日）彙整近期 Kotlin 生態的重要更新。新聞部分介紹 Amper 0.10，新增自動 JDK 配置、Maven 轉 Amper 的轉換器、對自訂 Kotlin 編譯器外掛的支援，以及針對 Ktor 與效能分析的 IDE 整合改進；並宣布新的 OpenTelemetry Kotlin SDK，提供跨 Android、iOS、JVM 與 JS 的統一追蹤與日誌介面。專欄文章涵蓋使用 Koog 建立可靠 AI 代理、透過單元測試熟悉 Koin 編譯器註解，以及為多模組 Android 凝聚 BoM 的設定說明。其他內容還有 Android CI 的 GC 實驗、教學影片與多個新興函式庫，以及贊助與投稿資訊。

12

There’s a Better Way to CTA with TooltipBox (Material 3) — Stop Using Wonky Toasts!

Medium Kotlin 作者：RAFA 發布：04-05 08:41

There’s a Better Way to CTA with TooltipBox (Material 3) — Stop Using Wonky Toasts!

Instead of relying on bottom-toasts to explain a tapped CTA, use Material 3's TooltipBox to provide clearer, anchored feedback.

重點摘要

Toasts can feel detached and unclear when used for CTA feedback.

Material 3's TooltipBox offers anchored, contextual messages attached to the control.

TooltipBox improves clarity, discoverability, and interaction consistency over transient toasts.

RAFA's post argues that using bottom-positioned Toasts to confirm or explain CTA actions is often a poor choice because the message appears detached from the control that triggered it and can feel "wonky" or unclear. The author recommends Material 3's TooltipBox as a better alternative: TooltipBox attaches to the CTA, delivers contextual feedback or labels in place, and preserves visual and interaction consistency. Compared with transient toasts, anchored TooltipBox messages are easier to scan, more discoverable, less disruptive, and can reduce ambiguity about which control produced the message. The article encourages developers to prefer TooltipBox for clearer call-to-action feedback and links to a longer walkthrough on Stackademic for examples and guidance.

用 TooltipBox（Material 3）更好地处理 CTA — 别再用奇怪的 Toasts！

与其用底部 Toast 来说明被点按的 CTA，不如用 Material 3 的 TooltipBox 提供贴近且清晰的反馈。

重點摘要

底部 Toast 容易与触发元件脱节，导致信息不明确。

TooltipBox 可附着在 CTA 上，提供上下文相关的提示。

TooltipBox 比临时 Toast 更清晰、更易发现且交互一致。

RAFA 在文章中指出，用底部 Toast 来回应按键或 CTA 的操作往往不理想：信息与触发控件脱节、出现位置不直观，容易造成使用者困惑。作者建议改用 Material 3 的 TooltipBox，因其可以贴靠 CTA 提供上下文回馈或标示，维持视觉与交互一致性。与短暂出现的底部 Toast 相比，TooltipBox 更易被扫描与发现、干扰更小，也能减少关于哪一项控件触发了信息的模糊性。文章鼓励开发者考虑采用 TooltipBox，并在 Stackademic 提供链接以供进一步阅读与示范。

用 TooltipBox（Material 3）更好地處理 CTA — 別再用怪怪的 Toasts！

與其用底部 Toast 解釋被點擊的 CTA，不如用 Material 3 的 TooltipBox 提供貼齊且清楚的回饋。

重點摘要

底部 Toast 與觸發元件容易脫節，顯得不明確。

TooltipBox 可貼齊 CTA，提供上下文相關的提示或回饋。

使用 TooltipBox 可提升清晰度、可掃描性與互動一致性。

RAFA 在文章中指出，使用底部 Toast 來回應 CTA 操作常常不是理想做法：訊息與觸發元件脫節、顯示位置不直觀，容易讓使用者困惑。作者建議改用 Material 3 的 TooltipBox，因為它能貼齊按鈕或控制項，提供上下文相關的回饋或標示，同時維持視覺與互動一致性。與短暫出現的底部 Toast 相比，TooltipBox 更容易被掃描與發現，干擾性也較低，並能減少哪個控制項觸發訊息的模糊性。文章鼓勵開發者考慮採用 TooltipBox，並在 Stackademic 提供連結以便閱讀完整示範與說明。

13

I Spent Hours Debugging a One-Line Fix: A Kotlin Multiplatform War Story

Medium Kotlin 作者：Sijan Neupane 發布：04-05 10:27

I Spent Hours Debugging a One-Line Fix: A Kotlin Multiplatform War Story

When your cross-platform app crashes before it even loads, and the fix is embarrassingly simple.

重點摘要

A Kotlin Multiplatform app crashed before it could load.

Hours of debugging led to a one-line, embarrassingly simple fix.

The story highlights pitfalls and lessons in cross-platform development.

Author Sijan Neupane recounts a Kotlin Multiplatform debugging episode where a cross-platform app crashed before it even loaded. After hours of investigation the root cause turned out to be an embarrassingly simple one-line fix. The piece captures the frustration of long debugging sessions that end with a trivial correction and highlights common pitfalls when working across platforms with shared code. Rather than detailing the exact code change, the story emphasizes the mismatch between time invested and simplicity of the solution, serving as a cautionary, relatable reminder to check small configuration or compatibility issues early. It's a brief war story about persistence, humility, and the surprising lessons engineers learn when bridging multiple platforms.

我花了好几个小时调试，结果是一行修复：一则 Kotlin Multiplatform 战事

当你的跨平台应用在还没加载就崩溃，而修复竟然只有一行且尴尬地简单。

重點摘要

Kotlin Multiplatform 的跨平台应用在启动前崩溃。

耗费数小时排查，最终只需一行代码修复。

故事强调多平台开发中微小差异可能引发大问题。

作者 Sijan Neupane 分享了一则 Kotlin Multiplatform 的经历：一个跨平台应用在加载前就崩溃，经过数小时排查后，根本原因竟然只需一行代码就能修复，令人尴尬。文章并未详述具体代码改动，而是通过这段“战事”凸显在多平台共用代码与配置时，小问题可能导致大量调试工作，提醒开发者优先检查细微的配置或兼容性差异，并从中吸取经验、保持耐心与谦逊。

我花了好幾小時除錯，結果是一行修正：一則 Kotlin Multiplatform 的戰事

當你的跨平台應用在還沒載入就當掉，而修正竟然只有一行且令人尷尬地簡單。

重點摘要

Kotlin Multiplatform 的跨平台應用在啟動前當掉。

花了數小時排查，最後竟只需一行程式碼即可修復。

故事凸顯多平台開發中小細節可能造成大問題。

作者 Sijan Neupane 分享一則 Kotlin Multiplatform 的實戰經驗：一個跨平台應用在啟動前就當掉，花了好幾小時除錯後，問題竟然只需一行程式碼就能修好，令人尷尬。文章以這段「工程師戰事」為例，凸顯跨平台開發中小細節或設定可能造成大問題，以及長時間排查卻被簡單解法收場的無奈與幽默。這個故事提醒開發者在多平台共用程式碼時務必檢查微小差異與相容性，並從經驗中學會謙虛與耐心。

14

When Coroutines Become Unreadable: Designing Systems You Can Still Understand Six Months Later

Medium Kotlin 作者：Oliver Bozhinovski 發布：04-05 14:45

When Coroutines Become Unreadable: Designing Systems You Can Still Understand Six Months Later

If you ask most Android developers what makes a good coroutine architecture, the answer is usually something like:

重點摘要

Coroutine-based code can degrade in readability over time

Design for long-term understandability with clear boundaries and conventions

Prioritize documentation, testing, and observability to aid future maintainers

In "When Coroutines Become Unreadable," Oliver Bozhinovski examines why coroutine architectures in Android projects often become hard to follow and what to prioritize so systems remain understandable months later. The article opens by noting common developer beliefs about good coroutine architecture, then highlights that real-world coroutine code can become unreadable due to implicit control flow, dispersed scopes, and overuse of abstractions. It advocates designing for clarity through explicit boundaries, consistent conventions, limited and well-documented abstractions, and investments in tests and observability. The piece frames readability and maintainability as deliberate design goals, emphasizing trade-offs between concise code and long-term comprehensibility, and argues that conventions, documentation, and tooling save time and cognitive load for future maintainers.

当协程变得不可读：设计在六个月后仍能看懂的系统

如果你问大多数 Android 开发者什么造就了良好的协程架构，答案通常会是类似的：

重點摘要

基于协程的代码可能随着时间变得难以阅读

通过明确边界和一致约定来设计以利长期可理解性

依靠文档、测试与可观测性降低未来维护成本

Oliver Bozhinovski 的文章讨论了为何在实践中基于协程的架构会逐渐变得难以理解，以及在设计时应如何优先考虑，以便系统在数月后仍然可读。文章先提到开发者对“良好协程架构”的常见看法，但指出实际代码往往因为隐含控制流、分散的协程范围和过度抽象而失去可读性。作者主张通过明确的边界、一致的约定、有限且有文档的抽象层，以及充分的测试和可观测性工具来增强可维护性。核心观点是把可读性作为设计目标，权衡简洁性与长期可理解性，强调约定与工具对未来维护的帮助。

當協程變得難以閱讀：設計能在六個月後仍看得懂的系統

如果你問大多數 Android 開發者什麼造就良好的協程架構，答案通常會是類似的回應：

重點摘要

協程導向的程式碼可能隨時間變得難以閱讀

以明確邊界與一致慣例來設計以利長期理解

透過文件、測試與可觀測性減輕未來維護負擔

Oliver Bozhinovski 的文章探討為何在實務中以協程為基礎的架構會逐漸變得難以理解，以及如何在設計時優先考量以確保系統在數月後仍易於閱讀。文章指出，雖然開發者對「良好協程架構」有既定想法，但實際程式碼常因隱含的控制流程、分散的 scope 與過度抽象而失去可讀性。作者建議以清晰的邊界、一致的約定與有限且有說明的抽象來設計系統，並搭配充足的測試與可觀測性工具。整體論點是將可讀性與可維護性視為設計首要目標，重視文件與工具帶來的長期收益。

15

One-Time Events in Jetpack Compose: Why I Switched from SharedFlow to Channel

Medium Kotlin 作者：chanzmao 發布：04-05 05:19

One-Time Events in Jetpack Compose: Why I Switched from SharedFlow to Channel

Handling “one-time events” — such as navigation or transient UI feedback — requires different patterns in MVI and Jetpack Compose.

重點摘要

One-time events (e.g., navigation, transient UI) need special handling in MVI.

The author migrated from SharedFlow to Channel to address those events.

The article compares both approaches and explains implications for Compose.

The article examines how to handle "one-time events" in an MVI-style architecture with Jetpack Compose. The author describes real-world cases like navigation and transient UI feedback that should be consumed only once, and explains why they moved from using SharedFlow to using Channel for those events. Rather than presenting a generic flow solution, the piece focuses on the behavioral differences between the two primitives, the motivations behind the switch, and the practical impact on event delivery in Compose-based UIs. The write-up highlights trade-offs and provides guidance for choosing an approach that better matches single-consumption semantics in modern Android architectures.

Jetpack Compose 中的一次性事件：我为何从 SharedFlow 转向 Channel

在 MVI 与现代 Android 架构中，处理像导航或临时 UI 反馈等“一次性事件”需要不同的模式。

重點摘要

一次性事件（如导航、临时提示）在 MVI 中需要特殊处理。

作者将用于这类事件的实现从 SharedFlow 换为 Channel。

文章比较两者差别并说明对 Compose 的影响。

本文探讨在 MVI 风格架构与 Jetpack Compose 中如何处理“一次性事件”。作者以导航和临时 UI 反馈为例，说明这类事件应仅被消费一次的需求，并解释为何选择将实现从 SharedFlow 切换到 Channel。文章侧重于两种机制在事件行为上的差异、促成切换的原因以及这些差异对 Compose 事件传递的实际影响，并给出倾向于单次消费语义的实现建议。

Jetpack Compose 的一次性事件：我為何從 SharedFlow 改用 Channel

在 MVI 與現代 Android 架構中，處理像導覽或暫時性 UI 回饋等「一次性事件」需要不同的設計模式。

重點摘要

一次性事件（如導覽、暫時性提示）在 MVI 中需特殊處理。

作者從 SharedFlow 轉向 Channel 以處理這類事件。

文章比較兩者差異並說明對 Compose 的影響。

本文探討在 MVI 架構與 Jetpack Compose 中如何處理「一次性事件」。作者以導覽和暫時性 UI 回饋為例，說明這類事件應僅被消費一次的需求，並解釋為何決定從 SharedFlow 改用 Channel。文章著重於兩種工具在事件行為上的不同、促使改變的考量，以及這些差異對 Compose UI 事件傳遞的實務影響，並提供選擇更符合單次消費語意的方法建議。

16

BUKU SAKU LENGKAP: PEMROGRAMAN KOTLIN

Medium Kotlin 作者：Ahmad Fakih 發布：04-05 06:01

Complete Pocketbook: Kotlin Programming

Kotlin is a modern programming language developed by JetBrains and officially supported by Google for application development.

重點摘要

Modern programming language

Developed by JetBrains

Officially supported by Google for application development

The Medium post titled "BUKU SAKU LENGKAP: PEMROGRAMAN KOTLIN" by Ahmad Fakih introduces Kotlin as a modern programming language developed by JetBrains and officially supported by Google for application development. Framed as a "complete pocketbook," the excerpt emphasizes Kotlin's contemporary design and the platform-level endorsement that underscores its relevance for developers. The snippet is brief and serves as an entry point, directing readers to continue reading on Medium for the full material. Within the available excerpt, the author states Kotlin's origin and official backing without providing technical detail or examples. The piece functions as a concise notice or compact reference that points readers to a more comprehensive Kotlin resource on Medium.

完整口袋书：Kotlin 编程

Kotlin 是由 JetBrains 开发并得到 Google 正式支持的现代编程语言，适用于应用程序开发。

重點摘要

现代编程语言

由 JetBrains 开发

获得 Google 正式支持，用于应用程序开发

Kotlin 是由 JetBrains 开发并获得 Google 正式支持的现代编程语言。该 Medium 文章《BUKU SAKU LENGKAP: PEMROGRAMAN KOTLIN》由 Ahmad Fakih 撰写，被定位为“完整口袋书”，摘录强调 Kotlin 的现代性与官方背书，表明其在应用程序开发领域的相关性。文章片段简短，作为导读并引导读者在 Medium 上阅读完整内容；摘录中未提供技术细节或示例，但清楚指出这是一篇概览性、参考性简介，便于读者找到更多关于 Kotlin 的完整资料。

完整口袋書：Kotlin 程式設計

Kotlin 是由 JetBrains 開發並獲 Google 正式支援的現代程式語言，用於應用程式開發。

重點摘要

現代程式語言

由 JetBrains 開發

獲 Google 正式支援，用於應用程式開發

Kotlin 是由 JetBrains 開發、並獲 Google 正式支援的現代程式語言。此 Medium 文章〈BUKU SAKU LENGKAP: PEMROGRAMAN KOTLIN〉由 Ahmad Fakih 撰寫，標示為「完整口袋書」類型，片段強調 Kotlin 的現代性與官方背書，指出其在應用程式開發上的相關性。摘錄內容簡短，作為導讀並引導讀者前往 Medium 閱讀完整內容；片段未提供技術細節或實作範例，但明確表明文章屬於概覽性、參考性質的簡要介紹，讀者可藉此找到更全面的 Kotlin 資訊來源。

17

Room Database: A Practical Guide for Android Development

Medium Kotlin 作者：Sivabharath K 發布：04-05 06:05

Room Database: A Practical Guide for Android Development

A structured guide to understanding Room, from core components to migrations and transactions.

重點摘要

Introduces Room's core concepts and components

Covers database migrations and transaction handling

Focused practical guidance for Android developers

This article is a concise, structured guide to Room, the persistence library used in Android development. It outlines the key pieces needed to understand and work with Room, emphasizing core components and how they fit together. The guide also addresses database migrations and transaction management, presenting these topics in a practical manner for developers who need to maintain and evolve app databases. Aimed at Android practitioners, the piece distills fundamental ideas and workflows so readers can grasp how Room operates and what to consider when applying it in real projects.

Room 数据库：Android 开发实用指南

一份结构化的指南，涵盖 Room 的核心组件、迁移与事务等内容，帮助理解其运作方式。

重點摘要

介绍 Room 的核心组件与概念

讨论数据库迁移与事务处理

面向 Android 开发者的实务建议

本文是一篇结构化的 Room 指南，概述了 Android 开发中使用的 Room 持久化方案的关键要素，重点说明核心组件的作用与相互关系，同时讨论数据库迁移与事务管理的相关议题。文章以实用为导向，整理了开发者在建立與维护應用数据库时应关注的重点，便于读者快速掌握 Room 的基本概念与在实际项目中应用时的考量。

Room 資料庫：Android 開發實務指南

一篇有架構的指南，從核心元件講到資料庫遷移與交易處理，協助理解 Room 的運作。

重點摘要

說明 Room 的核心概念與元件

涵蓋資料庫遷移與交易管理

以 Android 開發者實務為導向

本文為一篇有條理的 Room 指南，說明 Android 常用的持久化機制 Room 的主要概念與組成，並介紹與遷移（migrations）及交易（transactions）相關的處理重點。文章以實務角度整理要點，幫助開發者了解各個元件如何協同運作，以及在維護與擴展應用資料庫時應注意的面向，適合需要掌握 Room 基礎與實作考量的 Android 開發者閱讀。

18

The Sticker Dilemma: Why Kotlin Annotations Need Use-Site Targets

Medium Kotlin 作者：Akshay Surana 發布：04-05 06:09

The Sticker Dilemma: Why Kotlin Annotations Need Use-Site Targets

Annotations are the silent architects of our codebase, powering Dependency Injection and enforcing resource types.

重點摘要

Annotations quietly shape Android code behavior and APIs

They enable Dependency Injection and resource-type enforcement

Kotlin needs explicit use-site targets to remove annotation ambiguity

Annotations play an outsized but often invisible role in Android development: they influence generated code, validate resources, and drive frameworks like Dependency Injection. The article argues that in Kotlin, where a single declaration can correspond to multiple generated elements (field, getter, setter, parameter), annotations can become ambiguous unless developers specify use-site targets. Use-site targets let you explicitly attach an annotation to the intended element, preventing mismatches between what the annotation expects and where it’s actually applied. By clarifying annotation placement, use-site targets reduce subtle bugs, improve interoperability with libraries and DI frameworks, and make intent clearer for maintainers. The piece highlights the practical need for precise annotation targeting in Kotlin-based Android projects to avoid hidden runtime or compilation surprises.

贴纸困境：为何 Kotlin 注解需要使用位置目标

注解是我们代码库中无声的架构师，驱动依赖注入并强制资源类型。

重點摘要

注解在 Android 开发中决定行为与生成结果

它们支持依赖注入并校验资源类型

Kotlin 需要 use-site targets 来消除注解应用歧义

在 Android 开发中，注解虽不显眼，却深刻影响代码行为：推动生成代码、验证资源并与依赖注入框架协作。文章指出，由于 Kotlin 的声明可能同时对应字段、getter、setter 或参数等多个目标，若不使用明确的使用位置（use-site target），注解可能被误用到错误的元素，从而引发意外行为或错误。通过指定 use-site targets，可以明确注解附着的具体位置，减少隐性错误、增强与库与 DI 框架的兼容性，并使维护者更容易理解意图。文章强调在 Kotlin 项目中精确标注注解位置的实用必要性。

貼紙困境：為何 Kotlin 註解需要指定使用位置

註解是我們程式碼庫中無聲的架構師，驅動依賴注入並強制資源類型。

重點摘要

註解在 Android 開發中決定行為與生成結果

它們支援依賴注入並檢查資源類型

Kotlin 要求 use-site targets 以消除註解應用的歧義

在 Android 開發中，註解雖不顯眼，卻影響大量行為：驅動生成程式碼、校驗資源並與依賴注入等框架整合。文章指出，Kotlin 的一個宣告可能對應到欄位、getter、setter 或參數等多個實體，若不明確指定使用位置（use-site target），註解就可能被套用到錯誤的目標，導致預期之外的行為或錯誤。透過 use-site targets 可以明確註解的作用位置，降低隱性錯誤、改善與函式庫和 DI 的互通性，並讓後續維護者更易理解原始意圖。結論強調在 Kotlin Android 專案中精確標註使用位置的重要性。

今日總結

Gemma 4 在 Android 上：完整開發者指南（離線 AI）

重點摘要

強固的 BLE：在 Android 12+ 使用前景服務防止斷線並實作自動重連

重點摘要

精通 Android 12+ 的 BLE 權限（Kotlin）：BLUETOOTH_SCAN／CONNECT 的變化與常見陷阱

重點摘要

掌握 Android BLE 斷線處理：重連與錯誤復原的穩健策略

重點摘要

精通 BluetoothGatt 生命週期：在 Android Kotlin BLE 中預防記憶體洩漏與過期連線

重點摘要

為何你的 Android BLE 廣播在 Android 12+ 背景下會悄然失效，以及如何修正

重點摘要

以 Kotlin Coroutines 解決 Android BLE GATT 競態條件

重點摘要

在 Android (Kotlin) 上穩定掌握 BLE 特徵通知

重點摘要

為何我放棄 DSL 解析器改用原始 DEX 編譯

重點摘要

Android 模擬器 vs 真機：選擇你的開發目標

重點摘要

Kotlin Weekly #505

重點摘要

用 TooltipBox（Material 3）更好地處理 CTA — 別再用怪怪的 Toasts！

重點摘要

我花了好幾小時除錯，結果是一行修正：一則 Kotlin Multiplatform 的戰事

重點摘要

當協程變得難以閱讀：設計能在六個月後仍看得懂的系統

重點摘要

Jetpack Compose 的一次性事件：我為何從 SharedFlow 改用 Channel

重點摘要

完整口袋書：Kotlin 程式設計

重點摘要

Room 資料庫：Android 開發實務指南

重點摘要

貼紙困境：為何 Kotlin 註解需要指定使用位置

重點摘要