Google I/O 2016 上发布的 Android N 有哪些新特性？

1.多窗口支持

在 Android N 中，我们为该平台引入了一个新的而且非常需要的多任务处理功能 — 多窗口支持。

现在，用户可以一次在屏幕上打开两个APP。

• 在运行 Android N 的手机和平板电脑上，用户可以并排运行两个APP，或者处于分屏模式时一个APP位于另一个APP之上。用户可以通过拖动两个APP之间的分隔线来调整APP。
• 在 Android TV 设备上，APP可以将自身置于画中画面模式，从而让它们可以在用户浏览或与其他APP交互时继续显示内容。如需了解详细信息，请参阅下文。

多窗口支持为您提供新的吸引用户方式，特别是在平板电脑和其他更大屏幕的设备上。您甚至可以在您的APP中启用拖放，从而使用户可以方便地将内容拖放到您的应用或从其中拖出内容—这是一个非常好的增强用户体验的方式。

向您的APP添加多窗口支持并配置多窗口显示的处理方式非常简单。例如，您可以指定您的 Activity 允许的最小尺寸，从而防止用户将 Activity 调整到该尺寸以下。您还可以为APP禁用多窗口显示，这可确保系统将仅以全屏模式显示APP。

如需了解详细信息，请参阅多窗口支持开发者文档。

2.Notification 增强功能

在 Android N 中，我们重新设计了Notification，使其更易于使用并且速度更快。部分变更包括：
- 模板更新：我们正在更新Notification模板，新强调了图片跟头像。开发者将能够充分利用新模板，只需进行少量的代码调整。
- 绑定的Notification：系统可以将消息组合在一起（例如，按消息主题）并显示组。用户可以适当地进行 Dismiss 或 Archive 等操作。如果您已实现 Android Wear 的通知，那么您已经很熟悉此模型。
- 直接回复：对于实时通信应用，Android 系统支持内联回复，以便用户可以直接在通知界面中快速回复短信。
- 自定义视图：两个新的 API 让您在通知中使用自定义视图时可以充分利用系统的风格，如Notification标题和操作。

如需了解如何实现新功能的信息，请参阅通知指南。

2.配置文件指导的 JIT/AOT 编译

在 Android N 中，我们添加了 Just in Time (JIT) 编译器，对 ART 进行代码分析，让它可以在应用运行时持续提升 Android 应用的性能。JIT 编译器对 Android 运行组件当前的 Ahead of Time (AOT) 编译器进行了补充，有助于提升运行时性能，节省存储空间，加快应用更新和系统更新速度。

配置文件指导的编译让 Android 运行组件能够根据应用的实际使用以及设备上的情况管理每个应用的 AOT/JIT 编译。例如，Android 运行组件维护每个应用的热方法的配置文件，并且可以预编译和缓存这些方法以实现最佳性能。对于应用的其他部分，在实际使用之前不会进行编译。

除提升应用的关键部分的性能外，配置文件指导的编译还有助于减少整个 RAM 占用，包括关联的二进制文件。此功能对于低内存设备非常尤其重要。

Android 运行组件在管理配置文件指导的编译时，可最大程度降低对设备电池的影响。仅当设备处于空闲状态和充电时才进行编译，从而可以通过提前执行该工作节约时间和省电。

3.快速的应用安装路径

Android 运行组件的 JIT 编译器最实际的好处之一是应用安装和系统更新的速度。即使在 Android 6.0 中需要几分钟进行优化和安装的大型应用，现在只需几秒钟就可以完成安装。系统更新也变得更快，因为省去了优化步骤。

4.瞌睡模式

Android 6.0 推出了瞌睡模式，即设备处于空闲状态时，通过推迟应用的 CPU 和网络活动以实现省电目的的系统模式，例如，设备放在桌上或抽屉里时。

现在，在 Android N 中，瞌睡模式又前进了一步，在外出时也可以省电。只要屏幕关闭了一段时间，且设备未插入电源，瞌睡模式就会对应用使用熟悉的 CPU 和网络限制。这意味着用户即使将设备放入口袋里也可以省电。

屏幕关闭片刻后，设备在使用电池时，瞌睡模式将限制网络访问，同时延迟作业和同步。在短暂的维护时间范围后，其允许应用访问网络，并执行延迟的作业/同步。打开屏幕或将设备插入电源会使设备退出瞌睡模式。

当设备再次处于静止状态时，屏幕关闭且使用电池一段时间，瞌睡模式针对 PowerManager.WakeLock,AlarmManager 警报和 GPS/Wi-Fi 扫描应用完整 CPU 和网络限制。

无论设备是否处于运动状态，将应用调整到瞌睡模式的最佳做法均相同，因此，如果您已更新应用以妥善处理瞌睡模式，则一切就绪。如果不是，请立即开始将应用调整到瞌睡模式。

5.Project Svelte：后台优化

Project Svelte 在持续改善，以最大程度减少生态系统中一系列 Android 设备中系统和应用使用的 RAM。在 Android N 中，Project Svelte 注重优化在后台中运行应用的方式。

后台处理是大多数应用的一个重要部分。处理得当，可让您实现非常棒的用户体验 — 即时、快速和情境感知。如果处理不得当，后台处理会毫无必要地消耗 RAM（和电池），同时影响其他应用的系统性能。

自 Android 5.0 发布以来，JobScheduler 已成为执行后台工作的首选方式，其工作方式有利于用户。应用可以在安排作业的同时允许系统基于内存、电源和连接情况进行优化。JobScheduler 可实现控制和简洁性，我们想要所有应用都使用它。

另一个非常好的选择是 GCMNetworkManager（Google Play 服务的一部分），其在旧版 Android 中提供类似的作业安排和兼容性。

我们在继续扩展 JobScheduler 和 GCMNetworkManager，以符合多个用例 — 例如，在 Android N 中，现在，您可以基于内容提供程序中的更改安排后台工作。同时，我们开始弃用一些较旧的模式，这些模式会降低系统性能，特别是低内存设备的系统性能。

在 Android N 中，我们删除了三个常用隐式广播 — CONNECTIVITY_ACTION、ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO — 因为这些广播可能会一次唤醒多个应用的后台进程，同时会耗尽内存和电池。如果您的应用收到这些广播，请充分利用 N Developer Preview 以迁移到 JobScheduler 和相关的 API。

如需了解详情，请查看后台优化文档。

6.Data Saver

在移动设备的整个生命周期，蜂窝数据计划的成本通常会超出设备本身的成本。对于许多用户而言，蜂窝数据是他们想要节省的昂贵资源。

Android N 推出了 Data Saver 模式，这是一项新的系统服务，有助于减少应用使用的蜂窝数据，无论是在漫游，账单周期即将结束，还是使用少量的预付费数据包。Data Saver 让用户可以控制应用使用蜂窝数据的方式，同时让开发者打开 Data Saver 时可以提供更多有效的服务。

用户在 Settings 中启用 Data Saver 且设备位于按流量计费的网络上时，系统屏蔽后台数据使用，同时指示应用在前台尽可能使用较少的数据 — 例如，通过限制用于流媒体服务的比特率、降低图片质量、延迟最佳的预缓冲等方法来实现。用户可以将特定应用加入白名单以允许后台按流量的数据使用，即使在打开 Data Saver 时也是如此。

