fix: install button not appearing on android 8 by germanamv · Pull Request #3333 · ReVanced/revanced-manager

germanamv · 2026-05-04T15:16:13Z

NotificationChannel is created before calling setForeground. If it isn't created, the notification won't show, and the "Foreground" status will be rejected.
WorkManager automatically holds a WakeLock while doWork() is running. Manually acquiring one is usually unnecessary and can sometimes conflict with EMUI aggressive power management.

oSumAtrIX · 2026-05-04T15:19:19Z

+            createNotificationChannel() // Safe to call multiple times
            setForeground(getForegroundInfo())
        } catch (e: Exception) {
-            Log.d(tag, "Failed to set foreground info:", e)
+            Log.e(tag, "Failed to set foreground info:", e)
+            // On Android 8, if this fails, the job is likely doomed
+            return Result.failure()
        }

-        val wakeLock: PowerManager.WakeLock =
-            (applicationContext.getSystemService(Context.POWER_SERVICE) as PowerManager)
-                .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "$tag::Patcher")
-                .apply {
-                    acquire(10 * 60 * 1000L)
-                    Log.d(tag, "Acquired wakelock.")
-                }
-
        val args = workerRepository.claimInput(this)

        return try {
-            runPatcher(args)
-        } finally {
-            wakeLock.release()
+            runPatcher(args) // WorkManager holds its own WakeLock internally


Suggested change

createNotificationChannel() // Safe to call multiple times

setForeground(getForegroundInfo())

} catch (e: Exception) {

Log.d(tag, "Failed to set foreground info:", e)

Log.e(tag, "Failed to set foreground info:", e)

// On Android 8, if this fails, the job is likely doomed

return Result.failure()

}

val wakeLock: PowerManager.WakeLock =

(applicationContext.getSystemService(Context.POWER_SERVICE) as PowerManager)

.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "$tag::Patcher")

.apply {

acquire(10 * 60 * 1000L)

Log.d(tag, "Acquired wakelock.")

}

val args = workerRepository.claimInput(this)

return try {

runPatcher(args)

} finally {

wakeLock.release()

runPatcher(args) // WorkManager holds its own WakeLock internally

createNotificationChannel() // Safe to call multiple times.

setForeground(getForegroundInfo())

} catch (e: Exception) {

Log.e(tag, "Failed to set foreground info:", e)

// On Android 8, if this fails, the job is likely doomed.

return Result.failure()

}

val args = workerRepository.claimInput(this)

return try {

runPatcher(args) // WorkManager holds its own WakeLock internally.

What is the change here? The code looks exactly the same.

Yeah the suggestion does look kinda weird.

Axelen123

Seems fine to me but I am not sure about the other suggestion.
Also, the PR title does not match the implemented code.

kitadai31

Overall, I have serious doubts as to whether this pull request will actually fix the issue.

kitadai31 · 2026-05-10T09:35:47Z


        try {
-            // This does not always show up for some reason.
+            createNotificationChannel() // Safe to call multiple times


Creating the notification channel here should be unnecessary, as it has already been done within the createNotification() method above that is called from getForegroundInfo().

Also, if you have really confirmed that creating a notification channel twice here fixes the problem, use the same method within createNotification().
The ID of the notification channel created by the new method is different from the one that is actually being used.
This change will make a duplicate notification channel.

kitadai31 · 2026-05-10T09:43:22Z

-            runPatcher(args)
-        } finally {
-            wakeLock.release()
+            runPatcher(args) // WorkManager holds its own WakeLock internally


iirc, WorkManager doesn't holds WakeLock
Try turning off the screen while patching without WakeLock
It should stop patching while the screen is off

I assumed the statement in the comment was true. Is it documented anywhere?

See conversation in #2147
It is not documented, but some reports can be found on StackOverflow

TUSHAR91316

A few observations regarding this PR:

Notification Channel ID: The new createNotificationChannel() creates a channel with the ID "patcher_channel", which doesn't match the channel ID used in createNotification(). This will end up creating a duplicate unused channel.
Aborting on Notification Failure: Returning Result.failure() inside the catch block for setForeground() will cause the entire patch job to fail if the foreground notification fails. It might be better to let the patch process continue even if the notification fails to display.
WakeLock: CoroutineWorker in WorkManager doesn't hold a CPU wakelock automatically across the entire job duration. Removing the manual WakeLock could cause patching to freeze when the device screen turns off, especially on OEMs with aggressive battery management.

TUSHAR91316 · 2026-08-23T15:40:19Z


        try {
-            // This does not always show up for some reason.
+            createNotificationChannel() // Safe to call multiple times


The channel ID "patcher_channel" used here is hardcoded and differs from the channel ID used in createNotification(). If a channel is needed before setForeground, we should reuse the existing channel ID / method to avoid creating a duplicate notification channel.

TUSHAR91316 · 2026-08-23T15:41:16Z

+            runPatcher(args) // WorkManager holds its own WakeLock internally
+        } catch (e: Exception) {
+            Log.e(tag, "Patcher encountered an error", e)
+            Result.failure()


Returning Result.failure() here will abort the entire patching operation if setForeground() throws. We should log the exception and allow patching to proceed instead of failing the job.

TUSHAR91316 · 2026-08-23T15:41:43Z

-                    // in the finally-block, and therefore, it will be released regardless (of failure/success eventually).
-                    acquire()
-                    Log.d(tag, "Acquired wakelock.")
-                }


Removing the WakeLock might cause the patching process to stop prematurely when the screen turns off (see PR #2147). WorkManager does not guarantee a CPU wakelock for CoroutineWorker.

fix for install not appearing on android 8

09d1d20

oSumAtrIX reviewed May 4, 2026

View reviewed changes

oSumAtrIX requested review from Axelen123 and CnC-Robert May 4, 2026 15:19

Axelen123 approved these changes May 9, 2026

View reviewed changes

kitadai31 reviewed May 10, 2026

View reviewed changes

TUSHAR91316 reviewed Aug 23, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

germanamv commented May 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Axelen123 left a comment

Choose a reason for hiding this comment

Uh oh!

kitadai31 left a comment

Choose a reason for hiding this comment

Uh oh!

kitadai31 May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TUSHAR91316 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

kitadai31 May 10, 2026 •

edited

Loading