[android] Why is RECEIVE_BOOT_COMPLETED permission needed? #6169

New issue

Open

opened 2023-10-01 08:49:56 +00:00 by rtsisyk · 0 comments

rtsisyk commented

2023-10-01 08:49:56 +00:00

Owner

While working on #6119 I realized that Organic Maps requires android.permission.RECEIVE_BOOT_COMPLETED permission:

Allows an application to receive the Intent.ACTION_BOOT_COMPLETED that is broadcast after the system finishes booting. If you don't request this permission, you will not receive the broadcast at that time. Though holding this permission does not have any security implications, it can have a negative impact on the user experience by increasing the amount of time it takes the system to start and allowing applications to have themselves running without the user being aware of them. As such, you must explicitly declare your use of this facility to make that visible to the user.

This permission was added implicitly by 'androidx.work:work-runtime' by Google.

WorkManager is the recommended solution for persistent work. Work is persistent when it remains scheduled through app restarts and system reboots. Because most background processing is best accomplished through persistent work, WorkManager is the primary recommended API for background processing.

Organic Maps uses WorkManager only to upload changes to OSM. The idea behind this was that WorkManager would take care of the task of uploading OSM changes, relieving the app from handling it. To re-schedule tasks after the system reboots, WorkManager requests RECEIVE_BOOT_COMPLETED permission.

Investigation in #6119 uncovered that uploading after the system reboot doesn't work anyway because it requires initialization of the entire application, including scanning maps on the SDcard:

W OsmUploadWork: OsmUploadWork.java:53 doWork(): Application is not initialized, ignoring androidx.work.WorkerParameters@466d33
I WM-WorkerWrapper: Worker result FAILURE for Work [ id=3985f8de-8a75-40be-a3e0-8ed67b96ae7c, tags={ app.organicmaps.background.OsmUploadWork } ]

I had a concern that the 'androidx.work:work-runtime' library from Android JetPack (by Google) adds 383KB of compiled Java code, 4 Services, 7 BroadcastReceivers and even an ORM library just to handle a simple queue in sqlite. This is why I implemented #6119. I checked git log and confirmed that the uploading of OSM on the system boot has NEVER worked correctly in Organic Maps before. However, my pull request has been HALTED during the code review by a **REQUIREMENT **to fix (actually, implement) such new behavior.

Before rushing to implement the new feature to do OSM upload on system boot, let's talk if we really want to do that?

Quoting our website:

Organic Maps

Respects your privacy

Saves your battery

No unexpected mobile data charges

Why would the app that aims to respect the privacy, save the battery and guarantee no unexpected mobile data charges, want to start implicitly on the system book to upload changes to the Internet? I see a contradiction between declared values and proposed feature.

Does the app really need to start on the system boot to trigger uploading OSM changes? Isn't it enough to trigger OSM uploading when the user starts the app explicitly?

While working on #6119 I realized that Organic Maps requires [`android.permission.RECEIVE_BOOT_COMPLETED`](https://developer.android.com/reference/android/Manifest.permission#RECEIVE_BOOT_COMPLETED) permission: > Allows an application to receive the [Intent.ACTION_BOOT_COMPLETED](https://developer.android.com/reference/android/content/Intent#ACTION_BOOT_COMPLETED) that is broadcast after the system finishes booting. If you don't request this permission, you will not receive the broadcast at that time. Though holding this permission does not have any security implications, it can have a negative impact on the user experience by increasing the amount of time it takes the system to start and allowing applications to have themselves running without the user being aware of them. As such, you must explicitly declare your use of this facility to make that visible to the user. This permission was added implicitly by 'androidx.work:work-runtime' by Google. > [WorkManager](https://developer.android.com/reference/androidx/work/WorkManager) is the recommended solution for persistent work. Work is persistent when it remains scheduled through app restarts and system reboots. Because most background processing is best accomplished through persistent work, WorkManager is the primary recommended API for background processing. Organic Maps uses WorkManager only to upload changes to OSM. The idea behind this was that WorkManager would take care of the task of uploading OSM changes, relieving the app from handling it. To re-schedule tasks after the system reboots, WorkManager requests RECEIVE_BOOT_COMPLETED permission. Investigation in #6119 uncovered that uploading after the system reboot doesn't work anyway because it requires initialization of the entire application, including scanning maps on the SDcard: ``` W OsmUploadWork: OsmUploadWork.java:53 doWork(): Application is not initialized, ignoring androidx.work.WorkerParameters@466d33 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=3985f8de-8a75-40be-a3e0-8ed67b96ae7c, tags={ app.organicmaps.background.OsmUploadWork } ] ``` I had a concern that the 'androidx.work:work-runtime' library from Android JetPack (by Google) adds 383KB of compiled Java code, 4 Services, 7 BroadcastReceivers and even an ORM library just to handle a simple queue in sqlite. This is why I implemented #6119. I checked `git log` and confirmed that the uploading of OSM on the system boot has NEVER worked correctly in Organic Maps before. However, my pull request has been **HALTED** during the code review by a **REQUIREMENT **to fix (actually, implement) such new behavior. Before rushing to implement the new feature to do OSM upload on system boot, let's talk if we really want to do that? Quoting our website: > Organic Maps > - Respects your privacy > - Saves your battery > - No unexpected mobile data charges **Why would the app that aims to respect the privacy, save the battery and guarantee no unexpected mobile data charges, want to start implicitly on the system book to upload changes to the Internet?** I see a contradiction between declared values and proposed feature. Does the app really need to start on the system boot to trigger uploading OSM changes? Isn't it enough to trigger OSM uploading when the user starts the app explicitly?

This repo is archived. You cannot comment on issues.