Android N 继承了 ConnectivityManager，以便为应用检索用户的 Data Saver 首选项并监控首选项变更提供一种方式。所有应用均应检查用户是否已启用 Data Saver 并努力限制前台和后台数据的使用。

7.快速设置Tile API

“快速设置”通常用于直接从通知栏显示关键设置和操作，非常简单。在 Android N 中，我们已扩展“快速设置”的范围，使其更加有用更方便。

我们为额外的“快速设置”Tile添加了更多空间，用户可以通过向左或向右滑动跨分页的显示区域访问它们。我们还让用户可以控制显示哪些“快速设置”Tile以及显示的位置 — 用户可以通过拖放Tile来添加或移动Tile。

对于开发者，Android N 还添加了一个新的 API，从而让您可以定义自己的“快速设置”Tile，使用户可以轻松访问您应用中的关键控件和操作。

对于急需或频繁使用的控件和操作，保留“快速设置”Tile，且不应将其用作启动应用的快捷方式。

定义Tile后，您可以将它们显示给用户，用户可通过拖放将Tile添加到“快速设置”。

如需创建应用Tile的更多信息，请参阅可下载的 API 参考中的 android.service.quicksettings.Tile。

8.号码屏蔽

Android N 现在支持在平台中进行号码屏蔽，提供框架 API，让服务提供商可以维护屏蔽的号码列表。默认短信应用、默认手机应用和提供商应用可以对屏蔽的号码列表进行读取和写入操作。其他应用则无法访问此列表。

通过使号码屏蔽成为平台的标准功能，Android 为应用提供一致的方式来支持广泛的设备上的号码屏蔽。应用可以利用的其他优势包括：
- 还会屏蔽已屏蔽的来电号码发出的短信
- 通过 Backup & Restore（备份和还原）功能可以跨重置和设备保留屏蔽的号码
- 多个应用可以使用相同的屏蔽号码列表

此外，通过 Android 的运营商应用集成表示运营商可以读取设备上屏蔽的号码列表，并为用户执行服务端屏蔽，以阻止不需要的来电和短信通过任何介质（如 VOIP 端点或转接电话）到达用户。

如需了解详细信息，请参阅可下载的 API 参考中的 android.provider.BlockedNumberContract。

9.来电过滤

Android N 允许默认的手机应用过滤来电。手机应用执行此操作的方式是实现新的 CallScreeningService，该方法允许手机应用基于来电的 Call.Details 执行大量操作，例如：
- 拒绝来电
- 不允许来电到达呼叫日志
- 不向用户显示来电通知

如需了解详细信息，请参阅可下载的 API 参考中的 android.telecom.CallScreeningService。

10.多区域设置支持、多语言

Android N 现在允许用户在设置中选择多个区域设置，以更好地支持双语用例。应用可以使用新的 API 获取用户选择的区域设置，然后为多区域设置用户提供更成熟的用户体验 — 如以多个语言显示搜索结果，并且不会以用户了解的语言翻译网页。

除多区域设置支持外，Android N 还扩展了用户可用的语言范围。它针对常用语言提供超过 25 种的变体，如英语、西班牙语、法语和阿拉伯语。它还针对 100 多种新语言添加了部分支持。

应用可以通过调用 LocaleList.GetDefault() 获取用户设置的区域设置列表。为支持扩展的区域设置数量，Android N 正在改变其解析资源的方式。请务必使用新的资源解析逻辑测试和验证您的应用是否能如期运行。

如需有关新资源解析行为和应遵循的最佳做法的更多信息，请参阅多语言支持。

11.Android 中的 ICU4J API

Android N 目前在 Android 框架（位于 android.icu 软件包下）中提供 ICU4J API 的子集。迁移很简单，主要是需要从 com.java.icu 命名空间更改为 android.icu。如果您已在您的应用中使用 ICU4J 捆绑包，切换到 Android 框架中提供的 android.icu API 可以大量节省 APK 大小。

如果要了解有关 Android ICU4J API 的更多信息，请参阅 ICU4J 支持。

12.OpenGL™ ES 3.2 API

Android N 添加了框架接口和对 OpenGL ES 3.2 的平台支持，包括：
- 来自 Android 扩展包 (AEP) 的所有扩展（EXT_texture_sRGB_decode 除外）。
- 针对 HDR 的浮点帧缓冲和延迟着色。
- BaseVertex 绘图调用可实现更好的批处理和流媒体服务。
- 强大的缓冲区访问控制可减少 WebGL 开销。

Android N 上适用于 OpenGL ES 3.2 的框架 API 与 GLES32 类一起提供。使用 OpenGL ES 3.2 时，请务必通过 标记和 android:glEsVersion 属性在您的清单文件中声明要求。

如需了解有关使用 OpenGL ES 的信息，包括如何在运行时检查设备支持的 OpenGL ES 版本，请参阅 OpenGL ES API 指南。

13.Android TV 录制

Android N 通过新的录制 API 添加了从 Android TV 输入服务录制和播放内容的功能。构建在现有时移 API 之上，TV 输入服务可以控制能够录制的渠道数据、保存录制的会话的方式，同时可通过录制的内容管理用户交互。

如需了解详细信息，请参阅 Android TV 录制 API。

14.Android for Work

Android for Work 针对运行 Android N 的设备添加了许多新功能和 API。部分重要内容如下— 有关与 Android N 相关的 Android for Work 更新的完整列表，请参阅 Android for Work 变更。

15.关闭工作

在具有托管配置文件的设备上，用户可以切换工作模式。工作模式关闭时，管理的用户临时关闭，其禁用托管配置文件应用、后台同步和通知。这包括配置文件所有者应用。关闭工作模式时，系统显示永久状态图标，以提醒用户他们无法启动工作应用。启动器指示该工作应用和小组件无法访问。

16.Always on VPN

设备所有者和配置文件所有者可以确保工作应用始终通过指定的 VPN 连接。系统在设备启动后自动启动该 VPN。

新的 DevicePolicyManager 方法为 setAlwaysOnVpnPackage() 和 getAlwaysOnVpnPackage()。

由于 VPN 服务无需应用交互即可由系统直接绑定，因此，VPN 客户端必须针对 Always on VPN 处理新的入口点。和以前一样，由与操作匹配的 Intent 过滤器将服务指示给系统。android.net.VpnService。

用户还可以使用 Settings>More>Vpn 在主要用户中手动设置实现 VPNService 方法的 Always on VPN 客户端。

17.辅助工具增强功能

Android N 现在针对新的设备设置直接在欢迎屏幕上提供“Vision Settings”。这使用户可以更容易发现和配置他们设备上的辅助工具功能，包括放大手势、字体大小、显示屏尺寸和 TalkBack。

随着这些辅助工具功能更为突出，在启用这些功能后，您的用户更可能试用您的应用。请务必提前启用这些设置测试您的应用。您可以通过 Settings > Accessibility 启用它们。

还是在 Android N 中，辅助工具服务现在可以帮助具有动作障碍的用户触摸屏幕。全新的 API 允许使用人脸追踪、眼球追踪、点扫描等功能构建服务，以满足这些用户的需求。

如需了解详细信息，请参阅可下载的 API 参考 中的 android.accessibilityservice.GestureDescription

