Huge apk file and weird permissions during installation on the device

Hi, I’ve created a test app and after compiling the apk I have downloaded it and then I noticed that its dimensions were really big: 3.5 MB for just few things I’ve implemented. I was expecting just few KB for the apk; it was a bitter surprise to see all that space for just that.

Any way to optimize it?

Also before installing it asks for permissions (for accessing network, wi-fi, etc…), but I did not implement any functionality about that (the app is just a timer/countdown). Why it is happening?

An “empty” aia project will compile to just over 3mb.

You must be installing on a device before Android 6? Later android versions only ask for permissions when the user needs them, not on installation

See Power Users Study Permissions with MIT

Thank you for the fast answer.

What's that for?
That size is really not motivated.
If I do the same app for windows its weight is few KB.
IMHO this is an issue that needs to be solved: the apk file size must be optimized and the apk has to contain just what is needed to work not all the AI libraries.

Yes, Android v4

IMHO it doesn't matter "when" the device asks for permissions, it maters that it does ask for those permissions without I have implemented anything that use them so far. So they are not motivated to be asked, at all. Is there anything that is added during compiling without me to know it? (Considering 3.5 MB of file size this question is more than legitimate IMHO)
Usually in the past versions of AI when I added a functionality, a sensor component, etc. the apk during the "built" process was automatically configured with the needed permissions, no more no less. So for a timer I was expecting no permissions for network access, and similar tasks because there are no functionalities implemented for that.

Thank you for the link.

which components are you using?
any extensions?

Taifun


Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun.

  1. If you create an empty app with AI2 (without any property / action / function), it has a minimum size of 3.3 MB. See e.g. here: Is there anyway to reduce final apk build size please?

  2. The (non-dangerous) standard permissions are:

    <uses-permission android: name = "android.permission.INTERNET" />
    <uses-permission android: name = "android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android: name = "android.permission.ACCESS_WIFI_STATE" />

These are always granted automatically on all Android versions. But since Android 6 (API 23), dangerous permissions (e.g. READ_/ WRITE_EXTERNAL_STORAGE) are no longer granted at install-time but at runtime.

Internet access permission is not dangerous?
And wifi and network aren't dangerous as well?

I can immagine apps that spies and get data from the smartphone of the user sending data to a web server... I think that everything and every permission can be potentially exploited by a bad developer that has bad purposes, or even apps that spy wifi or network to send the state of it and credentials to someone that can use those data to hack the network or wifi... I think that everything has to be authorised if there is the need to no more no less.

Also having an empty app that has MB means that the compiler does some messy thing attaching not useful and not needed content that can be used from some one else if is known how to access the relative class or else. I think that everything that is not needed can be dangerous without having the need of it so risks aren't motivated.
IMHO the way to go is to compile apps inserting only what is really needed and not every AI class library even if not needed.

Also we know that AI has some limits for compiling big apps and that memory space is a waste without having nothing in exchange,

So IMHO this "philosophy" has to change ASAP.

Thanks for the comprehension.

you might want to suggest this to Google...
What is a dangerous permission?

Taifun


Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun.

. 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:

  1. 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 ;
  2. 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;
  3. 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.

So all the hassle might just help to reduce the app size by around 1MB.
In addition, inexperienced users will certainly have problems with it.

As for the (non-dangerous) permissions, just try to remove them from the Manifest. I do this regularly with some of my apps with two dangerous permissions (READ / WRITE) so that they don't have to be granted when installing on devices with API < 23.

@Anke
Reducing the app size is one point but not the only one in fact IMHO there is the security issue to be considered too: adding code to the app that isn't used may expose without any need the app it self to be exploited other programmers because it has in it a lot of .class or .jar files that the app it self doesn't use effectively but they are there and maybe they can be accessed by someone else's app exposing the device to unwanted risks.
In programming it is taught that the less is the code in a program the better because of maintenance of the code it self, because of debugging, because of memory, because of security: every file can have into it code that can be exploited for doing thing that are not properly legal. So having a clean apk reduces the memory usage of the device and reduces security risks as well.

Of course I'm a newbie in programming in general and under Android in particular so maybe I'm wrong. Sorry if it is that, but it worth it to clarify because this is an important point IMHO.