Using Activities from Library projects - android

I have a Library project set up and a project which depends on this library project - Everything compiles fine and I've had the Dependent project running fine however;
I'm have an intermittent problem however while using an Activity from the Library project.
My Library project can be "unchecked" as a library project and the "picker" Activity can be run in isolation. Running the Library project in it's own right works fine with no problems.
When I use the Library project (and the "picker" Activity) from the dependent project it gives me either NullPointerExceptions (or historically DexOp) errors saying that the "picker" Activity can't find it's resources.
Can anybody tell me if they have experienced this before?
EDIT
Manually copying the layout.xml used by the Library project activity to the dependent project makes the project open the "picker" Activity correctly. Is this required?! Surely not? This further makes me wonder if there is a problem with merging/referencing the integer id's from R.java in the Library project.
EDIT
I'm not sure if this is of any consequence, but one of my Library projects is a wrapper around a set of custom views used in different front end projects.
These custom views each have an Activity so that they can be tested in isolation.
One of these view's has custom attributes, which while running in isolation work very well. However, it doesn't seem like the dependent project correctly pull's in the attributes and keep's them in their original namespace, causing the imported layout's to throw compilation errors:
[2012-05-16 12:07:28 - Project] D:\opt\workspace\CustomGlowList\res\layout\main.xml:14: error: No resource identifier found for attribute 'listId' in package 'com.company.library.glowlist'
[2012-05-16 12:07:28 - Project] D:\opt\workspace\CustomGlowList\res\layout\main.xml:14: error: No resource identifier found for attribute 'type' in package 'com.company.library.glowlist
EDIT
DexOp errors were solved by removing a duplicate file name which was present in the Dependent project. Not sure if the file name was the problem or the contents of the file.
EDIT
I've been unable to find a solution to this problem as of yet (although #yorkw's answer certainly helps with the xml attributes! Thanks).
I have managed to make this problem intermittent however:
I have gone through each of the library projects and ensured they all had their own namespace (ie, com.company.library.component1, com.company.library.component2 etc). After a couple of clean's (each project ordered with the correct precedence) this problem resolves itself, however does eventually come back when switching around library/not a library to test components.

Cause:
Issue 9656: Library projects don't support custom XML attributes for custom classes
Solution:
Upgrade to latest SDK & ADT version (fixed was released since r17) and use http://schemas.android.com/apk/res-auto as custom attributes' namespace URI, see Revisions for ADT 17.0.0:
Added support for custom views with custom attributes in libraries. Layouts using custom attributes must use the namespace URI http://schemas.android.com/apk/res-auto instead of the URI that includes the app package name. This URI is replaced with the app specific one at build time.
Related Topic:
Help with a custom View attributes inside a Android Library Project

not sure how you use the android library , but i've done this thing a lot of times without any problems , so please have a reading of the next things regarding using android libraries:
in order for an android project to use an android library project , you can either edit the "project.properties" and add the path to the library project there , or , much easier, right click the project (that uses the library project) , choose "android" category , and choose there "add" and choose the library project.
in order to make the android project to always open the android library project , also choose "java build path"->"projects" and choose the library project.
on the "project.properties" , try to set the target to the same target for both projects , and to the newest one that you have (latest now is 15) ,even if you can't test the app on this android version .
source files and all resources files (in the res folder) are ok to be used on the library projects.
assets folders cannot be used inside the library project . only on the android project that actually runs , the assets folder can be used . same thing goes to the proguard file .
the manifest of the library projects almost doesn't need to have almost anything . see this post for more information: https://stackoverflow.com/a/10445630/878126 . if there are activities on the library project that you wish to be able to access via the project that use it , don't forget to include them in the manifest of the android project (no need to write them in the manifest of the android library) .
remember to run lint before you export the app . it gives you plenty of warnings , but the most important warning is when you use too-new functions that cannot run on the range of APIs that you target . this is important for libraries since it's easy to get lost if there are multiple sources .
if you wish to extend activities on the android library , you need some kind of a method to go between them . the only way i know of is to extend the application and let it be the manager of how to create an intent for each of the activities . i think you can do other tricks , but they are all probably similar to this one.
if you have the same resource (any resource on the "res" folder) on both the android library and the android project, the one on the android project will replace the other one . this has advantages and disadvantages . remember that you can't have different file extensions for the same resource .

