We’ve got 2021 and if you are an Android Developer you need to know a few things that are going to change really soon.
There are new guidelines for using background location in Android apps. If you want to use this permission in your app you’ll need to submit a special Permissions Declarations Form in Google Play Store.
App published before April 16, 2020 – Submit a compliant version of your app by March 29, 2021
Apps published after April 16, 2020 – Submit a compliant version of your app by January 18, 2021
I decided to write this blog post because the whole process of preparing your app for this is not obvious. It took some time for me to understand how Google wants you to prepare your app for this and what steps you need to take before sending the form in the Play Store.
Google Play Policy – Declared permissions and in-app disclosures
Start from reading official docs and just take a look at video posted at Android Developers channel.
Before sending the form
Check if you really need this permission. In my opinion in most cases you don’t need it. Setting GPS permission to “While app in use” should work for most apps.
Make sure you’ve added prominent disclosure and runtime permission (with user consent) Usage of the location should be clear for user but we’ll stop here because in most cases your app can be rejected because of missing proper disclosure
Prepare a video of yourself app showing the usage of that feature. Prominent disclosure should be also visible on your video.
Location permissions form
Here’s the form. Prepare a short description of your app and how you want to use background location access and why you need it.
If something is wrong you’ll get an answer from Google the same day (of course this can vary). We tried that in November 2020 (maybe in 2021 when you got the deadline the approval/rejection time can be longer).
Let’s talk about rejections. I sent this form a few times (I was sure I prepared my app properly but there was always something missing). It looks like we didn’t get the clear point how this should be done. I contacted many other developers also trying to fill that form and they’d also been rejected
In our case, using background location is needed for one feature. We don’t need a background location from all users, we also don’t want to ask for a background location if we don’t need to.
So we decided to do it like this:
Add special disclosure before turning on feature that needs to use background location
We added a new fullscreen fragment showing all the info – why we need that permission and how it is used.
We added suggested flow to ask for Background Location permission
We don’t ask for background location permission if we don’t have to.
For us it was something obvious and we were pretty sure this would work. We don’t ask for that permission if we don’t need to use it.
Our review team must be able to verify the feature’s functionality in your app. If your feature is not visible to the user then you must demonstrate its functionality in your submitted video. Your video should show the in-app feature’s functionality using location in the background and how a user would trigger the prominent disclosure, runtime permission (with user consent), and the declared feature. If your feature’s functionality is not directly visible to the user, then you will need to show us its functionality in a video showing the in-app experience (e.g. notifying the user of a fraud alert). Please modify your video to demonstrate the declared feature for which you are requesting access to location in the background, and resubmit your declaration form via the Play Console
It wasn’t clear for us what was wrong. We understood that the video wasn’t right and using the feature wasn’t obvious.
We recorded new, resubmitted the form again with a new video but the answer was the same. Status: REJECTED
After sending appeal to our case we got more detailed rejection status.
Prominent disclosure not foundYour app must display a prominent disclosure through a pop-up alert before your app’s location runtime permission. Based on our review, a prominent disclosure did not appear before the runtime permission. Please add a prominent disclosure before the runtime permission.Remember, your prominent disclosure must:Appear before your app’s location runtime permission.Include at least the following sentence, adapted to include all the relevant features requesting access to location in the background in the app that are readily visible to the user: “This app collects location data to enable [“feature”], [“feature”], & [“feature”] even when the app is closed or not in use.” If you extend permitted usage to ads, please also include: “This data is also used to provide ads/support advertising/support ads.”Include any other details necessary to make it clear to the user how and why you are using location in the background. While additional content is permitted, it should not cause the required content to not be immediately visible.
It was missing the point. But let’s stop here for a while. I talked with many devs trying to pass this location form and in most cases the proper way of showing prominent disclosure was the problem. This reply from Google is telling exactly what you need to do.
So let’s get back to our case. This approach in our case was WRONG:
Home screen. We didn’t ask for background permission if we didn’t have to.
There was one feature that could use standard location access (while the app is open). We didn’t ask for background permission so there was no disclosure about it.
When the user was trying to use a feature that is using background location access – we created a separate fragment showing disclosure, telling him why, we used proper scope for asking for this permission (recommended by Google for Android 11).
User approved this permission for this feature – the feature is ready to go.
As I know, many devs were trying to use it just just like that. You won’t be accepted if you have scope like this in your app.
You should do something like this
To pass Google Play Store review you need to have prominent disclosure before asking for ANY location access. That’s the change we made. We left the second consent screen before turning on features that need to use background location access (we want to be transparent for users).
In the disclosure we wrote how we use location in general and we mentioned features. We said that most features don’t need to use background location and you won’t be asking for it if we don’t need it but you should be aware that if you want to use (in our case) GPS recording feature – you need to allow background location permission. And later we’ve got recommended scope for asking for it.
Keep in mind your use case can vary. If you are using ads – you need also put this information in that disclosure (we don’t use ads or Advertisement ID).
Verify if you really need background permission access. You can still use foreground service for location (if you are not starting it from the broadcast receiver or any other background process). In that case foreground service is becoming background service and you need this permission.
Show proper dialog telling how you use location in your app. Do it always before asking for any location permission.
Record a short video (required by the form) showing your feature. Disclosure dialog should be also visible on the video.
We started working with the form in October 2020 so it was just after Google released it. Like I said before, because this is manual review, this process may vary for you. Your use case can be different but many developers were missing proper disclosure.
Android 11 is officially out! There are many changes related to privacy you should know about and it’s good to check your apps for potential flaws. It’s also good to know what are the current platform restrictions.
I’d like to focus on important change in Android 11 that can affect your app if you are using location and foreground service. What’s important, it doesn’t matter if you are targeting your app to API29 or to the latest API30. If you are using device with Android 11 it’s also good to know how to deal with location permissions and when your app can be blocked.
To support the additional control that users have over an app’s access to location information, Android 10 introduces the ACCESS_BACKGROUND_LOCATION permission.
Unlike the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions, the ACCESS_BACKGROUND_LOCATION permission only affects an app’s access to location when it runs in the background. An app is considered to be accessing location in the background unless one of the following conditions is satisfied:
An activity belonging to the app is visible.
The app is running a foreground service that has declared a foreground service type of location.To declare the foreground service type for a service in your app, set your app’s targetSdkVersion or compileSdkVersion to 29 or higher. Learn more about how foreground services can continue user-initiated actions that require access to location.
TL;DR: It’s clear. You can use location in the app only when you are showing the user your app, user can see what’s going on and is aware of that. That’s why foreground service type was introduced.
Use case: GPS Tracker
Let’s talk about real example here. I’m working on an app that is recording trips (routes) with GPS. Change that was made in Android 10 wasn’t problematic for us. We are always showing user some UI that the app is working – notification (so we run foreground service working with active notification)
No. We are showing notification to the user, user can see that the app is working, everything is fine. And we are asking only for location Allow only while using the app. We don’t need background permission. That’s great!
Auto trip recording
In our app we have some feature called “autostart“. User can start recording automatically. For example when entering their vehicle. Simple BROADCAST RECEIVER matched with Bluetooth.
You can set this up. When you are connected to some BT device, app is starting recording route. We are starting foreground service, showing info to user.
Android 10: No. Start foreground service, get location with foreground service.
Android 11: Yes. You can’t use location even with foreground service when it was started by BROADCAST_RECEIVER. Broadcast Receiver for Android 11 is background process.
When trying to start foreground service with Broadcast Receiver you’ll get this error:
Foreground service started from background can not have location
Solution: You need to get ACCESS_BACKGROUND_LOCATION for your app. Even when using foreground service. The same foreground service will work without having this permission if user stars it manually from your app (e.g. clicking record button in your app).
Changes in Android 11
At Android Developers Summit ’19Dianne Hackborn said that “Abusing foreground services is becoming big issue and we have to do step to address that…“
I believe that in most cases you don’t need ACCESS_BACKGROUND_LOCATION for your app. It’s always good to analyse your needs here. If you need it for your use case – be aware of other changes here. You can’t ask for this permission directly. And this is another big change in Android 11.
If you are setting up any website today SSL certificate (https://) is a must have. July 2018 will be a game changer and you should be prepared for this date.
While I work in mobile right today I’m getting questions about this because I spent many years working with web and still I’m trying to be up-to-date with new web technologies and trends. This kind of knowledge is also very useful in mobile because web and mobile are connected and this connection in my opinion is getting closer and closer (see PWA, Instant Apps, Flutter…).
(Let’s get to the point) Let’s say you’ve got website without SSL (HTTP) and you are afraid you’ll get some penalty for not having SSL. Is this true? What will happen in July 2018?
For the past several years, we’ve moved toward a more secure web by strongly advocating that sites adopt HTTPS encryption. And within the last year, we’ve also helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as “not secure”. Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.
What is also important, this will be additional factor for Google Search results (SEO). If you want to keep top positions in Google’s search results – keep it in mind.
How to add SSL (HTTPS) to my site?
Let’s just simplify this:
You can probably buy SSL certificate at your hosting provider (as your hosting provider)
You can get free certificate from https://letsencrypt.org/ and install it on your server (ask your hosting provider how to do it and what is important – ask if this is possible. I know that not all hosting providers are allowing to do that – because for example they want to sell you one…)
Use Crowdflare service for free and move your website to HTTPS in a minute
I’d like to focus on Cloudflare
Cloudflare provides content delivery network services, DDoS mitigation, Internet security and distributed domain name server services, sitting between the visitor and the Cloudflare user’s hosting provider, acting as a reverse proxy for websites.
It may sound like a sponsored article but it’s not. Cloudflare is really great service that can help you in many ways:
Stop attacks directed at a website
Dynamically modify content in order to improve performance
Insert applications into web pages
Provide rich analytics on all the requests to your website
Automatically determine what objects are static and cacheable at the network’s edge without any user configuration
Provide a network gateway between protocols like IPv6 \<-> IPv4
Make installing SSL flexible and one-click easy
And many more things a traditional CDN can’t provide….
How to set up your domain with Cloudflare?
Read this FAQ tutorial to know how to move your domain to Cloudflare. This is starting point for the service. Once you have it – you can try to use and test it’s features. Just start with Free service
Once you have. Your domain is active at Cloudflare. How to turn on SSL?
Just go to Crypto tab and enable SSL (Flexible can be good start point, for blog, landing page – you can start using it without a problems)
Is that all?
Just check your website and other option in Crypto
If you have mixed content you want to enable also Automatic HTTPS Rewrites and if you want to make HTTPS your default URL Always use HTTPS
That’s it. Check your website, you should see SSL confirmation
So it’s just a friendly reminder for July 2018 and make your users more secure.
As you can see I started my own blog and you are probably thinking why?
What’s the purpose?
I was thinking about starting my own blog years ago. As you can see that didn’t happen and my own domain was inactive for many years. I was posting different kind of things in various social media channels and for years it gave me some kind of illusion that actually it’s the best way to share your thoughts, knowledge and it’s working. I’ve got Facebook or Twitter, I’m sharing my moments there so what’s the purpose? I used the phase “moments” deliberately because it is how it works right now. It’s hard to say what’s the average lifetime for posts on Facebook or Twitter but I after day or two, almost no way will see your content and it’s getting worst because for example Facebook is not showing your content to all of your friends etc. Second point is that it’s really hard to get back to some of your thoughts written there.
I’m not doing this for clicks, views, mostly for myself but you know how it is, if anyone can find it useful I will be really happy!
I’d like to focus on few things right now:
mobile (of course Android)
and we’ll see what else 🙂
So as you can see a little bit of mixed stuff. A little bit of developer’s blog, startup blog, reviews. Who knows. Firsts of all let’s see how it works. Let’s give it a try!
OK, but why in English?
It took me some time to make this decision. For many years right now my primary language is English. For developers or in startups’ world it is also primary language, so why not? And there’s always a space to polish language skills.