bug: Android 13 patch failed

[Bryancyriel7]

Bug description

In the pre-release update, I'm stuck on patching the file with the correct APK version, and what happened to the Morphe app variant?

Version of Morphe (Manager) and the app you are patching

Base: 1.13.0-dev.3
YT patched version: 20.45.36

Morphe logs

java.nio.file.NoSuchFileException: /data/user/0/app.morphe.manager/cache/temp_apk_1774595650850.apk
	at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:548)
	at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:259)
	at java.nio.file.Files.copy(Files.java:1295)
	at app.morphe.manager.patcher.Session$run$4.invokeSuspend(SourceFile:114)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:33)
	at kotlinx.coroutines.DispatchedTask.run(SourceFile:100)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(SourceFile:124)
	at kotlinx.coroutines.scheduling.TaskImpl.run(SourceFile:89)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(SourceFile:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(SourceFile:820)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(SourceFile:717)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:704)

Acknowledgements

• I have checked all open and closed bug reports and this is not a duplicate.
• I have chosen an appropriate title.
• All requested information has been provided properly.
• The bug only affects using Morphe (Manager)

[optimatrix0]

Analysis of the issue

The error reported is a "java.nio.file.NoSuchFileException", which indicates that the system attempted to access or copy a file that does not exist at the specified path:

"/data/user/0/app.morphe.manager/cache/temp_apk_1774595650850.apk"

From the stack trace, the failure occurs during a call to "Files.copy", meaning the patching process expected a temporary APK file to be present, but it was not found at the time of execution.

Likely causes

Based on the context, a few possibilities stand out:

• The temporary APK was never successfully created due to a failure in an earlier step (e.g., download, patching, or build process).
• The file may have been deleted prematurely (for example, by a cleanup routine or cache invalidation).
• There may be a race condition in the coroutine flow, where the copy operation is triggered before the file creation step has completed.
• The generated file name (timestamp-based) may not match the actual output, leading to a mismatch in expected vs. actual file paths.

Suggested improvements

To make the process more robust and easier to debug, the following could help:

• Add an explicit existence check before attempting to copy the file, with a clear error message if it is missing.
• Ensure proper synchronization between coroutine steps so that file creation is guaranteed to complete before any copy operation begins.
• Improve logging around file generation and deletion, especially for temporary APKs.
• Review cache cleanup timing to ensure temporary files are not removed before they are used.

Summary

This does not appear to be an issue with "Files.copy" itself, but rather with the lifecycle of the temporary APK file. The root cause is likely in an earlier stage of the patching pipeline or in asynchronous execution timing.

Hope this helps narrow it down 👍

[optimatrix0]

Additional insight on device performance

One important detail that might help narrow this down is the impact of device performance and timing differences.

This issue could behave differently depending on how fast the device executes the patching steps:

• On faster devices, the temporary APK file may already be created by the time the copy operation runs, so everything works as expected.
• On slower devices (or under heavier system load), the coroutine responsible for creating the file may not have finished yet when "Files.copy" is called, resulting in a "NoSuchFileException".

Implication

This reinforces the possibility of a race condition in the patching flow, where file creation and file access are not properly synchronized.

Since this kind of timing variation can happen across different devices and Android versions, it would explain why the issue is reproducible but not necessarily consistent in all environments.