The problem was being caused by the R files from each of the Library projects not correctly being built and referenced. The resource files are built and referenced directly from the calling project.
Each of the Libraries need to have unique package as defined in the AndroidManifest.xml. This leads to each of it's resources being compiled in that unique namespace within the calling project alongside the Library jar which contains the class files.
The problem becomes intermittent when switching between a library and a runnable project because a clean and build needs to take place to regenerate these files as it isn't done automagically when unclicking the Use as library checkbox, where as the jar (and java classes) don't require as much coaxing for them to be correctly referenced as the library projects references them when acting as a Library.
This can lead to intermittent and also varying errors including missing references, DexOp and NullPointerExceptions depending on to what degree the R.java files have been mangled or partially built and what conflicts are taking places between packages.

I have same issue like, I have one library project and it has some activity.
When I was calling library project's Activity from my Main project, layout files resources were not getting loaded properly for the libray project's activity and giving "nullpointer exception" or "class could not be loaded", etc.
Solution: I have noticed that same layout file name is getting used in my Library project and Main project. I have just renamed those activity and it is solved.
May be this will help you.

I had similar issue when referencing Library project inside the Android App project. I deleted the R.java file from Library project so it generated again and App picked up the generated file. You should see the generated R.java file under your app project->gen->library_namespace_R.java.

Related

Error: cannot access android.support.v7.app.AppCompatActivity

I need your help, (I searched the questions, but I do not understand though the answers are positive) What should insert code? (The answer comes that I send the code of appcompatactivity. But I do not understand)
I'm working with android NDK but send me the error .. This is my code
C:\Users\Eduu\AndroidStudioProjects\NDKSample2\app\src\main>javah -d jni classpath C:\Users\Eduu\AppData\Local\Android\sdk\platforms\android-19\android.jar;..\..\build\intermediates\classes\debug com.example.eduu.ndksample2.MainActivity
work: Android Studio
When you create a new app, Eclipse gives you a copy of the compatibility library. (One can only guess if you are using Eclipse, but I do.) The purpose of this library is to implement fragments and other post-3.0 stuff on 2.x devices. You are given this library only if you specify a 2.x target when you create the project. In one of my workspaces, I have 24 copies of the library, ranging from appcompat_v7 to appcompat_v7_24. Each one is located on the same directory level as the corresponding project, that is, in the same parent folder. It is easy to guess which copy corresponds to the latest project, but if you don't know for sure that the project is the latest one, you have to search the config files.
If you put your project under version control and forget about this dependency, you get an error in the copy retrieved from the version control. Fixing it is a tedious task, Eclipse is no lucid coding. You will have to manually specify the dependency in several places. One possible approach is to create a new project and move the source to it (note that you can move the version control directory, like .hg or .git, and restore the source, if that does not sound too untrivial for you), another one is to create a new project and use its compatibility library.

How to prepare a closed sourced SDK module on Android Studio?

