Android Question How to exclude Internal Library?

[JohnC]

Back in this thread:

How to get FileProvider working without entire RuntimePermission lib or entire com.android.support:support-v4 ?

I need my app to be able to update itself, but also be as small as possible. I also don't want my app to require permission to the user's storage/files, so I am using FileProvider. The FileProvider class uses the function "GetSafeDirDefaultExternal" to get a directory that the shared file can...

www.b4x.com

There was an issue that when I used the FileProvider class, it would bring in some unneeded runtimepermission code that added like 700k to my APK.

Luckily, @Ivica Golubovic was able to write a new lib that didn't cause this extra unused code to be added to the APK.

But now, after upgrading from B4A 9.01 to B4A 13, that extra code is again being included in the APK.

If I had to take a guess, some code related to the File provider functionality is now "internal" with B4A v13, so it has priority over the external lib that @Ivica Golubovic wrote.

I tried to simply rename the FileProvider.b4xlib to FileProvider.org (in the \Libraries directory) so that it wouldn't "load", but NG - the extra code was still added.

So, how can I fix this so it will use @Ivica Golubovic's library only?

 

[drgottjr]

isn't his lib called tinyfileprovider? don't refer to fileprovider. didn't you use #additionaljar: tinyfileprovider before? and use his manifest statements.

 

[JohnC]

It's a Library that I need to include in the Library Manager.

And then I define it's class in the Starter Service:

Public tp As TinyFileProvider

And then I use it in various parts of my code, such as:

If File.Delete(Starter.tp.SharedFolder, "update.apk") = True Then

Dim out As OutputStream = File.OpenOutput(Starter.tp.SharedFolder, "update.apk", False)

i.Initialize("android.intent.action.INSTALL_PACKAGE", Starter.tp.GetFileUri("update.apk"))

But for some reason, when I compile the project using B4A 9.01, the resulting APK size is 450k.

And when I compile the same exact project with B4A 13, the resulting size is 1.2MB.

 

[drgottjr]

members have been reporting larger size apk's with 13 since day 1. several different threads. on last one i read, i believe erel said that's the way it is. not fileprovider this time.
here: https://www.b4x.com/android/forum/t...igger-apk-file-size-in-sdk-34.162202/#content

check erel's comment

 

[JohnC]

OK, I haven't followed up on this thread because my initial thought was that since I am still able to compile my app using B4A 9.01 to get the smaller APK size using @Ivica Golubovic's library, the issue of generating an APK of almost 3x the size when compiled using B4A 13 was not very important one for me at this time.

But I just realized that when I want to post the app in the playstore, I will need to generate an AAB file, which B4A 9 can't do.

So, this is actually an important issue because one of the major advantages my app has over the competition is it's small size because it will typically run on devices with low memory, and since the app needs to stay running in the background, the lower the size, the better the chances android won't try to kill it.

When FileProvider was external (as in B4A 9), @Ivica Golubovic's library was able to easily replace the file provider functionality, so the entire runtime permission lib did not have to be included, which kept the APK size down. But it seems that since it is now an internal function in B4A 13, it is dragging in extra unneeded code and bloating the APK/AAB.

So, how can I prevent some internal fileprovider related function/library from being used so that it will instead just use @Ivica Golubovic's library which provides all the file provider functions my app needs?

Are there some class(es) I can specify with the #ExcludeClasses feature to prevent the extra bloat from being included in the app?

 

[AnandGupta]

As I read about aab, Google now makes apk from aab as per device when installing. So it will be different in different devices.