In Sep 2008, Android provided developers with the ability to use GPS location with app users’ permission as part of the first Android 1 (API 1). Millions of apps have been built using location-based services in creative ways since then. As more apps started using location in the background, and sending this data to servers for use by applications outside the device, Android started setting some rules of the game to manage battery drain and user privacy. Beginning with Android 8 (API 26) in Aug 2017, the platform has evolved significantly with regard to location access controls. In this post, we review the changes from Android 8 to 10, and take a look beyond to Android 11. In particular, we look at how this impacts product development teams building live location apps.
在2008年9月，Android作为第一个Android 1(API 1)的一部分，为开发人员提供了在具有应用程序用户许可的情况下使用GPS位置的功能。 自那时以来，已经使用基于位置的服务以创造性的方式构建了数百万个应用程序。 随着越来越多的应用程序开始在后台使用位置信息，并将此数据发送到服务器供设备外部的应用程序使用，Android开始设置游戏规则以管理电池消耗和用户隐私。 从2017年8月的Android 8(API 26)开始，该平台在位置访问控制方面已经有了显着发展。 在本文中，我们回顾了从Android 8到10的变化，并进一步介绍了Android11。特别是，我们研究了这如何影响构建实时定位应用的产品开发团队。
Android 8(Oreo)区分前景和背景 (Android 8 (Oreo) distinguishes foreground and background)
Android Oreo (Android 8 / API 26) was the first OS update to impose meaningful restrictions on app developer’s ability to access location by distinguishing between foreground and background apps. Prior to Android 8, apps with location permissions could access that data in any form they liked, which adversely impacted device battery and user privacy.
Android Oreo (Android 8 / API 26)是第一个OS更新，通过区分前台和后台应用程序，对应用程序开发人员访问位置的能力施加了有意义的限制。 在Android 8之前的版本中，具有位置权限的应用可以按自己喜欢的任何形式访问该数据，这会对设备电池和用户隐私产生不利影响。
Remember that time in Nov 2016 when news hit the wire that Uber started background collection of rider location data? There had already been years of chatter about Google Maps tracking you in the background, and we learnt to look away because Google Maps and Android were two products from the same company. The Uber exposé felt more drastic, users awakened en masse, and mobile Operating Systems had to act decisively.
还记得2016年11月的那段时间，当时有新闻报道Uber开始对骑手位置数据进行后台收集吗？ 关于Google Maps在后台跟踪您已经有很多年的讨论了，我们学会了移开目光，因为Google Maps和Android是同一公司的两种产品。 Uber博览会更加激烈，用户被集体唤醒，移动操作系统必须果断行动。
Android 8 clarified that “in an effort to reduce power consumption”:
Android 8阐明了“为了减少功耗”：
- “The system distinguishes between foreground and background apps” and goes on to clearly define each.“系统区分前台和后台应用程序”，并继续明确定义每个应用程序。
- The system “limits how frequently background apps can retrieve the user’s current location. Apps can receive location updates only a few times each hour.”该系统“限制后台应用可以检索用户当前位置的频率。 应用程序每小时只能接收几次位置更新。”
The system allows apps to start a foreground service to “retrieve location updates more frequently”, though clarifies that “when such a foreground service is active, it appears as an ongoing notification in the notification area” (a.k.a. persistent notification)
该系统允许应用程序启动前台服务以“更频繁地检索位置更新”，尽管它阐明了“当此类前台服务处于活动状态时，它在通知区域中显示为正在进行的通知 ”(又名持久性通知)。
While the release cited battery efficiency as the main driving force behind the changes, it was no coincidence that Uber ended its post-ride tracking of users’ location a week after the release of Android 8 in Aug 2017.
虽然该版本将电池效率视为更改背后的主要驱动力，但在2017年8月发布Android 8一周后， Uber终止了对用户位置的骑乘追踪并不是偶然的。
What did these mean for apps that wanted to access location in the background with higher frequency than few times each hour, and do so with explicit user permission? This was still possible to do by starting a foreground service in the app.
对于希望每小时在后台访问频率高于几次且具有明确用户许可的应用程序，这意味着什么？ 通过在应用程序中启动前台服务，仍然可以做到这一点。
Let me distinguish between foreground apps, background apps, and foreground services with some examples.
让我通过一些示例来区分前台应用程序，后台应用程序和前台服务。
前台应用 (Foreground app)
A navigation app like Google Maps is naturally used in the foreground. The app uses GPS location with high frequency and pulls up map data from the server so users can get turn-by-turn directions in real-time while driving. From the user’s perspective, the data remains private on the device to serve the navigation use case. However, navigation apps might choose to store this data and send it to the server for telemetry to improve maps for everyone.
诸如Google Maps这样的导航应用自然会在前台使用。 该应用程序使用高频GPS定位，并从服务器提取地图数据，因此用户可以在驾驶时实时获取转弯方向。 从用户的角度来看，数据在设备上保持私有状态以服务于导航用例。 但是，导航应用程序可能选择存储此数据，然后将其发送到服务器进行遥测，以改善所有人的地图。
后台应用 (Background app)
Local search or content apps like the ones we use to check the weather, or find restaurants, or get news, use location to figure out where you are. Many of these apps track background location as specified by Android, and would count as background apps. “Few times each hour” is meaningful when you add up millions of users. Users are often unaware of such tracking and this data might be used for advertising, or find its way to data brokers who sell it to anyone who is willing to pay for it!
本地搜索或内容应用(例如我们用来查看天气，查找餐厅或获取新闻的应用)，可以使用位置来确定您的位置。 这些应用程序中有许多会跟踪Android指定的背景位置，因此会算作背景应用程序。 当您增加数百万个用户时，“每小时很少几次”是有意义的。 用户通常不知道这种跟踪，并且这些数据可能会用于广告宣传，或者找到将其出售给愿意将其出售给愿意付款的任何人的数据经纪人的方式！
前台服务 (Foreground services)
Logistics, gig work and delivery apps like the ones used by drivers in the supply chain of commerce, need not be in the foreground at all times. However, business needs to access location at a higher frequency for routing orders, tracking progress, sharing live location with customers, and expensing miles.
物流，演出工作和交付应用程序(例如，商业供应链中的驱动程序所使用的应用程序)不必始终处于前台。 但是，企业需要以更高的频率访问位置以发送订单，跟踪进度，与客户共享实时位置并花费里程。
To power experiences that users want, many consumer apps might require higher frequency location access in the background too. For instance, social apps that power live location sharing between friends with mutual opt-in, two sided marketplaces with live location sharing to consummate transactions offline, and other consumer apps in health, finance and insurance where the user lets the service track frequent locations for direct personal benefit.
为了增强用户想要的体验，许多消费者应用程序可能也需要在后台进行更高频率的位置访问。 例如，可以通过相互选择加入来支持朋友之间的实时位置共享的社交应用，具有实时位置共享以离线完成交易的双向市场以及健康，金融和保险中的其他消费者应用，用户可以通过该应用跟踪服务的频繁位置直接的个人利益。
Turns out, there are hundreds of thousands of apps that fall in this category of tracking movement with user permission. In Android 8, these apps start a foreground service that allows access to location even while the app is in the background. The user will see a persistent notification for these apps so there is clear communication that the app is using a foreground service even while the user is on another app or has the phone in the pocket.
事实证明，有成千上万的应用程序属于此类具有用户权限的跟踪移动。 在Android 8中，这些应用程序会启动一个前台服务 ，即使在后台运行该应用程序也可以访问位置。 用户将看到这些应用程序的持续通知，因此即使用户在另一个应用程序上或手机放在口袋里，也可以清楚地通信该应用程序正在使用前台服务。
Android 9(Pie)进行增量更改 (Android 9 (Pie) makes incremental changes)
Android Pie (Android 9 / API 28) made incremental updates with respect to location access. Android 9 closed some long standing security loopholes. Before Android 9, apps could use Mozilla Location Services or similar services to determine “location based on network infrastructure like Bluetooth beacons, cell towers and WiFi access points” without location permissions from the user. After Android 9, these APIs require the same permission as location APIs. It may be noted that fused location provider merges GPS with network infrastructure to provide accurate user location. It is the ability to circumvent location permissions that got shut with Android 9. It is natural for such vulnerabilities to exist and it was a great move by Android 9 to fix it. Legit businesses were not impacted by this change.
Android Pie (Android 9 / API 28)对位置访问进行了增量更新。 Android 9消除了一些长期存在的安全漏洞。 在Android 9之前，应用程序可以使用Mozilla定位服务或类似的服务来确定“基于网络基础设施的位置，例如蓝牙信标，基站和WiFi接入点”，而无需用户的位置许可。 在Android 9之后，这些API需要与位置API相同的权限。 可能要注意的是， 融合的位置提供商将GPS与网络基础设施合并，以提供准确的用户位置。 绕过位置权限的功能是Android 9所关闭的。这种漏洞的存在是很自然的，Android 9对其进行了修复是一个不错的举措。 合法业务不受此更改的影响。
Android 10明确显示背景权限 (Android 10 makes background permission explicit)
Android 10 (API 29) made an important privacy update with “more user control over location permissions”. Remember background apps that get location permissions to check weather and local news, and then track you a few times an hour anyway, even when you are not using the app? These apps now require explicit user permission to access background location.
Android 10 (API 29)通过“对位置权限的更多用户控制”进行了重要的隐私更新 。 还记得后台应用程序获得位置权限以检查天气和当地新闻，然后即使一个小时不使用它，仍然每小时跟踪您几次，即使您不使用该应用程序也是如此？ 这些应用程序现在需要明确的用户权限才能访问后台位置 。
Apps that start a foreground service, as discussed earlier in the context of tracking commercial movement, can continue to track frequent locations in the background. App developers need to declare a special service property and publish an app update that targets Android 10. Once the user has updated the app, location tracking will continue as before with no change in user flow. As before, users will continue to see persistent notifications for apps with foreground service for location.
如前面在跟踪商业活动的上下文中所述，启动前台服务的应用程序可以继续跟踪后台的频繁位置。 应用程序开发人员需要声明一个特殊的服务属性，并发布针对Android 10的应用程序更新。一旦用户更新了应用程序，位置跟踪将像以前一样继续进行，用户流不会发生变化。 和以前一样，用户将继续看到具有前台服务定位的应用程序的持久性通知。
Not only did Android 10 let go of dessert names (after a last attempt to name it Android Q for Queen Cake), it deserted background apps secretly tracking locations of consumers who did not intend to be tracked. This is a healthy development for the world of apps, and we expect further improvements in this direction with Android 11 coming up in the Fall of 2020.
Android 10不仅放开了甜点的名称(在最后一次尝试将它命名为Queen Cake的Android Q之后)，它还放弃了后台应用程序，秘密地跟踪了不希望被跟踪的消费者的位置。 对于应用程序世界来说，这是一个健康的发展，并且随着2020年秋季Android 11的发布，我们希望朝着这个方向进一步改进。
Android 11将添加细粒度的控件 (Android 11 will add fine grained control)
Android 11 is expected to release in Q3 this year, with further improvements in user privacy. Users will get more fine-grained controls over location permissions. Specifically,
预计Android 11将于今年第三季度发布，并进一步改善用户隐私。 用户将获得对位置权限的更多细粒度控制 。 特别，
- Apps will be required to handle one-time permissions where users grant temporary access to location. Apps will need to be “designed to handle situations where data access can be lost when the user moves away from the app and the app can request the permission again”.在用户授予对位置的临时访问权限时，应用将需要处理一次性权限。 应用程序将需要“被设计为处理当用户离开应用程序并且应用程序可以再次请求权限时丢失数据访问的情况”。
- In addition, background apps will need to “request foreground (coarse or fine) and background location permissions incrementally in separate calls to the permission request method. Before each request, use a full screen view to explain the benefits that users receive for granting that permission”.此外，后台应用程序将需要在对权限请求方法的单独调用中逐步“请求前台(粗略或精细)和后台位置权限”。 在每个请求之前，请使用全屏视图说明用户授予该权限所获得的好处。”
其他注意事项 (Other considerations)
Despite having all necessary location permissions from the user, there are certain scenarios when the app will encounter location outage from the Android platform. This is not an exhaustive list, though representative of issues that developers are likely to encounter in a production environment of a meaningful size.
尽管拥有用户的所有必要位置权限，但在某些情况下，应用会遇到Android平台的位置中断的情况。 这并不是详尽的清单，尽管代表了开发人员在有意义尺寸的生产环境中可能遇到的问题。
- User may revoke access for the device (applies to all apps) after first granting access in the app在首次授予应用访问权限后，用户可以撤消对设备的访问权限(适用于所有应用)
- User may revoke access specifically for your app after first granting access in the app用户可以先在应用中授予访问权限，然后专门撤销对您应用的访问权限
- User may force stop the app through settings, thus killing location access for the app用户可能会通过设置强制停止应用程序，从而终止了该应用程序的位置访问权限
- Device may enter low battery or battery saver mode that causes location access to be suspended in uncertain ways设备可能会进入电池电量不足或省电模式，从而导致位置访问以不确定的方式暂停
- Device may enter an area, like a subway or basement, where locations are unavailable but location service pretends to behave normally设备可能会进入位置不可用但位置服务冒充正常运行的区域，例如地铁或地下室
原生v混合 (Native v Hybrid)
A side impact of the updates in Android 8 onwards is that location APIs will require native app development. Direct control through hybrid frameworks like React Native, Flutter, Cordova, Ionic or Xamarin will no longer work. Hybrid app developers will need to build native functionality for location access.
Android 8及更高版本的更新的副作用是，位置API将需要本机应用程序开发。 通过混合框架(例如React Native，Flutter，Cordova，Ionic或Xamarin)的直接控制将不再起作用。 混合应用程序开发人员将需要构建本机功能以进行位置访问。
摘要 (Summary)
In the last three years, location access on Android has evolved from a binary allow/deny state, to few times an hour throttle for background location and persistent notifications for foreground service, to plugging a security loophole to get non-GPS location, to explicit permissions for throttled background location. The future brings granular privacy controls with one-time access, and incremental permissions from foreground to background.
在过去的三年中，Android上的位置访问已从二进制的允许/拒绝状态演变为背景定位和前台服务的持久性通知每小时耗费数小时的时间 ，再到堵塞安全漏洞以获取非GPS位置，限制背景位置的权限。 未来将带来一次访问权限以及从前台到后台的增量权限的精细的隐私控制。
Background location access, as specified by the Android platform, would work best for apps that use location for content personalization and local search. Live location apps using more frequent location with explicit user permission, e.g. commerce, logistics, workforce, gig economy, delivery, ridesharing, social sharing, etc. should use foreground service with properly set attributes as recommended by Android.
如Android平台所指定，后台位置访问最适合使用位置进行内容个性化和本地搜索的应用。 使用具有明确用户许可的更频繁位置的实时位置应用程序，例如商业，物流，劳动力，演出经济，交付，拼车，社交共享等，应使用具有Android建议的属性正确设置的前台服务。
Would love to hear from you about your live location use case, and exchange thoughts on the best way to manage access controls to protect user privacy and minimize battery drain.
希望听到您关于居住位置用例的消息，并就如何管理访问控制以保护用户隐私并最大程度地减少电池消耗的最佳方式交换意见。
翻译自: https://proandroiddev.com/evolution-of-location-access-on-android-897a0449e71f