每日新聞摘要

Google Play stopped accepting new apps and updates that do not target Android 16 (API 36) on August 31, 2026, and the submission block already applies if you have not upgraded. Developers can request a one-time extension through Play Console to November 1, 2026, but it is not automatic and should be treated only as extra time to finish the work. The article explains the exact targeting rules across device categories, calls out companion deadlines for Play Billing and native code page-size support, and details the main breakages that can appear after moving to targetSdk 36, including edge-to-edge, predictive back, large-screen behavior, 16 KB page sizes, toolchain alignment, and Billing Library v8 migration. It also recommends verifying the built artifact and testing on real devices or emulators after the upgrade.

Google Play 自 2026 年 8 月 31 日起停止接受未以 Android 16（API 36）为目标的新应用和更新；如果还没升级，提交时就会被拦下。开发者可以通过 Play Console 申请一次性延期到 2026 年 11 月 1 日，但这只是额外缓冲，不会自动生效，也不能替代升级本身。文章梳理了不同设备类别的目标 API 要求，提醒同时检查 Play Billing 和原生代码的相关门槛，并说明升级到 targetSdk 36 后常见的兼容性变化，包括 edge-to-edge、predictive back、大屏行为、16 KB page size、工具链配套以及 Billing Library v8 迁移。最后建议从打包产物验证，并在真机或对应模拟器上测试。

This article is part 12 of the Android Modularization series and centers on release engineering. Its teaser points to three release-specific concerns: R8 full mode, consumer keep rules, and a configuration-cache failure that only shows up in release builds. From the available text, the piece appears to address build and packaging issues that matter once an app moves from development to release, without claiming any unsupported fixes or outcomes.

这篇文章是 Android Modularization 系列的第 12 部分，主题聚焦于发布工程。文中摘要提到三个与发布相关的重点：R8 full mode、consumer keep rules，以及只会在 release build 中出现的 configuration-cache 失败。从现有内容来看，文章主要讨论应用从开发走向发布时的构建与打包问题，没有提供额外未经证实的解决方案或结果。

This article asks whether you should upgrade to Java 27 and focuses on the changes most likely to matter in practice. It points to compact object headers and G1 being the default as the main examples, noting that these changes can reduce memory usage. The piece also emphasizes checking the effect on your own system rather than relying on assumptions, making it a practical guide for evaluating the upgrade.

本文讨论是否应该升级到 Java 27，并聚焦于实际使用中最值得关注的变化。文中提到紧凑对象头和默认使用 G1 是两个主要例子，这些改动可能降低内存占用。作者还强调，不应只依赖推测，而要在自己的系统上实际确认效果，以便更务实地评估这次升级。

The provided content is extremely limited and only shows an introduction plus a link prompt to continue reading on Medium. No actual Android development updates, shifts, or technical claims are included in the visible text, so there is nothing substantive to summarize beyond noting the article’s title and the absence of body content.

目前提供的内容非常有限，只能看到前言以及前往 Medium 继续阅读的提示，没有实际的 Android 开发更新、变化或技术论述可供摘要。由于可见正文缺失，无法根据这段文字推断标题所称的 7 项转变，只能如实说明本文可用信息不足。

The provided content contains only the article title and a short teaser, so the substantive details of the post are unavailable. Based on the title, the article appears to focus on the hidden or leftover work that can remain after coroutines are cancelled in a production Android codebase. However, no concrete examples, implementation details, or conclusions are included in the supplied text, so any deeper summary would be speculative.

目前提供的内容只有文章标题和一行导语，因此无法获得完整论述。就标题来看，文章应是在讨论 coroutine 被取消后，生产环境 Android 代码库中可能遗留下来的隐性工作或后续处理问题。不过，正文没有提供具体案例、实现细节或结论，所以如果继续延伸摘要，就会超出原文可证实的范围。

This piece introduces the topic of modern television delivery by contrasting IPTV, OTT, cable, and satellite. However, the provided article body is only a brief teaser that says television has changed a lot and invites readers to continue on Medium. As a result, the visible text does not include any detailed explanation, technical comparison, or conclusions about the different TV technologies.

本文以 IPTV、OTT、有线电视和卫星电视为主题，说明现代电视传输方式的变化。不过，所提供的正文只有一句简短开场，提到电视已经改变了很多，并引导读者前往 Medium 继续阅读。因此，现有文本并未包含各技术的详细说明、比较内容或结论。

The article describes how the author built Muffle, an Android app that automates sound-profile changes based on location, time, and prayer schedules. Standard background execution proved unreliable because Android and device manufacturers aggressively kill processes, so the app moved to a foreground service with a persistent notification, WorkManager for periodic tasks, boot-complete handling, and battery-optimization requests. The author also adjusted GPS polling to reduce power use, considered Geofencing API as a better fit, and handled Do Not Disturb permissions carefully. The main lesson is to design for failure: assume the service may die, persist state locally in Room, and rebuild it on restart.

本文讲述作者开发 Muffle 的过程：这是一款可根据 GPS、时间和祈祷时间自动切换手机音量状态的 Android 应用。由于普通 Service 很快会被系统或厂商的电池管理杀掉，作者改用前台服务，并结合常驻通知、WorkManager、REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 和 ACTION_BOOT_COMPLETED 来提高可靠性。他还通过调整 GPS 轮询频率来降低耗电，考虑改用 Geofencing API，并处理不同 API 等级下的 Do Not Disturb 权限差异。文章的核心结论是：不要指望后台执行稳定，应该默认服务会被终止，并把当前状态持久化到 Room 中，便于重启后恢复。

The article describes building a lightweight Kotlin/JVM JSON library that separates direct JSON handling from Kotlin class mapping. The core json module offers a sealed Json model, accessors, a DSL for constructing JSON, parsing, and writing, all without reflection or code generation. A separate json-reflect module adds reflection-based mapping between JSON and Kotlin classes, plus support for annotations, custom JsonMapper implementations, and Android-friendly ProGuard rules. The author also covers publishing to Maven Central, generating Dokka documentation, and automating releases with GitHub Actions. The main takeaway is that reflection is optional for JSON parsing, but remains useful when automatic object mapping is desired.

本文介绍作者打造的轻量级 Kotlin/JVM JSON 库，将直接操作 JSON 与 Kotlin 类映射拆分为两个模块。核心 json 模块提供 sealed Json 表示、accessor、构建 DSL、解析与写出能力，完全不依赖 reflection 或代码生成；独立的 json-reflect 模块则加入基于 reflection 的 JSON 与 Kotlin 类映射，并支持注解、自定义 JsonMapper，以及 Android 上所需的 ProGuard 规则。作者还说明了发布到 Maven Central、生成 Dokka 文档，以及用 GitHub Actions 自动化发布流程。核心结论是：JSON 解析可以不靠 reflection，但在需要自动对象映射时，它依然很方便。

This article describes a step-by-step journey for building a Shopify mobile app with Compose Multiplatform, beginning with the first Compose screen and moving toward a scalable mobile architecture. It frames the process as a practical from-scratch build rather than a high-level overview, emphasizing the progression from an initial screen to a more structured application design.

本文介绍如何使用 Compose Multiplatform 从零开始构建 Shopify 移动应用，过程从第一个 Compose 界面出发，逐步推进到可扩展的移动架构。文章强调这是一次以实践为导向的分步构建，而不是停留在高层概述；重点在于从最初的界面逐渐形成更有结构的应用设计。