• Does AndroidAnnotations have any perf impact?

• Generating code ? Yuk! C'mon man, it's 2017!

• How do you compare to RoboGuice

• Why generate subclasses instead of directly modifying the activities ?

AndroidAnnotations not working? See the Troubleshooting guide.

• "The import XX_ cannot be resolved" after a "Project > Clean" in Eclipse

• Warning / error related to AndroidManifest.xml, won't disappear?

• "XXX cannot be resolved or is not a field" error in the generated code

• Nothing gets generated

• Can I use AndroidAnnotations in a Scala Android Project?

• I added AspectJ to my project and AA doesn't work anymore

• I updated to ADT 22 and my classes aren't found at runtime

• I updated to AA 3.0+ and I now have an "Invalid Package File" error

• When using Instant Run, AA adds EApplication error

Short answer: no. AndroidAnnotations has a little compilation overhead (see how it works), but the generated classes are good old classic Android code. No reflection. No startup time, and no runtime impact.

Some people will argue that generating code should be avoided as much as possible. Here are the reasons why I think it can still be a good idea:

• Thanks to Java6's Annotation Processing Tool, the code is automatically generated each time you compile. Which means the generated code is always up to date.
• Android does not (yet) provide quick reflection and dynamic code generation. Which means that we currently have the choice with either slow reflection/Java dynamic proxies (limited to implementing interfaces), or generating code.
• Most tools and IDEs integrate seamlessly with Java's Annotation Processing Tool : Maven, Ant, Eclipse, Netbeans...

↑Back to top

RoboGuice is a great project that enables dependency injection on Android, using Guice. It also provides specific annotations that are very similar to AndroidAnnotations ones (injection of views, etc).

However, RoboGuice read those annotations at runtime, and injects the fields using reflection, which may impact the runtime performances.

AndroidAnnotations generates the boilerplate code in subclasses at compile time, which obviously leads to no runtime impact on performances.

AndroidAnnotations and RoboGuice do not compete, but are rather complementary, depending on your needs. Actually, you can even use both at the same time.

To be honest, I (@pyricau) have used and contributed a little bit to RoboGuice, which is why AndroidAnnotations usage looks similar.

↑Back to top

Because Java's Annotation Processing Tool does not allow code modification. The only exception to that rule is project Lombok, which is great but does not work with all Java compilers.

↑Back to top

AndroidAnnotations is activated when you compile your classes. If an activity is annotated with @EActivity but not registered in your AndroidManifest.xml, a warning is added to the activity. When you fix your AndroidManifest.xml, the warning won't disappear: you have to recompile the class. This can be done in eclipse either by modifying the class and saving it, or by doing a Project > Clean....

↑Back to top

The most probable cause to this error is the R class not being found by Eclipse, although AndroidAnnotations was able to access it at compile time. There seems to be a bug with the latest releases of the ADT plugin (especially on MacOS), related to the generation of the R class.

To fix the error, try to do the following in Eclipse: Project > Clean... and clean your Android project. Ensure that Build automatically is activated in Eclipse. Then, right click on your project, and hit Refresh.

If you still have the error, there is a kind of magical trick which triggers a build without using Project > Clean... that usually works:

• Right click on the project, go to Properties > Java Compiler > Annotation Processing
• Change the name of the Generated source directory from .apt_generated to something else.
• Click on Apply, accept the rebuild
• Then change the value back to .apt_generated, and Apply / rebuild again.

If it still does not work (doh!), please consider creating an issue.

↑Back to top

I have followed the docs to configure Eclipse but nothing gets generated.

Be careful that you have used the good jar for annotation processing: androidannotations-X.X.X.jar, not androidannotations-api-X.X.X.jar.

See old issue #89 for details. If that doesn't solve your issue, please create one.

↑Back to top

AndroidAnnotations is a Java annotation processor, and Scala does not seem to support the Java annotation processing tool. However, AndroidAnnotations may still be used in the Java source code of a Scala mixed-source project. See this [question](http://stackoverflow.com/questions/7454018/using-androidannotations-with-scala-and-gradle Stack Overflow) for more details.

↑Back to top

In Eclipse, when I open my project or when a do a "Project > Clean", I always get a "The import XX_ cannot be resolved" error in some classes.

This is a known Eclipse bug, and we hope it will be fixed at some point. It has also been reported in AndroidAnnotations issues (#257).

The source of the problem lies in the import of the generated class. An error shows up if you use annotations with imported constants in the same class. E.g. @EActivity(R.layout.someLayout) or @ViewById(R.id.someId).

The current way to avoid this bug is to find a way to remove the import. Let's say we have this :

// ...
import com.company.MyPref_;

@EBean
public class MyBean {
  @ViewById(R.id.someId)
  View someView;

  @SharedPref
  MyPref_ myPref;
}

You'll get a compile time error on import com.company.MyPref_;.

You can fix it by :

• Importing the whole package: import com.company.*;
• Using a fully qualified name : @SharedPref com.company.MyPref_ myPref;
• Having MyBean and MyPref_ in the same package.

↑Back to top

In Eclipse if you add AspectJ to your Android project, it may change a builder in the project configuration.

As explained in issue #507, please check your .project file in the project's root folder and check the list of builders. Replace the build command org.eclipse.ajdt.core.ajbuilder to org.eclipse.jdt.core.javabuilder and remove the nature org.eclipse.ajdt.ui.ajnature. Refresh your project and it should work.

↑Back to top

Since ADT 22, there are some important changes like a new "Android Private Librairies" in the build path which is unchecked by default. So AA-API appeared to be missing. Just check this case and everything should works. See issue #592 for more details.

↑Back to top

This is a known issue of Dalvik due to the way it manage multiple interfaces inheritance. An issue has been opened about this. You may have a class which implements too many interfaces. As said in the issue #903, AA 3.0+ add two extra interfaces on the generated class this bug may be thrown with no visible reason because of this. Sadly, we can't do much about this as we need theses extra interfaces to properly handle layout injection.

↑Back to top

The latest Android Studio Beta solves this error, please update your IDE.

↑Back to top