if you have 2 modules that has dependency on support v14
do you put the same dependency in both modules or you put it in one? I mean does it make the apk include the code twice and hit the 65 k limit
Thanks
Put the dependency in every module that needs it. Doing so makes the modules more independent. You can reuse a module in another project without having to worry about the dependencies.
It will be included in the APK only once.
Related
If I have multiple modules in my android project and I add a library dependency (like dagger or appcompat) in (say) 2 of those modules, will that library add twice of its size to the final APK size or will there be just one copy of the library in the final APK?
Also what if I use different versions of the library in different modules, how much will the APK size increase?
I have the same question which you asked so I tested this scenario and create a project with more then one module and place the pdf dependency
implementation 'com.github.barteksc:android-pdf-viewer:2.8.2'
in different module and then build the apk but there is no change in size of apk either to put dependency in one module or more then one module.
I am working on a project and have planned the following architecture within one single Android Studio project:
1) Eight custom library modules which I intend to reuse in future projects.
2) Three closely related apk modules which complement each other's functionality.
3) Five shared modules which would be used in above apk modules.
Is this the recommended approach to keep the project architecture modular, and reuse of modules in multiple projects, while ensuring performance of Android Studio.
You need to have more RAM for bigger projects , atleast 8 GB .
Lets say you have 2 apk modules and 1 library module that is being used by the 2 apk modules. If you find the compile times taking longer you can disable the apk module you are not working on temporarily and compile it faster .
I have to add a 3rd party library to my project.
Let's say the library is called XLib and it is made by vendor A.
I already have in my project a library with same name (XLib) but it is made by vendor B and they are 2 different things, I need them both.
how do I handle this scenario in Android Studio?
Thanks,
how are you importing these libraries? are they library modules or gradle dependencies?
if they are library modules, and you have the source, i would recommend renaming the modules XLib-VendorA and XLib-VendorB. Assuming they don't also have overlapping package structures, that may be all you need.
if they are gradle dependencies, then they should originate from different group names, so you would only be concerned about package collisions at that point.
If I need to use some library in multiple modules and add the line
compile 'example.path_to_library'
to both modules build.gradle,
will it create only one instance of the library classes and point to that or each module will have 2 separate libraries of the same stuff?
it will create only one instance of the library classes and point to that.
The library will be downloaded in your External Libraries folder and both the modules will access the same library.
if it solves your problem..do check this answer as correct..thank you, have a good day :)
Project explained below is created and built using Eclipse Juno(4.2).
We receive the following error when executing the Run Configuration for our Android application:
Dx
trouble writing output: Too many fields: 65757; max is 65536. By package:
2857 com.android.foo.bar
12 com.android.foo.bar.util
236 com.blah.yo.io
6 com.blah.yo.util
2 com.hmm
82 com.hmm.android.app
2761 com.hmm.android.common
2761 com.hmm.android.map
2761 com.hmm.android.map.common
.
.
.
A list of namespaces follows with similar numbers preceding them
Conversion to Dalvik format failed with error 2
Here's an example of our project structure:
Conceptual structure:
A - main/non-library module
B - library module/Android dependency of A
C - library module brought in as an Android dependency of library module B
D - library module/Android dependency of A
E - library module/Android dependency of A
F - library module/Android dependency of E
G - library module/Android dependency of E, B, D(a common IO module used across the different modules)
Folder structure:
/Project A/
B/*Android module structure*
C/*Android module structure*
D/*Android module structure*
E/*Android module structure*
F/*Android module structure*
G/*Android module structure*
At first we thought "wow, we've hit the max fields_ids_size so our app must have gotten that big", which it is a rather large app functionality-wise.
After some attempts at cleanup/discovery on the issue we are doubtful this is the cause. After analyzing the classes.dex file for the fields_ids_size and attempting different things we find that we can shrink the number of fields_ids down if we remove the library modules and just include them into the main project. Horrible for code/module reuse across projects, but takes the number from the above error message from 65757 down to nearly 24,000. Likewise, if jar'ing up a library module and including it into the classpath of the dependent entity(whether its the main non-library module or a library module), the number also shrinks if you remove the Android dependency to that library module and just use the jar file.
Seeing this, I took D from the example above and made it it's own standalone app with no dependencies/tie-ins to other modules and created the classes.dex file for it. Let's assume for this example that D has the namespace com.android.foo.bar. From the example error above this namespace was taking up 2857 fields ids when used as a library module of A. When compiled as it's own app and analyzing the classes.dex file, I saw this number fall to around 120 fields ids.
This is a rather large issue for our app as we're hitting this upper limit. We do have a workaround of sorts, but it is rather clunky and time consuming. I'm hoping there is a solution for this to allow us to have these library references and not have the issue of the number of fields_ids for library modules seemingly being inflated causing this issue.
I recently came across your exact same issue. My main project references a lot of library projects so I can easily re-use my code.
Lets say that 3 of my library projects both depend on the much used library, actionBarSherlock. In all 3 packages it will auto generate R.java and place ALL of the ids from actionbarsherlock into the new R.java. So now you have 4 R.java files (ActionBarSherlock, lib1, lib2, lib3) with many of the same ids being used.
The trick to get around this is to declare the same package name in all your library projects AndroidManifest.xml so you don't have so many identical ids.
The other alternatives are:
1) Build your projects with ant to create and load more than 1 dex file (Horrible solution) http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html
2) Merge and simplify the code
I hope this helps