Background
I'm working on an app that has become very popular, so much that a part of it is supposed to become an SDK (which would be available for developers), and the app will split to 2 apps (both use the SDK).
According to what I know, there are multiple ways to create an SDK module (previously called "project" on Eclipse) :
Completely open sourced (Android library) - all sources and resources are open sourced and can be modified. An example might be Facebook's SDK and a lot of Github repos.
a single Jar file, which can be closed sourced.
The problem
Sadly, I can't make the SDK open sourced, and it should relatively be protected vs prying eyes (obfuscated etc...).
The issue here is, the SDK needs to use some resources of its own (drawables, strings,...), and so far (because I didn't have a lot of experience with creating SDKs) I've found 2 ways to handle resources for SDKs :
use reflection and/or "context.getResources().getIdentifier" . This is quite messy, as I lose the whole "R" usage of the code. Also, it has issues with "styleable" , as I've written here. It also makes it hard to find unused resources.
even worse ways: put resources in assets folder, put files in a wacky way inside the jar file, ...
Note that a part of the SDK includes custom views (for example, classes that extend from TextView), so even if I do split the SDk into 2 modules- resources and java files, both might have issues of dependencies (each uses the other one).
The question
Is it possible to somehow solve this issue?
Is it possible for the code part of the SDK to remain closed sourced, reach the "R" file as usual, and make it easy for both me and whoever use the SDK ?
How would I then generate the jar file as being obfuscated via Android Studio? and is it possible to prepare it to to be used via gradle afterwards?
Can I maybe make the Android-library of the SDK into an obfuscated jar file and not worry about the "R" file ? I ask this because this way I could enjoy both worlds: for our apps, it would remain open sourced, and for third party apps it would be closed sourced.
EDIT: seeing that this is supposed to be easy, I've tried it myself. I've created a totally new POC project which has an Android library module called "sdkmodule", and added this class to it:
public class SdkClass
{
public String doIt(Context context)
{
return context.getResources().getString(R.string.app_name);
}
}
Then, I've made the app's module to use this one, and I wrote this code in it:
#Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
SdkClass sdkClass=new SdkClass();
Log.d("AppLog","string from SDK:"+sdkClass.doIt(this));
Log.d("AppLog","string with same ID name from app:"+getResources().getString(R.string.app_name));
}
What I expected is that the first log would print the string that's in the SDK module, and the second to show the string of the current project, but instead I got an exception:
java.lang.NoClassDefFoundError: Failed resolution of: Lcom/example/user/sdkmodule/R$string;
On another try, I've got the same string that's used on the app itself (the one that uses the SDK module). And, on another run, the SDK produced the needed string as I've wanted.
How could it be? What should I do ?
In addition, I've tried to make a second activity in the SDK itself, and I've created a resource there that has the same resource name (used for a textView in its layout) as of the app itself, yet with a different value, yet when I've reached this activity, I've seen the one used by the app.
Here's the project, zipped (ignore the name of the folder, I wanted to try flavors too) :
https://drive.google.com/file/d/0B-PZZGk2vPohX25WUDNKTmotUTg/view?usp=sharing
The answer to your problem is to package and distribute your library as an AAR bundle
This format allows you to provide an obfuscated SDK jar and with its resources and the R mapping file.
This format is a standard and fully supported by maven-android-plugin (actually it's the replacement of the old APKLib format which supports only the distribution of source files).
Of course it's also supported by Gradle and Android Studio.
The Android Archive (AAR) format does what you want. It's like an Android-specific JAR file and contains compiled code, but includes its own resources and manifest. You can also include obfuscation as part of the build process. By default, the current version of Android Studio (1.2) and Gradle automatically build .AAR files for all library modules you create in your project.
You can change an app module into a library project that will publish an AAR file just by changing apply plugin: 'com.android.application' into apply plugin: 'com.android.library' in your module's Gradle file. The .AAR file will be placed in your MODULENAME/build/outputs/aar folder after each build. Some more information is available here.
Edit 1, after question updated:
The resources in your AAR get consolidated with the app module when the final APK gets compiled. The app resources will override the library's. This is probably by design, to allow people using a 3rd party library to customize its resources when creating their app, without having to rebuild the library. I think the easiest way to solve your resource conflict issue would just be to name your sdkmodule resources something more unique. Why not make the string key R.string.com_example_sdk_name or something?
No, the AAR libraries don't get obfuscated by default, but you can set up ProGuard in the Gradle build file for your AAR library to take care of this. Other tools are also available.

Android library project as jar file for distribution, like google analytics

I have seen this question, and have some more doubts regarding creating a jar file which I can distribute and can be used in any android applications.
What my requirement is
As I said, I want to build and distribute a closed source library. I
don't want the source code to be visible.
In that library I don't want to use any assets, layouts, resources
etc. But I want to use some android specific codes, like getting
android device id.
The most popular answer in the above linked SO question tells to create a regular java project and import android.jar in it. I tried to do that, but I don't know how to add android.jar to any java project. I would like to get some clarification on that too.
Moreover I would like to know if there are any other methods using android sdk itself (without using java project) create a closed source library jar file.
I think what I want is possible, since google analytics for android native apps seems to have done it. I am sure in the .jar file they distribute they are using android specific codes, since there seems no other way for them to get the device information to display in the analytics viewer.
EDIT : CAN SOMEONE CLARIFY THIS??
I think I have made some progress. This is what I have done
Created a regular android project (not library project, the "is
Library" checkmark is unchecked)
In the project I have coded out my logic. It uses some android
specific classes like SharedPreference, UUID, PackageManager. But
nothing related with assets, layouts also no class extending
Activity. Just a java class extending java.lang.object
Exported the project using Project->rightclick->export->Java->JAR
file. In the next screen I unchecked the checkbox near
AndroidManifest.xml. Set a destination directory to export and
clicked next thrice with keeping the default settings. Then I clicked
Finish, and got a lovely libMyLibraryName.jar at my desktop.
Then I created another android project, added this libMyLibraryName.jar to new project using project->rightclick->properties->java build path -> libraries->add external jar.
And I tried to use my class in the library, in my new project
MyLibraryClass objClass = new MyLibraryClass(this);
And I was able to compile and run successfully. I even sent the library to one of my co worker who was able to use the library in his on machine (Just making sure library project in my workspace wont influence the project using it).
Now I have 2 questions.
1) My first question is , what they meant by the term "true library" in the below given documentation ? Is it any non android java project which can be exported to a JAR file?
However, a library project differs from an standard Android
application project in that you cannot compile it directly to its own
.apk and run it on an Android device. Similarly, you cannot export
the library project to a self-contained JAR file, as you would do
for a true library. Instead, you must compile the library indirectly,
by referencing the library in the dependent application and building
that application.
Well this portion is taken from documentation under title "Library Projects".
2) My second question is, anything wrong with the way I have created the JAR file? Any possible pitfalls which might bite me back later? I would like to make sure I am not doing something terribly wrong, before using it in my important projects.
I might add that I didn't try the method of creating a JAVA project and importing android.jar. I am ready to try that one, if what I have done currently is wrong.
The android.jar will be located where you installed your Android SDK. Under the platforms directory there should be a number of other directories named android-<version>. The android.jar will be there. Choose the one specific to the minimum android version you are targeting.
Once you have that, copy it into your project. If you're using eclipse I think you can just cut and paste jars straight into your project, right click and add it to build path. If you're not using eclipse or any other IDE, you just need to ensure that the android.jar is on the classpath when building your jar file.
After that your newly built android library can be dropped into any Android project.
In answer to your additional questions:
What they mean by a true library is a jar file as opposed to an Android library project.
I don't think there's anything wrong with the way you created the jar file. I would have made it using the android.jar as I mentioned above but your way should also work. To verify this I would examine the jar contents and make sure all you have in there is .class files.

