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.
Related
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
First some premises:
Android applications make use of Android SDK API classes.
A class definition is some code or parts of code, which gets compiled into machine code/bytecode.
I assume that all (or most of) the classes/packages that make up Android SDK API are listed under:https://developer.android.com/reference/packages.html
https://developer.android.com/reference/classes.htmlWhich is a lot!
Now the question:
Where do these codes/data reside? Are they compiled along with the application code into the APK file or do they exist inside the Android OS on a device, in which case the application should dynamic-link to them?
If they're present on the device, then what difference does it make to compile the application with newer Android SDK versions (per compileSdkVersion in Android Studio for example)?
Let's say the "Android SDK Build-Tools" (which is not the same as "SDK Platform" (according to "SDK Manager" window!) and has its own versioning) takes care of compiling your code and therefore newer version mean better bytecode optimization and faster JAVA -> DEX translation!?
Does "SDK Platform" which you compile your android application against and set it's version with compileSdkVersion keyword, contain solely class declarations and reference-symbols?!
What about Google APIs (e.g. Google Maps API)?
What about Android Support Library?
The Android SDK code is baked into the device, and is not part of your apk.
Stuff you need to include via gradle compile gets into your apk (e.g. Support Library)
The Android core SDK classes are provided by the Android runtime instance that runs per App, you might call it the Android virtual machine if you will. When your App needs to load a specific Android framework class, a Classloader will load it for you in a process similar to dynamic-link as you mentioned.
There is not much you can do to change the version of the framework running on the device. However, the reason you need to specify the different minimumSdk and targetSdk, is for the lint/compiler tools to indicate you what functions/apis might not be present at runtime in specific framework versions. Based on this information you provide wrappers/adapters or simply if/else logic to provide an alternative functionality or simply to avoid a ClassNotDefinedException or MethodNotFoundException at runtime. It is basically a dev tool to help you visualize what could be wrong with other versions different from the one you are compiling against.
Certainly when you compile it, it produces references-symbols in a similar way as if reference an included library. The VM Classloader will resolve the actual file to load at runtime. Not quite sure how Google Apis work but it might be provided as well, in the case of the support library it gets included as far as I know.
I am on Windows 8. I have some questions regarding Android SDK:
Can both IDEs share a common Android SDK?
Will there be any issues in updating IDEs?
Generally, yes, it's safe to share a common Android SDK for both Eclipse and Android Studio. Updating IDEs won't affect the SDK at all.
Take note when updating/deleting packages in Android SDK Manager: you might use some packages (e.g. specific API version) in a particular IDE (past example: Android "L" Developer Preview in Android Studio). Updating/deleting them may break the project that use them, and it might be difficult to fix the issue. However, for already-stable APIs like Android KitKat (API 19) and below, there won't be any issue when updating them.
Additional note: Android project created in either Android Studio or Eclipse is not really compatible to each other due to different project structure and technology. Therefor, it's better to always use the same IDE for projects that are created in it. If you want to test both IDEs on same project, it's better to export the project from Eclipse, instead of from Android Studio as it's easier.
I am not fully certain that I am not making any mistakes when setting API level when developing under Eclipse so here are some examples which I am not 100% certain about.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
Yes this practice is correct and is done to ensure support for the latest android versions.
When you set a minSdkVersion, then that's thr lowest version of Android your app will support and compiling with ant/gradle will show errors ehen you will use methods introduced in newer api levels for an older one.
Deprecated means that another method has replaced this one and that this one will spon be removed from the Android source code, so developers are encouraged not to use them. But yes they will work until they remain in the source.
The android.jar is a dependency of the methods and stuff included in the android OS, stuff that you'd be able to call and no I don't think framework.jar plays a role in this.
All external libraries are referenced and added to the apk. BUT only some of the google ones, those that are not primary. (Take a look at the gapps packages, that'll give you some specifics. Link: http://goo.im/gapps)
I hope I got this right and helped you to understand.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
Yes. That way you ensure you're always using the latest build sdk.
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
Just make sure that older devices will not get to that part of the code, using Build.Version.SDK_INT. This will give you the current SDK of the device.
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
Deprecated methods will continue to work, but better alternatives are available. When you have the option to use that better alternative, use it. When you're supporting devices that don't have this alternative yet due to older versions, continue using the deprecated method. You might have to do some if else branching based upon the Build.Version.SDK_INT value.
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
The newer devices contain the code of the older devices. Therefore it is not necessary to keep references to other versions.
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
The class files in the jar will be packaged in the .apk. The Google Play Services on the device communicates with your app using those classes.
I faced a suspicious problem when I tried to update my Android App to work on 4.2.1, Nexus 7. I'm using my own .so library, which inclusion was working fine on Android version 4.1, before I updated. Now I get all sorts of problems.
I compared the logs when deploying on an Android device running 3.2.1 and my Nexus 7 running 4.2.1. The library is being placed in two different locations, which might be causing my problems.
ANDROID 3.2.1:
Trying to load lib /data/data/com.my.app/lib/lib_my_app_jni.so 0x407e8218
Added shared lib /data/data/com.my.app/lib/lib_my_app_jni.so 0x407e8218
ANDROID 4.2.1 (Nexus 7):
Trying to load lib /data/app-lib/com.my.app-1/lib_my_app_api_jni.so 0x4257b6c8
Added shared lib /data/app-lib/com.my.app-1/lib_my_app_api_jni.so 0x4257b6c8
Why is it all of the sudden placed in the mysteries app-lib dir? How do I force it back? And where is this documented?
Thanks...
From Android 4.2, multi-user feature added in android frameworks.
And several directory locations are changed, but API is not changed such as Context.get???Dir() or Context.get???Path(). (just return value is changed)
Also android platform make symbolic link for legacy.
These changes are not documented.
I'm going to answer my own question, because we ended up implementing our library differently then originally intended.
The problem was that we were copying over access certificates and more, to the directory that the library was in. This approach worked fine on older Android versions, where that was located in the data/data/package/. But on newer Android versions (data/app-lib/package/) that location is read-only.
What we did was to move the location, simple. Thanks for the input.