ANDROID

This is a post-mortem where the very dangerous permission, READ_PHONE_STATE, unintentionally sneaked into our app. Here’s how this could happen, how we debugged and finally how we solved it.

Prologue

Sprint comes to lớn an end & we’re happy lớn deliver a new release of our app. After rolling it out khổng lồ our beta community without issues, we move ahead khổng lồ production.

While everything looks fine at first, after a while we see users complaining:

*

Honestly we were completely taken aback by this… But sure enough looking at the play store:

*

Root cause

If you ever run into a similar issue, the apk Studio merged manifest view is the way khổng lồ go. Just open your manifest và click the Merged manifest tab at the bottom.

*

Sure enough, the READ_PHONE_STATE permission is there.

Unfortunately, this view couldn’t help us find where the permission was merged from:

Double-clicking the permission led us back to normal manifest viewColor coding palette is so subtle that we couldn’t see what color the permission was highlighted in

*

Fortunately, the manifest merger also prints a log file to build/outputs/logs that describes where everything is merged from.

*

This tệp tin gave a clear answer:


uses-permission#android.permission.READ_PHONE_STATEIMPLIED from /app/src/debug/AndroidManifest.xml:8:1-15:12reason: hue.libraries.translations has a targetSdkVersion
Wow… That’s nasty!

A while ago we decided to lớn move all our translations to a new module, with an empty manifest and a bare-bones build.gradle file:


apply plugin: "com.android.library"android compileSdkVersion Config.compileSdk
And because we didn’t explicitly mix the targetSdk, a targetSdk of 1 is assumed & hence we kết thúc up with a dangerous permission!

To be fair, the documentation does warn you about this:

*

But still… wow!

Solution

While a solution could be to simply phối the targetSdk in our translations module. This wouldn’t prevent something similar from happening in the future.

Therefore we decided khổng lồ set the targetSdk (and others) for all our modules in the top level build.gradle file. This also keeps submodule build.gradle files lean.


subprojects afterEvaluate project -> if (project.plugins.findPlugin("android") ?: project.plugins.findPlugin("android-library")) app android buildToolsVersion Config.buildTools compileSdkVersion Config.compileSdk defaultConfig minSdkVersion Config.minSdk targetSdkVersion Config.compileSdk compileOptions sourceCompatibility Config.javaVersion targetCompatibility Config.javaVersion
Additionally, we also wanted to lớn protect ourselves against 3rd tiệc nhỏ library developers that could make this mistake. To vì chưng so, you can inform the manifest merger to lớn remove the permission while merging by adding the following lớn your manifest:


android:name="android.permission.READ_PHONE_STATE" tools:node="remove"/>
That is overkill you say?

Well, Firebase & Google play services already made this booboo in the past.

… wow!

Wrap-up

Not explicitly setting your target SDK version will cause a dangerous permission to lớn sneak into your app. Make sure you mix the target SDK in every module & protect yourself from 3rd buổi tiệc nhỏ libraries.

If you’ve made it this far you should probably follow me on Twitter. Feel không lấy phí leave a bình luận below!

Leave a Reply

Your email address will not be published. Required fields are marked *