I'm using google-play-services library in my app which is a eclipse project.
When final apk creating, it's containing some extra entries in manifest.xml file which is showing as containing ads alert when publishing app.
Extra entries showing like -
<activity android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode"
android:name="com.google.android.gms.ads.AdActivity"
android:theme="#android:style/Theme.Translucent" />
How could we ignore/remove these entries from final apk?
<activity android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode"
android:name="com.google.android.gms.ads.AdActivity"
android:theme="#android:style/Theme.Translucent"
tools:node="remove" />
I think tools:node="remove"can be used for gradle build or will work for eclipse build as well?
It is added by admob library. So if you don't want it and you don't want your app to contain ads, you should exclude admob from your project.
tools:node="remove" is for removing unwanted permission from other libraries that is used in your project and yes, it won't work in eclipse.
UPDATE:
Seems that you are using an old version of google-play-services which contains all modules as a single .jar file. I suggest that you find out which module of google-play-service you need for this project and only add that one with it's dependencies instead of adding all modules of google-play-services as a single jar. And this version you are using possibly is version 8.4.0 of google-play-service (or even older than it) so it is much better to use one of the newer versions.
For using only the module that your project needs and using a latest version of it, you should do as follows. Let's assume that you just need 'play-services-maps`. So you go to
<android-sdk-folder>/extras/google/m2repository/com/google/android/gms/play-services-maps
and open one of the recent versions like 11.0.4 (or less but I suggest to choose one of 10+ versions) and get the .aar file and add it to your eclipse project (if you don't know how to use .aar file in eclipse read this). Also open the play-services-maps-x.x.x.pom file to see what is the other library that maps needs (which are play-services-base and play-services-basement in this example) and go to their folder and add their .aar files to your project too and check their .pom files as well to include tehir dependencies.
Yes, it is kind of tedious job, but it is the way to add this gradle-based-distributed libraries to eclipse.
Related
The purpose of posting images is to spot the errors easily as it is not the normal manifest file.
I'm trying to display Google Maps inside an instant app application. Now the application gets installed successfully (and runs smoothly) if I try to run it via app module i.e. normal install (which means I have included all the necessary gradle dependencies and API key) but if I try to run it as an instant app (not instant run) I'm facing this error:
and it takes me to debug/xml file:
Any idea?
This problem occurs when you include the google-play-services dependency in a non-base feature module. The underlying issue is that although the
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
element is added to the base feature's AndroidManifest.xml, the referenced id (#integer/google_play_services_version) is not available since the dependency is defined, and scoped, in another feature module.
The easiest, and most maintainable, workaround is to add the google-play-services dependency to the base feature module. Everything included in the base is available to non-base features, but as this error shows the opposite is not true.
If you find yourself writing a big Android application that depends on many different libraries (which I would recommend instead of reinventing the wheel) it is very likely that you have already come across the 65k method limit of the Dalvik executable file classes.dex. Furthermore, if you depend on large libraries like the Google Play Services SDK which itself in already contained more than 20k methods in version 5.0 you are forced to use tricks like stripping packages or multidex support to avoid errors while packaging. With Android's new runtime ART which is publicly available since Android Lollipop multiple dex files are easier to handle, but currently developers are still forced to do method counting.
What is the simplest way to reduce your application`s method count while using Google Play Services?
The biggest change for developers that came with the 6.5 release of the Google Play Services was probably the Granular Dependency Management. Google managed to split up it's library to allow developers to depend only on certain components which they really need for their apps.
Since version 6.5 developers are no longer forced to implement the complete Google Play Services library in their app, but can selectively depend on components like this:
compile 'com.google.android.gms:play-services-fitness:6.5.+'
compile 'com.google.android.gms:play-services-wearable:6.5.+'
compile 'com.gogole.android.gms:play-services-maps:6.5.+'
...
If you want to compile the complete library into your app, you can still do so:
compile 'com.google.android.gms:play-services:6.5.+'
A complete list of available packages can be found on the Android Developers site.
For someone who do not use Android Studio w/gradle or don't want to implement ProGuard to you project.
It's possible to avoid 65k while using google-play-services
by keeping some packages that you really want to use by using jarjar. For example, in my project I want to implement only google map and google location I lean my google-play-services.jar like this.
Download jarjar HERE
Create new file call 'services.rules'
edit it as follow
keep com.google.android.gms.maps.*
keep com.google.android.gms.location.*
Copy your original google-play-services.jar / jarjar-1.4.jar / services.rules into the same folder
start command prompt and type..
java -jar jarjar-1.4.jar process services.rules google-play-services.jar google-lean.jar
That's it you will get a new .jar that size was reduce a lot (method also)
use it instaed of google-play-services.jar and dex over 56k will gone.
Here is .jar that was lean already as mention above.
I know this question is old but for those of you who face this issue while working on eclipse and cannot use the above answer
please follow the steps
if you don't want to download android studio to get the lib projects
you can download lib files from here
https://www.dropbox.com/s/1pf73czcn7pyqgi/com.google.android.gms.rar?dl=0
and skip to step 4
1 - first of all you still need android studio to download your dependencies
you can download it from here
https://developer.android.com/sdk/index.html
2 - then in your build.gradle inside your app add the below lines
dependencies {
compile 'com.google.android.gms:play-services-maps:7.5.0'
//map , gcm or any specific api for a hole list visit the below link
//https://developers.google.com/android/guides/setup
}
and then hit sync project with gradle file
after that you will get to lib projects
play-services-base
play-services-maps
right click on them to get their path
4 - create project inside eclipse delete the generate files inside src folder
, res folder and manifest
5- copy res and manifest from play-services-base to your project
6 - copy file inside play-services-base/jars to the libs folder of your project
normally named classes.jar (please rename it to any other name so it won't conflict with other project)
7- add this jar to build paths then right click on project / properties / java build path / order and export tab check the added jar
8- right click on project / properties / android / check is lib
9- make the same steps for play-services-maps
10 - now you got to lib projects one is called googleBase and the other is called googleMaps (or any other name)
11 - add them to your project as libraries
now add the following lines to your manifest
<!-- Include required permissions for Google Maps API to run-->
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-feature
android:glEsVersion="0x00020000"
android:required="true"/>
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
<meta-data
android:name="com.google.android.maps.v2.API_KEY"
android:value="" />
for a complete tutorial with images please refer to below link
http://androidninja.quora.com/Prevent-65-K-Methods-Count-When-Using-Google-Lib-on-Android-with-eclipse-adt
I have an Android library project. I include the version of the library in its manifest. I use this version internally, so right now I also have the version stored as a static constant. Is there any way to read the version of the library project from the manifest so I can remove this redundancy? From my searching, I'm guessing that the answer is no, since library project manifests are in essence discarded during the build process.
I've created apk by maven + eclipse.
It is a single file and has internal references to libraries given by mvn dependencies. On my android everything works great, but I need to display in runtime version of referenced libs. I know how to display version of my application (from androidManifest.xml), but the problem is to get version of other used library, which in some way is included to my apk.
Inside apk I don't see my referenced jars, I suppose it is made by class.dex.
I found the way to get version from jar lib, but it doesn't work for apk.
Can we found version of internal reference library at run-time?
Let me rephrase your question.
You have developed a mobile app which uses third party library and your goal is to find the version of that third party library from APK.
If i have understood it correctly,
then i faced a similar requirement recently.
Firstly the third party jar's manifest will have version information.
When you built APK this manifest info that contains the version info wont be merged with APK's AndroidManifest file.
AndroidManifest schema does not seem to provide this facility.
In our case we ship the library ,so one probable solution is that we can probably add the version info into metadata element inside activity element in Android Manifest file of the library so that apk when it is built it will copy the activity element from the library's android manifest to the app's android manifest.This way we can pass that version info of a library to main APK's Android Manifest.
May be we can make a request to modify the schema of Android manifest to give provision to include version info of internal library.
Please check the following link.
https://developer.android.com/guide/topics/manifest/manifest-element.html
The other solution could be one can possibly use jarsigner to insert custom entry (that contains info on version of third party library into APK's manifest file after building APK.
Thats again not a standard solution.
I've read similar questions here, but am still not clear on a couple of things. Using a Library Project means that my overall project will have two manifests -- one for the library and the other for the "main" app project -- and I'm not clear what goes in which or if there is some redundancy.
I'm developing an app widget with "lite" and "paid" versions, so will have almost all code in a library project. Being a widget, the library will have at least a receiver, a service, a configuration activity, plus a couple of other activities. So where should the full declarations of these components -- including intents, filters, etc. -- be declared? Do they go in the manifest for the library, or in the manifest for the application package itself, referencing the classes in the library (e.g. android:name="com.foo.mylibrary.MyService")?
Some examples I've looked at seem to declare them in both manifests, but I suspect that putting these in one or the other is a no-op.
Using a Library Project means that my overall project will have two manifests -- one for the library and the other for the "main" app project -- and I'm not clear what goes in which or if there is some redundancy.
The library project manifest is not presently used.
Gradle for Android, and therefore Android Studio, support library projects and AARs publishing a manifest. This can include things like activity declarations, required permissions or features, or minimum supported Android SDK levels.
The rules for how library manifests are merged with the app's own manifest -- particularly when you take build types and product flavors into account -- is a bit complex.
So where should the full declarations of these components -- including intents, filters, etc. -- be declared?
In the host project.
The library could publish those components, and the Android Studio host project can then remove them if needed.
Do they go in the manifest for the library, or in the manifest for the application package itself, referencing the classes in the library (e.g. android:name="com.foo.mylibrary.MyService")?
The latter.
In either (with Gradle for Android and Android Studio). In theory, it is easier for the library to publish the components, so the app author does not have to. Personally, I am not a huge fan of this, as too many developers will wind up shipping unnecessary manifest entries.
As of ADT r20 Preview 3 it is now possible to merge manifests. So common configuration can now be put into the library manifest. See https://stackoverflow.com/a/10400355/262789 for more information.
Version 13 of Intellij IDEA is necessary for manifest merging support (manifestmerger.enabled=true). Also the Grade based build system appears to be necessary for Android Studio support.
Any referenced android elements like activities, receivers, services, etc. MUST go into your Application manifest or they won't be recognized by the OS. As you guessed, the Library manifest file is pretty much an empty implementation
UPDATE
As CommonsWare points out above, the Android build tools will now attempt to merge the various manifests on your behalf. Leaving up the original answer for posterity