I just tried and downloaded the same file 10 times with different file names. In your case, It only happens when your URL is not suitable or the file with the same name already exists. Id is just used to identify the download. If you want to use same ids for multiple download then you could it won’t affect your download. However, make sure you are providing a direct download URL and file with that name does not exist.
What result do you get on APK?
Nope. I think I mis-posted it. I just wanted to say that when a file download is cancelled then you could not resume it, you will have to redownload it (We all know this ).
Please post some screenshots or something that proves the downloaded file has removed before redownloading it. Maybe a block that show the file does not exist?
I tested the extension with all paths (Shared folders, ASD, PrivateDir) and with media & non-media files on Android 9, 11, 12. It works perfectly! The is no bug.
hit “download” - download starts and completes succesfuly
after file is downloaded, hit “check” - returns true
hit “delete”
hit “check” - returns false
verify file deletion in filemanager (file deleted)
2nd loop:
hit “download” - creates 0 byte target file and fires “downloadComplete” instantly
hit “delete”
hit “check” - returns false
verify file deletion in filemanager (file deleted)
3rd loop:
hit “download” - creates 0 byte target file and fires “downloadComplete” instantly
hit “delete”
hit “check” - returns false
verify file deletion in filemanager (file deleted)
.
.
.
until I reinstall the APK or Companion
It acts like DownloadCompleted “status” stay “hanged” somewhere…
Same behaviour in Companion and APK on Android 10.
No other way to reenable downloading then uninstall/reinstall of the Companion/APK.
Your APK works like a charm.
I tried to define target path using GetASDpath instead of File component - still no succes, same bug. On first loop after reinstall of Companion (or APK) download works, on second and more tries, it does not. Starting to be desperate… Any ideas? Anke, maybe you can try to build apk same way like I did and try download some .zip to see what happens?
Thanks. The situation becomes more weird. I tested what happens when I cancel download in the middle of the progress, lets say 50 %. Then I deleted target file and started download over - the download started succesfully, but the progress counter continued from 50 %. I tried this repeteadly, and the counter countinoued increasing until it reached 100 %. So it looks like the AIX somehow “remember” the progress even if the download is canceled (this operations should IMHO logically reset the progress counter to 0, compared to download paused which expects the user wants to continue downloading later on). I think this could be related to my issue. Sumit, can you pls double check on this? Is the source code of the AIX available to throw an eye on that?
Can you show me your blocks - please! I want to repeat you steps 1:1. Thank you!
EDIT: finally solved.
On appinit random int is generated with value in interval between 10e6 to 10e12 to use as a filename. This is a workaround to enable Fetch donwload same file over and over for me. Then the downloaded file is renamed to target filename to be processed in next steps.
But still, resolving the bug in some next version of AIX would be highly appreciated. I hate workaround.
Many thanks to Anke for her attention, at the end it helped me realize what to do.
EDIT2: well, this is f***n ridiculous… The workaround above does work within Companion but not builded to APK. One week of life spent on this sht… fck.
).