18.直接启动

直接启动可以缩短设备启动时间，让注册的应用具有有限的功能，即使在意外重启后。例如，如果当用户睡觉时加密的设备重启，那么注册的警报、消息和来电现在可以和往常一样继续通知用户。这也意味着重启后辅助工具服务会立即可用。

在 Android N 中，直接启动充分利用基于文件的加密，以针对系统和应用数据启用细化的加密策略。为系统和应用数据。系统针对选定的系统数据和显式注册的应用数据使用设备加密的存储。默认情况下，凭据加密的存储可用于所有其他系统数据、用户数据、应用及应用数据。

启动时，系统在受限的模式中启动，仅访问设备加密的数据，不会对应用或数据进行常规访问。如果您有想要在此模式下运行的组件，您可以通过在清单文件中设置标记注册它们。重启后，系统通过广播 LOCKED_BOOT_COMPLETED Intent 激活注册的组件。系统确保注册的设备加密的应用数据在解锁前可用。所有其他数据在用户确认锁定屏幕凭据进行解密前均不可用。

如需了解详细信息，请参阅直接启动。

19.密钥认证

使用硬件支持的密钥库，可更安全地在 Android 设备上创建、存储和使用加密密钥。它们可保护密钥免受 Linux 内核、潜在的 Android 漏洞的攻击，也可防止从已取得 root 权限的设备提取密钥。

为了让硬件支持的密钥库使用起来更简单和更安全，Android N 引入了密钥认证。应用和关闭的设备可使用密钥认证以坚决地确定 RSA 或 EC 密钥对是否受硬件支持、密钥对的属性如何，以及其使用和有效性有何限制。

应用和关闭的设备服务可以通过 X.509 认证证书（必须由有效的认证密钥签署）请求有关密钥对的信息。认证密钥是一个 ECDSA 签署密钥，其在出厂时被注入设备的硬件支持的密钥库。因此，有效的认证密钥签署的认证证书可确认硬件支持的密钥库是否存在，以及该密钥库中密钥对的详细信息。

为确保设备使用安全的官方 Android 出厂映像，密钥认证要求设备 bootloader 向可信执行环境 (TEE) 提供以下信息：

• 设备上安装的操作系统版本和补丁级别
• 验证的启动公钥和锁定状态。

如需了解有关硬件支持的密钥库功能的详细信息，请参阅硬件支持的密钥库指南。

除密钥认证外，Android N 还推出了指纹绑定密钥，在指纹注册时不会撤销。

20.网络安全性配置

在 Android N 中，通过使用说明性网络安全性配置（而不是使用传统的易出错的编程 API（例如，X509TrustManager）），应用可以安全地自定义其安全（HTTPS、TLS）连接的行为，无需任何代码修改。

支持的功能：

• 自定义信任锚。让应用可以针对其安全连接自定义哪些证书颁发机构 (CA) 受信任。例如，信任特定的自签署证书或受限的公共 CA 集。
• 仅调试重写。让应用开发者可以安全调试其应用的安全连接，而不会增加安装基础的风险。
• 明文流量退出。让应用可以防止自身意外使用明文流量。
• 固定证书。这是一项高级功能，让应用可以针对安全连接限制哪些服务器密钥受信任。
  如需了解详细信息，请参阅网络安全性配置。

21.默认受信任的证书颁发机构

默认情况下，针对 Android N 的应用仅信任系统提供的证书，且不再信任用户添加的证书颁发机构 (CA)。如果针对 Android N 的应用希望信任用户添加的 CA，则应使用网络安全性配置以指定信任用户 CA 的方式。

22.APK signature scheme v2

PackageManager 类现在支持使用 APK signature scheme v2 验证应用。APK signature scheme v2 是一个整个文件签名架构，通过检测对 APK 文件进行的任何未经授权更改，可大幅提高验证速度，同时也可加强完整性保证。

为保持向后兼容，在使用 v2 签名架构签署之前，APK 必须先使用 v1 签名架构（JAR 签名架构）签署。对于 v2 签名架构，如果在使用 v2 架构签署后使用额外的证书签署 APK，验证将失败。

APK signature scheme v2 支持稍后将在 N Developer Preview中推出。

23.作用域目录访问

在 Android N 中，应用可以使用新的 API 请求访问特定的外部存储目录，包括可移动媒体上的目录，如 SD 卡。新 API 大大简化了应用访问标准外部存储目录的方式，如 Pictures 目录。应用（如照片应用）可以使用这些 API（而不是使用 READ_EXTERNAL_STORAGE），其授予所有存储目录的访问权限或存储访问框架，从而让用户可以导航到目录。

此外，新的 API 简化了用户向应用授予外部存储访问权限的步骤。当您使用新的 API 时，系统使用一个简单的权限 UI，其清楚地详细介绍应用正在请求访问的目录。

如需了解详细信息，请参阅作用域目录访问开发者文档。

各位看官如果觉得文章不错，帮忙点个赞吧，对于你来说是举手之劳，但对于我来说这就是坚持下去的动力。

最近剛好整理 Android N 的資料Blog 連結：

由於 google 的官方更新項目是不斷增長的，且不少東西也沒有詳細的實務經驗，我就只能看到哪寫到哪。以下是簡單介紹。

看完的，有補充資料

1. Multi-Window Support 多視窗支援
2. Notification Enhancements 通知欄強化
3. Multi-locale Support, More Languages 多地區設定支援，更多語言
4. Doze on the Go 移動時休眠
5. Project Svelte: Background Optimizations 專案 Svelte：背景最佳化
6. Data Saver
7. Quick Settings Tile API 快速設定磚 API
8. Android TV 錄製
9. Network Security Configuration 網路安全性強化
10. Scoped Directory Access 限定範圍目錄存取
11. Virtual Files 虛擬檔案
12. Supporting Direct Boot 直接開機
13. Android for Work Updates
14. Java 8 Language features JAVA 8 支援
15. Profile-guided JIT/AOT Compilation 設定檔指引 JIT/AOT 編譯

底下是還沒細看的（待補充，我決定放到第二篇），一句話結論

1. Vulkan API －新的 3D 渲染 api
2. SurfaceView －請大家用 SurfaceView 取代 TextureView ，比較省電
3. Number Blocking－系統級的 who’s call
4. Call Screening－系統級的 who’ call
5. New Emojis－更多 Emojis
6. ICU4J APIs in Android －更小的 size
7. WebView－Chrome + WebView, Together and Multiprocess
8. OpenGL™ ES 3.2 API－更新
9. Accessibility Enhancements －nope
10. Key Attestation －nope
11. APK Signature Scheme v2－改善驗證速度並增強完整性保證
12. Keyboard Shortcuts Helper－Meta（alt/command） + / to trigger aKeyboard Shortcuts screen
13. Custom Pointer API－自訂游標外觀
14. Sustained Performance API－用來測試 long-running apps
15. Print Service Enhancements－nope
16. FrameMetricsListener API －monitor its UI rendering performance，not limited to the past 120 frames.

Android N 新增一次顯示多個應用程式的支援。 在手持式裝置上，兩個應用程式可以在「分割畫面」模式中並排或上下排列。 在電視裝置上，應用程式能使用「子母畫面」模式，在使用者與另一個應用程式互動時持續播放影片。