Sharing Java library with Android Apps

I'm just getting started in Android development, and use Netbeans with NBAndroid and SDK 17.
I'd like to use the same Java source code in my Java and Android app.
http://developer.android.com/guide/developing/projects/projects-eclipse.html says how to do it in Eclipse (although it is sketchy on the .JAR connection thing), but I can't seem to make it work in NB.
Based on that link, My understanding is that the correct setup for the Android app is an Android Application project which references an Android Library project which in turn references a .JAR library produced by a Java Library project. I could then also have a Java Application project referring to the same Java Library project.
So, I've set up this project structure... I have an AndroidApp project which is a basic HelloAndroid Activity in a com.ex package. This project includes an AndroidLib library project in the Libraries folder. I also have a LibClass.java file which defines a simple LibClass class which has one function getText() that just returns a String to be displayed. The MainActivity in the AndroidApp calls this to get the String to output.
When I put LibClass.java directly into the AndroidLib project, everything is fine.
But what I want to do is to share the source code with Java.
So I want to move the LibClass.java into the JavaLib library, whose .JAR file is included in the AndroidLib project. However, when I tried that, I get an error in the MainActivity class, complaining it can't find LibClass. Looking at the Projects window, I can see LibClass.class inside the com.ex package in the JavaLib.jar in the Libraries folder of the AndroidLib project. And AndroidLib is visible in the Libraries folder of the AndroidApp project, but it doesn't show any packages or other contents there.
So I feel like I'm just one step away from making this work. Do I need to do something with one or other of the AndroidManifest files perhaps? Or do something with the build.xml files? Or am I on the wrong track altogether?
I'd be really grateful if someone could post a how-to for this.
I'm trying something similar; I've got Java EE projects, built using Eclipse, and I'm trying to utilize some of that code from my Android projects. This should give me a shared codebase rather than a bunch of confusing SVN externals which I've had to endure before.
Rather than creating JAR files I've found that working with the source and building for the platform works best (well, it has been working but I've got a problem with it at the moment). So, what I'm doing is:
c:\MySvnFolderStructure\MyJavaProjectFolder\src\ (and then all the source under that)
c:\MySvnFolderStructure\MyJavaProjectFolder\android\ (and all the Eclipse Android project gubbins)
c:\MySvnFolderStructure\MyJavaProjectFolder\jee\ (and all the Eclipse JEE project gubbins)
The Android and Java EE projects do not have their own src folders, they both link to the src folder in their parent folder. What this means is that each of the Java implementations is building its own byte code version from the source, and using its own external libraries (like the Apache HTTP ones, for example).
Naturally they can't share stuff like awt (as mentioned in another post), but there's plenty of stuff that does cross-over especially if it's core Java classes that are being used.
Also, it's proving a bit tricky writing JUnit tests as there needs to be some duplication of the test code at the moment because the Android ones need extra instrumentation, but I'm working on it.
Also, see this post about relative paths in Eclipse, which means the folders can be checked-out to different places on different machines (like we all do with our version control check-outs) and still be shared.
if I understand your situation correct, you are trying to use a custom java library for both your android and java applications.
For this scenario, you can build the java library first. Instead of adding the java library jar as android library, you can drop the jar directly inside the libs folder of android project and add it to android project's build path.
If you are using ANT scripts for building the java library jar , you can consider adding the source files also as part of jar. This will help you get code assistance when you develop the android part. But this part is purely optional.
The problem is that the Java platform in Android is different from the JDK platform.
In particular, the .JAR library CANNOT refer to anything that is not icluded in the Android platform. An example of things you can't refer to is java.awt.* (except you can have java.awt.fonts).
There is also a difference between JDK String and Android String -- Android does not implement the isEmpty() method.

