Closed buttercookie42 closed 7 months ago
thanks...
I blindly implemented first parts of it:
remaining questions:
My phone doesn't yet have Android 14, so I'm basing this only on looking at the source code, but
check if pm has the option in the help output
… based on that, the flag hasn't been included in the help output, so the only possible criterion is whether the app is running on ≥ Android 14 (API 34) or not.
how is this used in the session installer? which of the commands should get that option?
I guess install-create
, given that the flag gets added to the session parameters just as usual.
hopefully it does not hurt to use it on an apk that isn't old?
Again, based on reading the source it shouldn't affect anything else. This gets turned into this which then only turns off the target API check.
thanks for investigating... I also checked the usage text on A14 (emulator) and it doesn't include the option.
Did I say, that I hate that hiding game (in this case Google)...? What's the purpose to hide something (that a user will never see), when developers can look at the sources?
I now use pm install --bypass-low-target-sdk-block
and check if the error message complains about (=contains) the option.
It works because the options are checked before the remaining parameters.
That's not directly what I really want (checking if it's available), but I think it's more future-proof than using the api version. The fact that it is introduced at that version doesn't mean it will always be there after it.
On the other side, the error behavior might also change and option processing might also be rearranged (at least that's the usual way to do, somehow dictated by the option logic).
A more defensive variant would be to only add the option in case of a corresponding error. However detection of that error should even be less reliable and the repetition would need to move the handling to a higher level. I don't like to scatter something like this in several places far apart.
I wanted to write this as a feature wish today because I ran into this problem yesterday. Fortunately I had a look onto the issue list before and saw this topic. Thank you that you took care of the problem, I hope thre will be a new release soon. I had to help me using adb install with the above mentioned parameter and restore the data in a second step for the older apps. Fortunately there were only 16, but the complete solution with Neo Backup would have been much easier... Thanks for your continuous work!! I could make tests with session installer using a beta release.
well, you could have asked. I would have created a so called "pumpkin" test apk for you (at least, if I have some spare time, are you on the telegram group? I usually post it there).
I added it to the repo. However, it's just written down and needs testing to be added to the main branch.
i came here because of the infamous INSTALL_FAILED_DEPRECTED_SDK_VERSION
error/bug. ...because i always try to use the same NeoBackup version with which the backup was created.
just want to report, after updating to the latest 8.3.6 release it works like a charm on Android 14. :+1:
BTW: how about a feauture to schedule not just backups, but also the tasks from the helper/tools section, like deleting old backups resp. backups of not installed apps, saving a list of all apps, exporting all scheduled tasks itself and copying the apk - and overwriting if the same APK already exists (i know, the APK is also in its own backup folder)? -> sorry for getting a little bit off-topic, but that came into my mind while dealing with this issue.
thanks for confirming
you should not mix "issues", this one will be closed and the feature request would not be seen... also discussion about it doesn't belong here. Feel free to add it as a new issue.
fixed
On Android 14 it is necessary to pass the
--bypass-low-target-sdk-block
flag topm install
when attempting to install apps that are considered too old by Android (anything targetting lower than Android M).