這功能其實之前就有其他大廠做過，我想主因其實很簡單，就是在大螢幕機器上，這樣的操作可以有效利用所有的畫面，是個非常直覺的功能。但是相對的對裝置效能更加要求，尤其是對 RAM，這樣的功能實在很難想像在 256 MB 的手機上可以使用。

至於如何使用，官網是這樣說

使用者可以透過下列方式來切換多視窗模式：

• 如果使用者開啟總覽畫面並長按活動標題，就可以將該標題拖曳到畫面醒目提示的部分，將活動放入多視窗模式。
• 如果使用者長按「總覽」按鈕，裝置會將目前的活動放入多視窗模式，並開啟總覽畫面，讓使用者選擇要分享螢幕的另一個活動。

使用者可以在活動分享螢幕時，將一個活動中的資料拖放到另一個活動。 (之前，使用者只能在單一活動內拖放資料)。

ps. 總覽畫面就是 recent app 頁面，也就是大家手機按下右下或是左下的方塊按鈕會出現的畫面，老實說我覺得千言萬語比不上一段影片演示。

看到這邊注意到官網提到的

『Manufacturers of larger devices can choose to enable freeform mode, in which the user can freely resize each activity. If the manufacturer enables this feature, the device offers freeform mode in addition to split-screen mode.』

這個也是文字敘述並不太好理解，簡單來說就是可以像平常操作電腦，可以自由縮放視窗，尤其是在向電視這種超大型畫面上，個人覺得所有做 Android 電視棒的廠商都要好好注意這塊，不過也是需要 app vendor 去支援。

開發方面就不多說，要注意的東西不少。需要注意的是 multi-window activity 的生命週期基本上跟原本一樣，但是仔細想想就知道多視窗操作時就會有其中一個才是 focus 的 window，而沒有 focus 的 window activity 都是處在 onPause 階段，並非 onStop 階段，相對地拿到 focus 的 windows activity 會進入 onResume。

另外就是我很好奇 home app 會是怎麼處理 multi-windows ，之後拿到機子一定要試試看。此外 task queue 的處理也是需要仔細研究。ps. multi-windows mode 下 Android N是可以支援兩個view (兩個Activities之間)交換資訊(multi-window);實作 View.OnDragListener，傳遞 ClipData。(Drag and Drap)

而在此項目之下所衍生的就是『Picture in picture(子母畫面)』，影片演示 ，(TV only)

當使用者從影片返回瀏覽其他內容，您的應用程式可以將影片移入 PIP 模式。

當使用者觀看到影片內容的結尾時，您的應用程式可將影片切換到 PIP 模式。

主畫面顯示系列中下一集的預告或摘要資訊時。您的應用程式可以為使用者提供一個觀賞影片時佇列其他內容的方式。 當主畫面顯示內容選擇活動時，影片繼續在 PIP 模式中播放。

開發上需要注意的基本跟 multi-windows 是一樣的，生命週期，通常進入 onPause 後，影片就會停止播放，因此必須在 onPause 階段作一些處理，讓影片繼續播放，同樣的也必須在 onResume 階段作相對處理。另外需要注意的就是 pip mode 是 240×135 dp。（這很明顯是為了 tv 設計的，可是目前感覺市面上好像還沒有出旗艦款的電視，同時處理子母畫面感覺很吃資源）。

這部份有以下五大改版

1. Template updates: We’re updating notification templates to put a new emphasis on hero image and avatar. Developers will be able to take advantage of the new templates with minimal adjustments in their code.

樣板更新，老實說我覺得沒啥好說，看上面圖最快。使用者可以更加簡單的換成新版的ui

2. Messaging style customization: You can customize more of the user interfacelabels associated with your notifications using the MessagingStyle class. You can configure the message, conversation title, and content view.

訊息風格客製化，其實這個很方便，可以根據情況套入不同的 message style ，其實以前就可以用 客製化 notification ui 的方式達到，但這個很明顯 google 多個規範，讓大家更好做事。

3. Bundled notifications: The system can group messages together, for example by message topic, and display the group. A user can take actions, such as Dismiss or Archive, on them in place. If you’ve implemented notifications for Android Wear, you’ll already be familiar with this model.

通知歸群，這個的中文實在不好翻，看了一下 i/o 影片介紹，個人覺得這個比較符合意義，過去在通知欄裡其實沒啥可以玩得，因為所有的通知都是照時間排序好，彼此之間都是獨立的。但也不是說一定不行，如果有開發 email 的人就會知道有個 style 叫做 inbox ，可以作到類似的事情但是處理實在麻煩。 現在多一個 setGroup() and setGroupSummary() 幫助各位更方便處理這件事情。此外在 api 24 以上 ，系統會自動把4條通知以上歸類成一組，如果怕被系統弄的不好看，請自己先處理吧。

4. Direct reply: For real-time communication apps, the Android system supportsinline replies so that users can quickly respond to an SMS or text message directly within the notification interface.

直接回應，就我所知以往要回覆信件或是 sns， notification 最多能作到的就是利用 pendingIntent 去開啟 activity 進行回應。而這次多了一個新的 api 就是 RemoteInput，配合 message style 可以作到直接在 notificaion 上輸入文字，直接回覆，而不需要離開通知欄。感覺就是為了 Android wear 所設計的，實際上 Android wear 上早已經有了。

5. Custom views: Two new APIs enable you to leverage system decorations, such as notification headers and actions, when using custom views in notifications.

畫面客製化，主要就是多了兩個 api style，這一樣會需要搭配 message style 會更好。
Notification.DecoratedCustomViewStyle: Notification style for custom views that are decorated by the system.
Notification.DecoratedMediaCustomViewStyle :Notification style for media custom views that are decorated by the system.

總結:這次改動頗大，上次有比較大的改版感覺就是 notification service listener。而這次改版則是讓使用者可以有更多操作在 notification上面（受益最明顯的就是 email 這類 app (gmail)），其實這兩種改版都是為了讓 notification 不再像是潑出去的水一樣，就只是個通知，而是提高使用者，activity和 notification 之間的關聯性。ps.甚至在官方 blog 上提到 Android N 的 N 就是 notification。

Android N 現在可讓使用者在 [設定] 中選取多個地區設定，以便以更好的方式支援雙語言使用案例。應用程式可以使用新的 API 取得使用者選取的地區設定，然後為多地區設定使用者提供更精細的使用者體驗 — 例如以多語言顯示搜尋結果，以及不為使用者已經熟知語言的網頁提供翻譯。

簡單來說，過去你只能選擇一種語言作為使用環境，假設是繁體中文，如果 App 並不支援繁體中文那就只能是預設英文，但現在你可以在『設定』裡選擇多個你最習慣的語言與優先權，假設是第一優先是法文（fr_cj），第二是義大利文(it_ch)，如果 App 沒有支援法文，那就會自動找義大利文，如果還是找不到，那才會跳到英文。

對於國籍以及區碼的對應方式也改變。底下用幾張圖表示更加清楚

第一張圖：這是 Android N 之前的作法，當使用者只設定 fr_CH ，但 App Resources 只有 en , de_DE , es_ES , fr_FR , it_IT，那他的比對過程就會是

