There's a few reasons I disagree with removing the extensions functionality from the Play Store version.
Some devices do not allow sideloading (e.g., Chromebooks), at least not without a ton of headaches. This would immediately restrict people with these devices from using many of our AI related tutorials as those features are all currently published as extensions.
The read-only requirement is not a requirement of Google Play Store, it's a requirement of Android 14 itself and enforced by the operating system. The sideloaded version with extension functionality would still be subject to the rules.
Once someone has sideloaded the companion, they will need to manually update it from there on out if they want newer features of App Inventor since it will no longer be automatically updated via Google Play. This will cause increased feature drift and make it harder on everyone providing support.
And here we can return to @Anke's question, why Nitron doesn't have to do anything with companion, and extensions work fine there on every version of Android. Is this a requirement of Android14, or maybe Samsung's invention? I didn't find any mention of it in the list of new features in Android 14. Using Android 14 before all these fixes, I also had no problems with extensions... probably Samsung users had them.
I will point out that it did work on most devices. However, some Samsung devices did not work. It's entirely possible that the original patch worked on all of your devices (and therefore if Niotron is just lifting our changes for them too). Frankly, I don't have the time to reverse engineer their proprietary changes to our open source platform. Maybe one of them would be interested in contributing a patch. That said, I have another change in the works that should resolve the issue.
If the android14 fix works fine, maybe apply this fix to any version? Will the way to load jar files used in android14 work on older versions of android?
As I have said several times, it is not only Samsung devices that are affected. As soon as more than one extension is used, it fails on all my test devices with Android < 14.
I'm talking about the original issue that affected 2.73. Unfortunately, the fix we created for the bug in 2.73, now deployed as 2.73a, affects Android < 14. I have two devices on hand (Android 9 and Android 14) to try and test this. Unfortunately, neither is a Samsung device so we'll need people with Samsung to help test the fix once it's ready.
If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:
File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
// Set the file to read-only first to prevent race conditions
jar.setReadOnly();
// Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);
Handle dynamically-loaded files that already exist
To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.