Android project as Jar Library

I am currently working on a Android Project where we are expected to merge our App with 2 more apps from vendors who wouldn't be sharing their code.So just wanted to know Is there any way we could just include there Source code as JAR Files in our project and then include their resources and point to them(I did do it using getResources().getIdentifier("splash", "layout", getPackageName()) But Its still not working ?? I think I have tried all possible methods so hoping you guys could help me with this.
To quote CommonsWare from this question:
Bear in mind that your packaged classes cannot reference resources (at
least not via R. syntax), and that JARs cannot package resources,
manifest entries, etc. If all you are trying to JAR up is pure Java
code (perhaps using Android APIs), then you should be fine.
Basically, you can only use JARs that contain pure java as libraries in your app, not entire other projects.
The Activities can be compiled into a jar and added to the main Android project and we need to add their project's resources into your Project. The only we could make it work is using the getResources().getIdentifier("splash", "layout", getPackageName()). Even the Widgets like TextView, Button and all those should be referred to using the getResources() method. Like, for example, If you want to perform a action on particular button then we need to identify them by getResources().getIdentifier("Button" /*id in the XML File*/, "id"/*type*/, getPackageName()).
One more thing: you need to specify all the Activities in your Main Android Project's AndroidManifest.xml file with their package name. I hope this solves something.
In order to support faster build times, the r16 tools are creating their own jar files inside of Android Library Projects. You can use this feature to solve this issue. If a vendor would like to release their Android Library Project but without source code, they can make a copy of that Android Library Project that contains everything except for the source code tree. Next, include the jar file from the original Android Library Porject (the one that the r16 tools built.) This will allow you to have a component you can distribute that does not require source code. The consumer of this new Android Library Project will need to manually add any necessary meta data to their own project's AndroidManifest.xml file as needed (Activities, Providers, Permissions, etc).

Categories

Resources