1. 先確認 fr_CH => 沒有 2. 接者對應國籍 fr => 沒有 3. 最後只好使用預設 en

第二張圖：這是 Android N 的作法，當使用者只設定 fr_CH ，但 App Resources 只有 en , de_DE , es_ES , fr_FR , it_IT（同上），那他的比對過程就會是

1. 先確認 fr_CH => 沒有 2. 接者對應國籍 fr => 也沒有 3.找找看有沒有 Child 區碼對應到，就是 fr_FR 4. 就決定是 fr_FR

第三張圖：這是如果設定兩種以上預設語言 P1: fr_CH , P2: it_CH，但 App Resources 只有 en , de_DE , es_ES , it_IT，那他的比對過程就會是

1. 先確認第一優先 fr_CH => 沒有 2. 接者看國籍 fr => 也沒有 3. 找找看有沒有 Child 區碼對應到 => 還是沒有 4. 那開始找 P2:it_CH => 依然沒有 5. 找國籍 it => 就是沒有 6. 那找找有沒有 Child 區碼對應到，就是 it_IT 7. 就決定是 it_IT

總結：為了加快批配速度，開發者最好能更加精準的給予資源對應。對使用者也是一大方便，有人就是只看的懂 中文和日文，Android 每次沒中文就跳到英文，煩不煩阿

Android 6.0 引進休眠功能，這是可節省電池電力的系統模式，它會在裝置閒置時 (例如放在桌子上或抽屜中) 延後應用程式的 CPU 與網路活動。

現在 Android N 中的休眠功能更進一步進展，『可在移動時節省電池電力』。只要螢幕關閉一段時間且裝置拔除電源的情況下，休眠功能就會將熟悉的 CPU 與網路限制的子集套用到應用程式（Doze applies a subset of the familiar CPU and network restrictions to apps）。這表示即使使用者將裝置放在口袋內時也可以節省電池電力。

原本Android M 的休眠情況只有以下

• 裝置閒置（不包含移動）
• 螢幕關閉
• 裝置拔除電源

那麼『休眠功能就會將熟悉的 CPU 與網路限制的子集』這句是啥？看中英文都不好理解，再進一步就是底下這些情況

• Network access is suspended.
• The system ignores wake locks.
• Standard AlarmManager alarms (including setExact() and setWindow()) are deferred to the next maintenance window.
• • If you need to set alarms that fire while in Doze, use setAndAllowWhileIdle()or setExactAndAllowWhileIdle().
  • Alarms set with setAlarmClock() continue to fire normally — the system exits Doze shortly before those alarms fire.
• The system does not perform Wi-Fi scans.
• The system does not allow sync adapters to run.
• The system does not allow JobScheduler to run

總結：一句話『就算是移動中，沒在用手機我一樣進入休眠模式』，這裡 google 有提供建議 『Using GCM to Interact with Your App While the Device is Idle（we strongly recommend that you use GCM if possible, rather than maintaining your own persistent network connection.）』，對於 GCM 的通知，Android 會有系統級的對應，相對好很多。

專案 Svelte 一直努力在生態系統中讓各種 Android 裝置上系統與應用程式使用最少的 RAM。在 Android N 中，「專案 Svelte」專注於最佳化應用程式在背景執行的方式。

上面就是一段廢話，重點就是 Android 7.0 we‘re removing three commonly-used implicit broadcasts — CONNECTIVITY_ACTION, ACTION_NEW_PICTURE, andACTION_NEW_VIDEO— since those can wake the background processes of multiple apps at once and strain memory and battery. If your app is receiving these, take advantage of the Android 7.0 to migrate to JobScheduler and related APIs instead.

總結:『從 Android 5.0，我就一直拜託大家快使用 JobScheduler，可是你們好像又不太愛用，是不是做的不好阿？那我這次下大招了』google 如是說。
其實就是這三種 action 都有『thundering herd（驚群）』的問題，會造成 action 發出去的那一瞬間，一大堆 service 都醒來，讓 device 變得耗電，且浪費資源，所以這次配合上一段 Doze 來改善這問題。CONNECTIVITY_ACTION，在執行中的AP還是可以用BroadcastReceiver向 Context.registerReceiver()註冊去聽CONNECTIVITY_CHANGE。

• Android 7.0 introduces Data Saver mode, a new system service that helps reduce cellular data use by apps. Data Saver gives users control over how apps use cellular data and lets developers provide more efficient servicewhen Data Saver is on.
• When Data Saver is on, the system blocks background data usage and signals apps to use less data in the foreground wherever possible — such as by limiting bit rate for streaming, reducing image quality, deferring optimistic precaching, and so on.
• Android N 擴充 ConnectivityManager 為應用程式提供擷取使用者的 Data Saver 喜好設定與監視喜好設定變更的方法。所有應用程式應該檢視使用者是否已啟用 Data Saver 並努力限制前景與背景的數據使用量（期許阿，希望大家能加入以下 code）。

ConnectivityManager connMgr = (ConnectivityManager)        getSystemService(Context.CONNECTIVITY_SERVICE);// Checks if the device is on a metered networkif (connMgr.isActiveNetworkMetered()) {  // Checks user’s Data Saver settings.  switch (connMgr.getRestrictBackgroundStatus()) {    case RESTRICT_BACKGROUND_STATUS_ENABLED:    // Background data usage is blocked for this app. Wherever possible,    // the app should also use less data in the foreground.    case RESTRICT_BACKGROUND_STATUS_WHITELISTED:    // The app is whitelisted. Wherever possible,    // the app should use less data in the foreground and background.    case RESTRICT_BACKGROUND_STATUS_DISABLED:    // Data Saver is disabled. Since the device is connected to a    // metered network, the app should use less data wherever possible.  }} else {  // The device is not on a metered network.  // Use data as required to perform syncs, downloads, and updates.}

Data saver 對於 app 的處理流程

總結：看完 i/o 介紹影片之後，又是一個拜託各位用 JobSchedule 的系統級限制（那女講者表情超有趣）。過去對於 Data usage 設定最多只有針對個別 App 的 cellular networks 開啟或關閉。如果有好心的 App (Google 自家 Youtube如下)，了不起在底下加個 APP SETTINGS 讓你開啟 activity 進行流量限制設定。

如果是懶得做的 APP(Facebook 夠大廠了吧)，啥鬼設定都沒有。

快速設定是直接從通知欄顯示關鍵設定與動作的常用簡單方式。在 Android N 中，我們擴充了快速設定的範圍，讓它變得更實用、更便利。

我們也為額外的快速設定磚增加了更多空間，使用者可以透過向左或向右撥動存取分頁顯示區域。我們也讓使用者能夠控制要顯示的快速設定磚與顯示位置 — 使用者只需拖放磚，即可新增或移除它們。

對於開發人員，Android N 也加入了新的 API，讓您定義自己的快速設定磚，以便使用者輕鬆存取您應用程式中的關鍵控制項與動作。

快速設定磚是專為急需或常用的控制項或動作而保留的，它不應該做為啟動應用程式的捷徑。

定義磚之後，您即可將它們顯示給使用者，使用者只需拖放這些磚，即可將它們新增到快速設定中。

如需建立應用程式磚的相關資訊，請參閱可下載之 API 參考資料中的android.service.quicksettings.Tile。

總結：直接看影片最清楚

