Question on permissions

[IzzySoft]

My scanner got some extra checks in Januar, and on today's update of your app reported:

! repo/in.basulabs.shakealarmclock_35.apk declares sensitive permission(s):
  android.permission.READ_MEDIA_AUDIO android.permission.READ_EXTERNAL_STORAGE
! repo/in.basulabs.shakealarmclock_35.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Could you please clarify what those permissions are needed for? Thanks in advance!

Ah, btw: the DEPENDENCY_INFO_BLOCK is easy to avoid:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains.

[WrichikBasu]

Izzy from Android SE?! I am glad to see you here in my app's repo! You had helped me a lot in my initial days when I was fiddling with Android and asking questions on Android Enthusiasts SE. Thank you for all the help.

Could you please clarify what those permissions are needed for? Thanks in advance!

The app requests these permissions only when you are trying to choose a custom alarm tone. From my testing, I have observed that if the user selects a custom alarm tone, then the app often throws an error when the alarm rings because it could not access the custom tone. If the user-selected tone is from the default set of alarm tones available on the device, then in some devices, the app does work without that permission.

However, consider the situation where the user had, in the past, selected a tone from their external storage. E.g. they had selected a song from their device storage via the stock ringtone picker when setting an alarm using another app. These custom tones are saved by the device, and they come up when any ringtone picker (stock or 3rd party) tries to retrieve the list of available alarm tone Uris. This either throws an error in my app's ringtone picker itself when it is trying to access the list of tones and their file names. Or, if the user uses the stock ringtone picker, then the app throws an error when the alarm rings.

Android 13 introduced the granular READ_MEDIA_AUDIO permission, so the app requests that on API 33 and above. Below that, the app has to request the READ_EXTERNAL_STORAGE permission (as proposed in this answer on SO). The reason is explained within the app itself when the user attempts to select a custom alarm tone. And the Service that handles the ringing alarm has the ability to fall back to the device's default alarm tone if it is unable to access the custom tone due to revoked permissions.

Ah, btw: the DEPENDENCY_INFO_BLOCK is easy to avoid:
For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains.

Thanks for this info, I was unaware of this. I could definitely add that to the gradle files before releasing the next version. But is it bad to have the list of dependencies to show up? I mean, the app is anyway open-source and anyone can view the dependencies on GitHub. For a closed-source app, this absolutely makes sense.

[IzzySoft]

Izzy from Android SE?

The very one, indeed 😄 Just now reaching out as IzzyOnDroid, the maintainer of the repo your app is listed in.

Thank you for all the help.

Gladly given – and glad I was able to!

The app requests these permissions

Thanks! I already guessed as much – but didn't think these permission would be needed for the alarm tones offered by the device. And I didn't see a hint that one could choose a custom one e.g. from the music collection, though I suspected as much. Added that to the allow-list now.

But is it bad to have the list of dependencies to show up?

How shall they show up from that? Please read my quote again, here's the relevant part:

But as it's encrypted with a public key belonging to Google, only Google can read it

You can't. I can't. That's only for PlayStore. And you cannot be sure what else might be in there, as it's an opaque block. We've run a POC: one can hide literally anything in such signing blocks, most scanners are totally unaware of that (only 2 out of VirusTotal's 64 scanners detected an EICAR sample we hid there, none detected an ELF binary. And the signature was not even broken – though we used an APK signed by someone else, and we did not have access to the signing keys). So this might pose a security risk. So better not have it there – what is not there can't cause any harm.

I mean, the app is anyway open-source and anyone can view the dependencies on GitHub

Not only there, and no need for that blob either. Follow above link to your app and scroll down to the package section to see what my scanners evaluate from the APK. Send your next version without that blob and look again, my scanners can still tell:

No need for secrecy with FOSS, that's right – so no need for encrypted blobs with a dependency tree, right? 😉

[WrichikBasu]

The very one, indeed 😄 Just now reaching out as IzzyOnDroid, the maintainer of the repo your app is listed in.

That's wonderful. Even though I knew about your repo, I was unaware that my app was listed there. Glad that it could meet the standards and found a place in your repo.

I already guessed as much – but didn't think these permission would be needed for the alarm tones offered by the device. And I didn't see a hint that one could choose a custom one e.g. from the music collection, though I suspected as much. Added that to the allow-list now.

When trying to add/edit an alarm, the alarm tone for the current alarm is displayed under a heading "Alarm tone". Clicking anywhere on that View will allow the user to select a new alarm tone. In the ringtone picker that my app provides, at the very end of the list, there is an option "Choose from storage" through which one can select a file from the external storage. In the Settings activity too, one can set a custom alarm tone that will be used by default in all new alarms.

No need for secrecy with FOSS, that's right – so no need for encrypted blobs with a dependency tree, right?

Makes sense, I will add it to the gradle files and remove them from the next release. Thanks for pointing it out!

[IzzySoft]

That's wonderful. Even though I knew about your repo, I was unaware that my app was listed there. Glad that it could meet the standards and found a place in your repo.

🤗

Choose from storage

There! That was what I was guessing but didn't know. Thanks, clear now! If you want the other permissions being accompanied by explanations, too, just list them and I'll transfer them over.

I will add it to the gradle files and remove them from the next release.

🤩 Thanks!

[WrichikBasu]

If you want the other permissions being accompanied by explanations, too, just list them and I'll transfer them over.

The privacy policy explains in detail when and why each permission listed in the app manifest is required by the app. If you wish, you may copy the explanations from there. I have updated it to match the manifest in the latest version of the app. 😊

[IzzySoft]

Thanks, doing that now! Great you wrote that all up. Small typo: com.android.permission.SET_ALARM => com.android.alarm.permission.SET_ALARM 😉 Oh, and ACCESS_NETWORK_STATE is missing 😉

[WrichikBasu]

Thanks, doing that now! Great you wrote that all up.

And thank you for painstakingly copying all that to your repo! 😊

Small typo: com.android.permission.SET_ALARM => com.android.alarm.permission.SET_ALARM

Fixed that, thanks for pointing it out. 🙏

Oh, and ACCESS_NETWORK_STATE is missing 😉

The app doesn't require that permission. In fact, I haven't even declared it in the Manifest. 😳 Had to dig deep to find what library wants that permission. Taking help from this answer on SO, I found from the manifest merger report that it is requested by androidx.work:

uses-permission#android.permission.ACCESS_NETWORK_STATE
ADDED from [androidx.work:work-runtime:2.8.1]

However, the Work that my app creates does not have any constraint on network type; it has a constraint on battery level only. I'll see if I can remove that permission somehow; otherwise I'll add an explanation.

[IzzySoft]

And thank you for painstakingly copying all that to your repo!

Gladly! I aim for maximum transparency there. Nobody is forced to look for everything – but those who want should be able to.

Fixed that, thanks for pointing it out.

Great, thanks – and again, gladly done 👼

I'll see if I can remove that permission somehow; otherwise I'll add an explanation.

It's not critical, but if you want to give it a try (check that nothing breaks when removing it), here's how: Removing Unwanted Manifest Permissions With tools:node

[WrichikBasu]

Thanks a lot for all the help. 😊 The opportunity to collaborate like this is what makes coding open-source software so much more interesting!

Published a new release with all the changes incorporated.

[IzzySoft]

The opportunity to collaborate like this is what makes coding open-source software so much more interesting!

🤩 Yes, indeed! And so much positive feedback like yours here is what keeps me motivated to go on and improve wherever and whatever I can 😃

Published a new release with all the changes incorporated.

And full success it seems: it arrived, but my scanner report didn't mention it 🥳 Thanks!