I noticed that the application size of my app, as reported by android, was doubled respect to the same application two months ago, despite I did only minor modifications.
Even building the .apk from the same source code I used two months ago, I obtain a bigger .apk.
I did some investigations and noticed that the classes.dex was way bigger. It seems that something changed in the build environment. Is it possible that the last android SDK causes bigger .dex classes? is it due to something else?
I'm using android SKD inside Eclipse Indigigo:
Android SDK Tools rev. 21
Android SKD Platform-tools rev. 16
Check your resources, Check whether you included or excluded some libraries from the project, Check your .jar files in the project.Clean and build your project.
Related
How can I change the minimum SDK in an Android (Studio) project with recent (2020+) versions of Android Studio and Gradle?
During the creation of a new Android Studio project the wizard ask for the minimum SDK required.
Since the wizard generates a lot of boilerplate files and code, I assume that the boilerplate code is tailored to the minimum SDK chosen. My first objective is to generate a modern, lean, forward-compatible (Kotlin) app, so I chose API 31 (most recent non-beta on 29 Dec 2021). However, once the app (which is simple) is working, I would like to lower the minimum SDK to include as many devices as possible (without adding legacy dependencies, code, etc.). Is this a correct way to think about the relation between the choice of minimum SDK and the boilerplate code?
There are existing questions on older (2013) versions of Android Studio (and Gradle), e.g. here, but these do not work in modern versions of Android Studio and Gradle (I have only one build.gradle file and it does not mention any SDK, adding this gives errors).
EDIT: see below an image of the folder tree, as suggested.
I believe all you need to do is set minSdkVersion like provided by this answer. The problems you may encounter are going to be massively different based on what you're going to be doing, but mostly it should be OK. Of course, more you lower minSdkVersion, the more problems you will encounter, but it should be mostly ok to at least version 23.
However, minSdkVersion is usually chosen at the beginning. You should probably set it to 21 (which covers 98% of devices) and start from there (industry standard is currently at 23, which covers 94.1% of devices).
You should not be afraid of the app not being forward compatible because changes are usually quite small and there are ways to support different versions with ease and minSdkVersion doesn't even affect forward compatibility. Also, supporting multiple versions does not make the final size of the app any larger. Code that is not called for a specific version gets deleted at build time, so you don't have to fear having the app not lean because of lower SDK support. There is some build time performance penalty, but for a simple app, this is not noticeable. And in case there's a blocker with SDK version being too low, it's easier to raise it than lower it.
Bottom line here I'd say is, that it is easy to set a low minSdkVersion from the beginning. The amount of possible issues you'll encounter when lowering that version are probably not worth it and are also harder to fix than supporting a low SDK version from the beginning. And it all massively depends on the actual code.
Based on the comments by Ricky Mo.
The problem is that the default is the "Project View", which contains a build.gradle file that that defines the Kotlin version and the Android Studio Gradle plugin version.
The build.gradle file that defines the minSDK is found in the app folder (screenshot).
Alternatively you can switch from the "Project View" to Android. From the dropdown menu that open when you click "Project" (screenshot, highlighted).
My app targets Android 4.4 and up. But I have SDKs from like 14-25 installed via the Studio SDK Manager. I don't use the emulator except on rare occasions - but when I do its typically for 4.4 & 5x. But collectively Android Studio is taking up over 100Gb of storage on my system...I need to reduce its size (big time)
What can I delete that allows me to still target 4.4 and everything newer?
This question has been asked a multitude of times but everything I researched did not provide a clear answer.
If I delete 14-24, and build my app with just SDK 25, can my app still support Android 4.4? Or do I need to hold on to specific SDKs so that my app will still support all Android versions 4.4 and higher? Please be specific, too many vague answers out there.
My app is a cordova/ionic app - many plugins references specific versions of SDKs - typically based on when the plugin was last updated. But quite often these plugins are tested with SDK 22, or SDK 21 (mainly because the author has never bothered to update/maintain the plugin - but it still works) - will those plugins still work if SDKs 14-24 are deleted and only SDK 25 is installed?
As mentioned, I occasionally need the emulator for specific system-images; in lieu of question #1 - if I want to try spin up Android 4.4 emulator do I also need to keep specific SDKs to support those system-images.
Using the Android Studio SDK Manager - does removing specific SDKs via the manager also delete things from my hard drive? I would think it would, but I read some other blogs where people were manually having to delete things.
the Build procedure depends of BuildTools and Android SDK. If you set "minSdkVersion: 10" and "targetSdkVersion: 27" then YOU SHOULD manage all code differences between all versions. There are two possibilities: (A) older method/class is not more available on newer SDK: then the bulld procedure will fail because you cannot call/use them directly but only via Reflection (B) newer method/class is not present in the older SDK: then the build procedure ends fine but your App will crash when THAT method/class is used if you don't manage that specific case using "if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.xxxx)..."
it depends of what kind of plugin they are. Are they AAR file? Are they an editable project that you could join/add to yours? are them external libraries? AAR files and .SO libraries are already compiled so they doesn't need any other/external file or development tool.
Emulator runs using its own "System OS" files, so all the development stuff is unuseful for it. You can run an Emulator even without having never installed a development tool (Android Studio or other things)
Removing items from the Manager should remove even its files, but in some case there could be a bug and nothing (or just partially) is deleted. But you can check your drive storage free space if it is increased.
I have a Unity project that uses google vr. Unfortunately, there are some incompatibilities with the newer versions of tools and platform tools in the android sdk.
I think I can just have a separate android sdk that has the older, compatible versions of these folders and put it in my Unity project. This would allow me to keep the android sdk associated with my Android Studio projects up-to-date and keep my Unity project working. BUT, it means having two copies of the android sdk... which are big (It said ~30G when I started copying my android sdk).
Is there a more elegant solution that would not take up so much space?
The Android SDK is not particularly large: you can choose which parts of it you need, and install only those.
One of the things that make it so large is Android device images (emulators). If you don't need those, don't install them and it should take less space on your hard drive.
what u need to do is to specify android sdk in Edit-Preferences-External Tools
Background: I have been using the Terminal-IDE program to learn about doing Android development (I like vim, for starters...).
https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside
As shipped, it supports SDK level 9. I want to support level 14 (Android 4.0+), so that I can use GridLayout instead of the more complex TableLayout.
I emailed the author, who responded in less than a day (kudos!), but, when I look for a replacement android.jar under /system on my tablet (Nexus 7 model 2), that particular jar does not exist, only many other jars with longer names that are just wrappers around dex files.
Anybody ran into this problem and solved it?
Upon further emails with the author of the environment, I found an easy solution:
Go to the system/classes directory of the T-IDE install
Rename the existing jar (e.g. - android.jar.t-ide)
Copy the android.jar from the SDK (or sdk directory within Android Studio) with an alternate name (e.g. - android.jar.studio.sdk)
Make a symbolic link from the updated SDK jar to android.jar
Now I can use GridLayout from Android 4.0 - compiles (on the tablet) and runs just fine. I did not need to update any other environment variables or configurations, as I replaced the original android.jar with a sym-link to the updated jar (and an "ls -l" will show which one is being used as "android.jar").
Note: if you get the updated android.jar from Android Studio, be sure to get the one in the sdk directory, not the one in the "plugins" directory, which won't work.
I have built an Android app that worked fine on Android 2.3.* and 4.0.*. However, after upgrading my device to Jelly Bean (4.1.1), I found my app does not work properly (crashes, ANRs, etc.) any more.
As a temporary workaround, I am wondering if it is possible to pack an earlier version (say Android 2.3) of the Android framework JAR into my APK and force all my code to use classes/APIs in that JAR?
I think including the JAR in my APK should be easier. But I have no idea how I could force my code to use classes/APIs in the JAR during run-time.
I know it is not a decent fix (hacking, package size, legal issue, etc.) even it will work. But I am just curious whether it is feasible.
Any suggestions or hints would be appreciated!
(Edit)
I have tried the following:
Extracted the /system/framework/framework.odex from an Android 2.3 ROM;
Deodexed it and converted it into a JAR file (say framework.jar);
I verified framework.jar and it contains the actual framework code, not stub methods;
Put framework.jar into the libs folder of my project and built out the APK;
I verified the result APK and the android framework classes are indeed included.
However, it seems my code is still using the classes/APIs of the actual version of SDK installed in the Android device. :(
(Edit)
It seems all the framework/core classes are already pre-loaded from the device (/system/framework/framework.odex) by Zygote during system boot-up time, for performance reason. So even I have included those classes in our APK, the pre-loaded ones will still be instantiated instead.
This sounds like a dead end to me... :(
As a temporary workaround, I am wondering if it is possible to pack an earlier version (say Android 2.3) of the Android framework JAR into my APK and force all my code to use classes/APIs in that JAR?
That is not possible, sorry. What you think of as "the Android framework JAR" has no code -- it is merely stub implementations of the classes and methods exposed in the Android SDK. The real Android framework resides in the firmware, and you cannot replace it.