老實說這東西我開發上也沒有特別玩過，之前都要是裝置開發商才能用，現在終於釋放出來給一般APP 開發者玩 （這樣真的部會出現一大堆在 setting bar 上面嗎？之後可以實驗，一隻 app 到底可以放幾個 tile上去。主要做法須要實作 TileService 去聽 change 且有 permission “android.permission.BIND_QUICK_SETTINGS_TILE"）。（ps. 有機會的話，請我的好同事 J大來談一下這章節，來談談 api 24 之前的 quick settings 開發辛酸史，聽他轉述感覺 google 就是在做他之前的事情啊）

Android N 透過新的錄製 API，新增了錄製和播放 Android TV 輸入服務內容的功能。以現有的時間位移 API 為建置基礎，TV 輸入服務可以控制要錄製哪個頻道的資料、如何儲存已錄製的時段，以及管理使用者與錄製內容的互動。

如需詳細資訊，請參閱 Android TV 錄製 API。

總結：沒用過也沒玩過，但感覺很方便。歡迎大家提供看法。

路安全性設定功能，讓應用程式在安全的宣告式設定檔中即可自訂網路安全性設定，而不必修改應用程式的程式碼。 這些設定可以針對特定網域以及針對特定應用程式來設定。主要有以下四點。

這一段真的比較是屬於開發層面，目前還是比較少碰一塊，希望我的理解是對得，也歡迎各位指教

1. Custom trust anchors:Customize which Certificate Authorities (CA) are trusted for an app’s secure connections. For example, trusting particular self-signed certificates or restricting the set of public CAs that the app trusts.

設定自憑證 ＆ 限止信任的 CA 組

信任其他 CA

自訂信任錨點: 其實只看上面的 xml code ，個人很直覺得就是把以前對 ssl(Secure Sockets Layer) 的處理由程式碼轉換到 google xml 的規範化，這確實可以有效降低開發者的苦工。以前的玩法就是在 Android 裡使用 HttpUrlConnection 使用 TrustManager 去處理。事實上大部分開發下不少開發者是不太處理這塊，主要是因為 Android 已經預先把合法發行單位（VeriSign）的憑證都拉進來。而比較特殊的情況則是開發者自己需要連線到自己的 server 作存取，然後又不想使用發行單位發行的憑證，原因其實蠻簡單，就是送去發行單位一年大概要繳費 100 – 500 美金，且大部分 app 會存取的 server 都蠻固定（股票:通常會要求使用個人 CA，信件:通常會自己 Import 公司的 CA….）。

以下為過去的寫法，為了處理自發行憑證，不少 google c/p（就是我） 工程師就會犯一些錯誤，第一段程式碼會信任所有的 CA ，這樣搞的話有 SSL 跟沒 SSL 是一樣的。

import org.apache.http.conn.ssl.SSLSocketFactory;public class MySSLSocketFactory extends SSLSocketFactory {    SSLContext sslContext = SSLContext.getInstance("TLS");    public MySSLSocketFactory(KeyStore truststore) throws NoSuchAlgorithmException, KeyManagementException, KeyStoreException, UnrecoverableKeyException {        super(truststore);        TrustManager tm = new X509TrustManager() {            public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {            }            public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {            }            public X509Certificate[] getAcceptedIssuers() {                return null;            }        };        sslContext.init(null, new TrustManager[] { tm }, null);   }    @Override    public Socket createSocket(Socket socket, String host, int port, boolean autoClose) throws IOException, UnknownHostException {        return sslContext.getSocketFactory().createSocket(socket, host, port, autoClose);    }    @Override    public Socket createSocket() throws IOException {        return sslContext.getSocketFactory().createSocket();    }}

而以下這段則是 買一套送全部的典型範例，當憑證接受其中一個網站的 server ，那麼其他的也統統都接受了

HostnameVerifier hostnameVerifier = org.apache.http.conn.ssl.SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER;DefaultHttpClient client = new DefaultHttpClient();SchemeRegistry registry = new SchemeRegistry();SSLSocketFactory socketFactory = SSLSocketFactory.getSocketFactory();socketFactory.setHostnameVerifier((X509HostnameVerifier) hostnameVerifier);registry.register(new Scheme("https", socketFactory, 443));SingleClientConnManager mgr = new SingleClientConnManager(client.getParams(), registry);DefaultHttpClient httpClient = new DefaultHttpClient(mgr, client.getParams());// Set verifier     HttpsURLConnection.setDefaultHostnameVerifier(hostnameVerifier);// Example send http requestfinal String url = "https://www.pchome.com”HttpPost httpPost = new HttpPost(url);HttpResponse response = httpClient.execute(httpPost);HttpsURLConnection.setDefaultHostnameVerifier(hostnameVerifier);HostnameVerifier hostnameVerifier = org.apache.http.conn.ssl.SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER;

扯的這邊有點遠了，主要是想把前因後果還有耍笨的故事寫一下。另外不知道有沒有人覺得 raw/my_ca 這樣寫會有問題，如果被反組譯，那這個 CA 憑證不是很危險嗎？根據小組討論，感覺這個 ca 應該單純只是個公鑰，或是只是單純為了範例簡單寫而已 ，歡迎有高手幫忙解答。

2. Debug-only overrides:Safely debug secure connections in an app without added risk to the installed base.

設定 CA 進行偵錯：「只」有在 android:debuggable 為 true 時才予以信任。就是實用測試功能，可以把在 code 裡面的 DEBUG 搬出來。因為 play store 採取的安全措施是，不接受標示為可偵錯的應用程式，所以這種方式會比條件式程式碼安全。

3. Cleartext traffic opt-out:Protect apps from accidental usage of cleartext traffic.

退出明碼流量：打算只使用安全連線連線至目的地的應用程式，可以針對那些目的地退出支援明碼 (使用未加密的 HTTP 通訊協定，而非 HTTPS)。 此選項有助於避免應用程式由於外部來源 (例如，後端伺服器) 提供的 URL 中發生變更，而造成意外回復。 如需更多詳細資料，請參閱 NetworkSecurityPolicy.isCleartextTrafficPermitted()。『

This flag is honored on a best effort basis because it’s impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there’s no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext. However, most network traffic from applications is handled by higher-level network stacks/components which can honor this aspect of the policy.

NOTE: WebView does not honor this flag.』

例如上面，應用程式想要確保 http://secure.example.com 的所有連線一律要透過 HTTPS 完成，以保護敏感流量不受惡意網路危害。

補充：在 API level 23. 有加入這個 android:usesCleartextTraffic，但這個是所有網域都被限制住，預設值是 true (for example, HTTP and FTP stacks, DownloadManager,MediaPlayer)

4. Certificate pinning:Restrict an app’s secure connection to particular certificates.

關聯憑證：

應用程式一般會信任所有預先安裝的 CA。若這類的任何 CA 意在發行詐騙憑證，應用程式會有遭受 MiTM 攻擊的風險。 有些應用程式選擇透過限制所信任的 CA 組或關聯憑證，來限制可接受的憑證組。

憑證關聯的方法是，透過公用金鑰的雜湊 (X.509 憑證的 SubjectPublicKeyInfo) 來提供一組憑證。 只有當憑證鏈至少包含一個關聯的公用金鑰時，才是有效的憑證鏈。

