. aab is really interesting for other reasons but that isn't the point of the current topic which is about huge compiled apk files and relative permissions. Nevertheless what follows is valid for both apk and aab files.
For me it is ok in both ways if permissions have to be granted on install time or at runtime since for me as "app dev" doesn't change a thing. So no problem in both cases.
In fact the problem is if the app asks for permissions that aren't really needed nor forecast on the basis of the used components and on the basis of the dev aim of the app itself. If I developed an app that doesn't access the web or doesn't use the wifi why the user that installs it (that could be me or anyone else) needs to grant that kind of permissions? It seems a little bit an overkill, and even a "suspect" behaviour for the app.
It isn't logical nor required for the app to work properly to ask for permissions that are not specifically needed (as the countdown/timer that ask for network an wifi permissions). As I said I built just a timer/countdown. So no network access is needed nor components for network access are inserted by myself in it. So why asking those permissions?
The second point is about the issue of huge .apk | .aab file. Substantially I think that the builder / compiler for apk/aab must be kinda of "intelligent": it has to distinct and insert into the .apk | .aab only the class files the app is going to use due to its components the developer has inserted into it. For example if the app is a counter or a timer it doesn't need the components to use the bluetooth or the network if the developer doesn't implement any functionality to use that kind of services an features. So the resulting .apk | .aab will be optimized in dimensions (and even in security) because it doesn't have into it all the .class java files and libraries, etc that aren't strictly needed.
Something like that could be implemented IMHO into the compiler making it "aware" of libraries dependencies that are needed from time to time.
Please allow me to make a clarificatory example: let's suppose that the whole AI library collection is composed by 1000 files (.class files, .xml files, and others). Each one has dependencies that refer to some other files. Suppose now the user has inserted a specific component that has 3 dependencies so just 3 more files are called and each of these files calls let's suppose 2 other files each as their respective dependencies. So at the end of the compiling process the compiler inserts into the compiled .apk | .aab just 6 files out of those 1000 plus the main program files created by the developer.
Question:
How the compiler can choose what .class or library etc has to insert into the final .apk | .aab ?
Clearly this is the main point of the topic.
Of course I'm not a guru in programming but IMHO I immagine we have the folloking possible answers:
- The compiler on its own scans the code that is compiling starting from the main files created by the developper it self and searches for class.functions, .xml calls, etc (dependencies) and inserts the destination files into the compiled .apk | .aab ;
- The class.functions (and of course all other files dependencies) are inserted into a some kind of "relational database" and when they are called in some file are inserted into the .apk | .aab so they are present when needed on runtime;
- The developer (me for example) decides what components and what dependencies are need into the .apk | .aab and only these are compiled into the final .apk | .aab. In this case the app developer has the duty to check all the files and dependencies are correctly refered and iserted (just adding the right component as it is now) and the compiler insert just what is needed on that basis. On debbugging the developer will check if everything is ok.
IMHO all solutions have advantages and disadvantages. So we can think about a further 4th method that uses a "wise combination" of all the previous methods to get the advantages of all of them and compensate disadvantages.
Respectfully.