請注意，使用憑證關聯時，您務必要包括備份金鑰，這樣萬一強制您切換到新的金鑰或變更 CA (關聯到 CA 憑證或該 CA 的中繼者) 時，您的應用程式連線才不會受到影響。 否則，您必須推出應用程式更新，才能還原連線。

總結：這段我只有在開發 mail 時有稍微涉略。沒辦法給出更多實務上的感想。但看得出來 google 從 M 開始就非常注意，但是 M 所在意的則是 device 操作以及使用者資料的權限安全，而 N 則是更加強化網路安全這塊。看起來應該是發生過太多問題啦。

應用程式 (例如，相片應用程式) 通常只需要存取外部儲存空間中的特定目錄，例如 Pictures 目錄。 目前用來存取外部儲存空間的方式並非設計來輕鬆地為這些類型的應用程式提供已設定目標的目錄存取。 例如：

• 在您的宣示說明中要求 READ_EXTERNAL_STORAGE 或 WRITE_EXTERNAL_STORAGE 可允許存取外部儲存空間ac上的所有公用目錄，但這可能超過您應用程式所需的存取權。
• 使用儲存空間存取架構通常會使得您的使用者透過系統 UI 挑選目錄，這在您的應用程式一律存取相同外部目錄的情況下是不必要的。

Android N 提供新的簡化 API，可用來存取常用外部儲存空間目錄。

// 開啟主要共用儲存空間中的 <code>Pictures</code> 目錄StorageManager sm = (StorageManager)getSystemService(Context.STORAGE_SERVICE);StorageVolume volume = sm.getPrimaryVolume();Intent intent = volume.createAccessIntent(Environment.DIRECTORY_PICTURES);startActivityForResult(intent, request_code);

並向使用者確認權限

存取外部空間則需要，另外宣告

// BroadcastReceiver has already cached the MEDIA_MOUNTED// notification Intent in mediaMountedIntentStorageVolume volume = (StorageVolume)    mediaMountedIntent.getParcelableExtra(StorageVolume.EXTRA_STORAGE_VOLUME);volume.createAccessIntent(Environment.DIRECTORY_PICTURES);startActivityForResult(intent, request_code);

總結：一直到目前，幾乎所有的 app 開發對於 store access 權限都是全有或是全無，這對使用者會在給予權限感到恐慌。google 也不是沒有想過這問題，就是在 kitkat 時加入的 Storage Access Framework 讓使用者自己挑選資料夾給予存取，但老實說我還真的很少看到會使用 SAF 的 app ，主要還是因為使用者會覺得太麻煩，總和『好麻煩』和『通天的權限』兩個問題， 就希望能取消兩大資料存取權限，然後針對固定通用型的系統資料夾做出簡化操作，改成發 intent 的方式去請系統幫忙保證資料的存取範圍。ps.取得對特定外部目錄的存取權也會取得對該目錄之子目錄的存取權。

In previous versions of Android, your app could use the Storage Access Frameworkto allow users to select files from their cloud storage accounts, such as Google Drive. However, there was no way to represent files that did not have a direct bytecode representation; every file was required to provide an input stream.

Android 7.0 adds the concept of virtual files to the Storage Access Framework. The virtual files feature allows your DocumentsProvider to return document URIs that can be used with an ACTION_VIEW intent even if they don’t have a direct bytecode representation. Android 7.0 also allows you to provide alternate formats for user files, virtual or otherwise.

To get a URI for a virtual document in your app, first you create an Intent to open the file picker UI. Since an app cannot directly open a virtual file by using theopenInputStream() method, your app does not receive any virtual files if you include the CATEGORY_OPENABLE category.

After the user has made a selection, the system calls the onActivityResult() method. Your app can retrieve the URI of the virtual file and get an input stream, as demonstrated in the code snippet below.

師爺來說說這是啥，就是以前雖然可以利用 Storage Access Framework 拿到雲端空間的 URI，但是因為雲端文件沒有在本地端的直接 bytecode 那就無法被顯示出來讓使用者選擇（這段話超難理解，簡單來說就是 ACTION_VIEW intent 沒辦法找到這個雲端文間 URI 的檔案），那現在加入 virtual file 的概念，這東西可以被 DocumentsProvider 找到，但是畢竟 virtual file 並不存在於 local ，所以就算現在可以用 ACTION_VIEW 找到， openInputStream 依然無法存取 byte code.那要怎麼辦呢，我給你 code 你參考參考。

千言萬語不如來段 code

// Other Activity code ...  final static private int REQUEST_CODE = 64;  // We listen to the OnActivityResult event to respond to the user's selection.  @Override  public void onActivityResult(int requestCode, int resultCode,    Intent resultData) {      try {        if (requestCode == REQUEST_CODE &&            resultCode == Activity.RESULT_OK) {            Uri uri = null;            if (resultData != null) {                uri = resultData.getData();                ContentResolver resolver = getContentResolver();                // Before attempting to coerce a file into a MIME type,                // check to see what alternative MIME types are available to                // coerce this file into.                String[] streamTypes =                  resolver.getStreamTypes(uri, "*/*");                AssetFileDescriptor descriptor =                    resolver.openTypedAssetFileDescriptor(                        uri,                        streamTypes[0],                        null);                // Retrieve a stream to the virtual file.                InputStream inputStream = descriptor.createInputStream();            }        }      } catch (Exception ex) {        Log.e("EXCEPTION", "ERROR: ", ex);      }  }

底下是一般情況，非 virtual file

@Overridepublic void onActivityResult(int requestCode, int resultCode,        Intent resultData) {    // The ACTION_OPEN_DOCUMENT intent was sent with the request code    // READ_REQUEST_CODE. If the request code seen here doesn't match, it's the    // response to some other intent, and the code below shouldn't run at all.    if (requestCode == READ_REQUEST_CODE && resultCode == Activity.RESULT_OK) {        // The document selected by the user won't be returned in the intent.        // Instead, a URI to that document will be contained in the return intent        // provided to this method as a parameter.        // Pull that URI using resultData.getData().        Uri uri = null;        if (resultData != null) {            uri = resultData.getData();            Log.i(TAG, "Uri: " + uri.toString());            showImage(uri);        }    }}

總結：無感，因為我還是不太理解直接的應用點在哪？而且他的英文描述不太好懂，希望我沒有理解錯。歡迎大家指教。

直接開機可加速裝置啟動時間，並讓已註冊的應用程式只能使用有限的功能 (即使在未預期的重新開機之後)。例如，如果一個加密裝置在使用者睡覺時重新開機，已註冊的鬧鐘、訊息與來電現在可以持續如常通知使用者。這也表示協助工具服務在重新啟動之後可立即使用。

為了達到上述的目的，Android N 會在一個安全的 直接開機 模式下執行，這是裝置已經開啟電源但使用者尚未解鎖裝置的期間。 為了支援這種方式，系統為資料提供兩個儲存位置：

• 認證加密的儲存空間：這是預設的儲存位置，只有在使用者解鎖裝置之後才能使用。
• 裝置加密的儲存空間：這是「直接開機」模式期間與使用者解鎖裝置之後都可以使用的儲存位置。

這個部分我認為應該和 file-based encryption (FBE) 一起看，在 Android N 之前全部都是 full-disk encryption ，而這一版改成 FBE ，這直接受益部分就是直接開機。

『File-based encryption enables a new feature introduced in Android 7.0 calledDirect Boot. Direct Boot allows encrypted devices to boot straight to the lock screen. Previously, on encrypted devices using full disk encryption (FDE), users needed to provided credentials before any data could be accessed, preventing the phone from performing all but the most basic of operations。』

由於可以在兩種空間上進行切換，那對於開發者來說需要注意的是 切換點以及兩邊資料整合。先註冊 broadcastReceiver

android.intent.action.ACTION_LOCKED_BOOT_COMPLETED

Getting Notified of User Unlock

• If your app has foreground processes that need immediate notification, listen for the ACTION_USER_UNLOCKED message.
• If your app only uses background processes that can act on a delayed notification, listen for the ACTION_BOOT_COMPLETED message.

Migrating Existing Data

Use Context.moveSharedPreferencesFrom() and Context.moveDatabaseFrom() to migrate preference and database data between credential encrypted storage and device encrypted storage.

Context directBootContext = appContext.createDeviceProtectedStorageContext();// Access appDataFilename that lives in device encrypted storageFileInputStream inStream = directBootContext.openFileInput(appDataFilename);// Use inStream to read content...

總結：我怎麼覺得 mtk 有個關機鬧鐘，那到底怎麼弄的。這次 Android N 在系統層面的安全性真的強化不少。

來段廣告詞『Android for Work 是協助企業使用 Android 的方案，包括 Android 的產品功能、Google Play for Work 及其他生產力工具。Android for Work 主要透過 API 發佈，可讓企業行動管理服務 (EMM) 供應商和企業應用程式開發商為客戶員工提供安全、有效率而多元化的行動環境。

• Work profile security challenge
• 設定檔擁有者可以為以工作設定檔執行之應用程式指定個別的安全性查問。當使用者嘗試開啟任何工作應用程式時會顯示工作查問。成功完成安全性查問可將工作設定檔解鎖並在必要時將它解密。
• Toggle Work Mode
• 在具有工作設定檔的裝置上，使用者可以切換工作模式。當工作模式關閉時，受管理的使用者會暫時關機，因此而停用工作設定檔應用程式、背景同步與通知。這也包括設定檔擁有者應用程式。當工作模式關閉時，系統會顯示持續的狀態圖示，提醒使用者他們無法啟動工作應用程式。啟動器會指出工作應用程式和小工具無法存取。
• Always-On VPN
• 裝置擁有者和設定檔擁有者可確保工作應用程式一律透過指定的 VPN 連線。系統會自動在裝置開機時啟動該 VPN。新的 DevicePolicyManager 方法是setAlwaysOnVpnPackage() 與 getAlwaysOnVpnPackage()。因為系統無需透過應用程式互動即可直接連結 VPN 服務，所以 VPN 用戶端需要為「一律開啟的 VPN」處理新的進入點。正如以往，透過符合動作android.net.VpnService 的意圖篩選器向系統指明服務。使用者也可以使用 [設定] > [更多] > [VPN] 手動設定「一律開啟的 VPN」用戶端，這些用戶端在主要使用者中實作 VPNService 方法。
• Customized provisioning
• An application can customize the profile owner and device owner provisioning flows with corporate colors and logos. DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR customizes flow color.DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URIcustomizes the flow with a corporate logo.
• 使用者可以自己定義驗證流程的主要顏色，或是放置公司 logo 。。

總結：這個我真的連玩都沒玩過，更別說開發。感覺 always-on vpn 還蠻實用的。google 真的越來越重視 BYOD，除了區分工作與個人，安全性更是一大重點。我在看 api 時發現可以直接讀取公司的 calendar, email user contact。感覺很好用啊。

Android does not currently support all Java 8 language features. However, the following features are now available when developing apps targeting the Android N Preview:

須使用 Android Studio 2.1 (預覽版) 與 Android N Preview SDK，其中包括必要的 Jack tool chain 與適用於 Gradle 的已更新 Android 外掛程式。

• Default and static interface methods
• Lambda expressions (also available on API level 23 and lower)
• Repeatable annotations
• Method References (also available on API level 23 and lower)
• Type Annotations (also available on API level 23 and lower)

總結：千呼萬喚始出來，第二項的 Lambda 這東西從好久之前就不少人很想拉進 Android，還弄個 Retrolambda 來嚐鮮，不過我個人用的不太習慣啊。此外，都已經提到 Java 8 ，那怎麼可以不提 Jack (Java Android Compiler Kit ) and Jill (Jack Intermediate Library Linker)，但目前看起來效能差異不大，最直接受益就是沒有 『65k method limit』 問題。

• Legacy javac toolchain:
  javac (.java → .class) → dx (.class → .dex)
• New Jack toolchain:
  Jack (.java → .jack → .dex)

然後這裡有個大神寫得非常好，Android 新一代编译 toolchain Jack & Jill 简介

Profile-guided JIT/AOT Compilation 設定檔指引 JIT/AOT 編譯

在 Android N 中，我們新增了 Just in Time (JIT) 編譯器搭配程式碼分析工具到 ART，讓 Android 應用程式在執行時能夠持續改善其效能。JIT 編譯器補充了 ART 目前的 Ahead of Time (AOT) 編譯器，協助改善執行階段效能、節省儲存空間以及加速應用程式更新和系統更新。

設定檔指引編譯讓 ART 根據每個應用程式的實際用情形與裝置上的情況來管理其 AOT/JIT 編譯。例如，ART 會維護每個應用程式常用方法的設定檔，而且可以預先編譯和快取那些方法以獲得最佳效能。它不會編譯應用程式的其他部分，直到實際要使用這些部分時才會編譯。

除了改善應用程式關鍵部分的效能以外，設定檔指引編譯還有助於降低應用程式的整體 RAM 使用量，包括關聯的二進位檔案。此功能對於低記憶體裝置特別重要。

ART 透過對裝置電池產生最小影響的方式來管理設定檔指引編譯。它只會在裝置閒置和充電時預先編譯，這種預先工作的方式可以節省時間和電池電力。

總結：Android M 的時候，只有在 apk 安裝時才會編譯。這個說來慚愧，敝司曾經出過一隻超低階手機（512mb 還是 256 mb），系統更新慢到以為當機，但是等個２０分鐘，還是成功了，但是好戲還在後頭，居然不能安裝 facebook app , 這還能賣嗎？就是因為安裝時編譯消耗大量 RAM ，但是手機太爛了，就當機了，就當機了，就當機了。我想可能就是上面這些問題，所以還是退回部分先編譯這樣折衷的方式。

第一篇就到此為止，剩下的會在第二篇補完(希望)，如果有任何問題或是我寫錯的部分，歡迎底下回應。有興趣且有機子的人可以利用 Google Sample進行測試。

reference:
官方
官方影片
FB 上的 Scott Tsai 的感想
为你的安卓应用实现自签名的 SSL 证书
从开发者角度解析 Android N 新特性！
Android M新特性Doze and App Standby模式详解 – 不能轉載
Android 6.0电源管理方式
Android N的五項全新功能（加上分屏）
Android Nougat(7.0) 下拉通知栏创建自定义快捷设置