I'm using AndroidAnnotations in an Android Studio gradle project. I currently get error output from AA during compilation that says:
cannot find symbol class MyActivity_
The error output does not prevent building the application - its not really a compile error because the class is there, it seems that it is just an unfortunate timing issue with the compilation process.
Is there anything I can do to avoid these false-positive errors from AA? When there are "fake" errors shown every time I compile, its very easy to miss the real errors.
I had same error. To solve it I have revert my last changes and it has worked again.
I think it was either wrong optimized import(you must import generated classes eg. xxx_) or I injected layout by id what was not existed in the layout xml
Update
I figured it. My problem was what I had use private mofidier instead of proteced in
#ViewById(R.id.list)
private ListView list;
Try to see if you missed to fix some errors in the class MainActivity or in someone of his Bean member that you have annoted.
The problem doesn't have to be in MainActivty, but it is probably because of a private modifier which is used with Android Anotations (in injection, method declaration etc) somewhere in your code
Related
I have Unable to create application im.app.android.core.AppDemoApplication: e3.b: com.pushserver.android.huaweiPushClient cant cast com.myApp.android.push_lib.huawei.HcmPushClient to PushClient error
What proguard rule should I add? I have tried -keep class com.myApp.android.push_lib.** { *; } but after that I just see the blank screen - no crash, just stuck when trying to start.
Not really an answer, but too long for a comment. I'll update this answer in case we make progress.
1. What is the "normal bug"?
can't cast com.myApp.android.push_lib.huawei.HcmPushClient to PushClient
This means that somewhere in your code you are assigning/passing an instance of HcmPushClient to something that is expecting it to be a PushClient. I would assume that PushClient is some class that you defined in your project, but is does not extend from HcmPushClient. Try to find this piece of code and fix it or add it here to your question.
2. What does ProGuard have to do with this?
Actually, I think not much. If ProGuard would create this error, the message would look more like
can't cast com.myApp.android.push_lib.a.b to c
But since all class names in the error message are the original ones, it does not seem like ProGuard is making issues here. BUT: You can still decypher the message a little bit, because this part is obfuscated:
Unable to create application im.app.android.core.AppDemoApplication: e3.b:
e3.b refers to a class that was obfuscated by ProGuard. To find out what class it is, you can check the file /build/outputs/mapping/release/mapping.txt in your project folder. This is a simple text file that stores the information what class name was renamed to what obfuscated name. In this file search for -> e3 to find the class that was renamed to e3. Somewhere close to this line, you should also be able to find out what exactly e3.b is. Could be a method, could also be a member variable or an inner class.
I hope these two points will bring you closer to make the app run.
I want to define my class on frameworks/base/core, and use it as common library.
So what I did was adding a java class file 'MyTime.java' on frameworks/base/core/java/android/text/format folder. However, when I try to import the class, error 'cannot find symbol' occurred.
The code of MyTime class is like below.
package android.text.format;
...
public class MyTime {
...
}
I can't use this class, and tried for days, but still have not found the solution.
Could anyone help me?
This sounds like a bad idea, you are creating a fork of the Android API.
Did you run
make update-api
make sdk
to update frameworks/base/api/*.txt and rebuild framework.jar? If not, it will not be visible to users.
Repeating 1. Please add to a separate library, not the base framework.
I have tried AndroidStudio's code coverage feature and I have met a strange issue:
It is marks the tested class's name as 'not covered' code.
How is that possible? Is that a bug?
Picture here:
As you can see it has one method with 4 lines and each one of them is covered. So why is the red line at the class's name?
You are using a static method, so the class itself is never created as an object, therefore never testing that ability.
I tried the lombok #UtilityClass, it helped to ignore the class name and code coverage was improved to be 100%.
Since also a class with a static function has a default no-argument constructor, your code coverage tool will complain. A good way to solve this, is by adding a private constructor.
private EmailValidator() {
}
I am trying to use the library DBFlow in Android. I have used it before and in the older version (2.2.1) it used a $Table.field. Now it seems to have another format where we reference a new class by "_Table".
Example:
int taxBracketCount = SQLite.select(count(Employee_Table.name))
.from(Employee.class)
.where(Employee_Table.salary.lessThan(150000))
.and(Employee_Table.salary.greaterThan(80000))
.count();
Where and when are these "_Table" classes created? How do I access them?
(Even if I wanted to use and older version, my newly created studio project do not create the $ files either. Some explaination of this, or both, would be nice)
You need to run a successful build for the files to be generated. Make sure your code can compile, so remove any references to the "_Table" classes and run your project first and then you should be able to access them.
I got weird errors recently as below, said it couldn't find those "$Table" classes, but actually they had been built and in there.
I commented and uncommented every new java files. And eventually I found that's because there is no "#PrimaryKey" in one model class of DBFlow.
So, you have to define the bloody "#PrimaryKey" for your DBFlow model classes( and don't forget to extends BaseModel as well).
PS: DBFlow Version 3.0.0-beta
/Users/XXX/code_projects/###/src/main/java/com/XXXXX.java:9: error: cannot find symbol
import com.XXX.databasemodel.XXX$Table
_Table classes and their corresponding methods to communicate with the database are created when you build your project. You can build it even with these errors, and they'll be created on that moment.
If you're still facing the issue, make sure you're adding the #Table annotation on top of your class, else they won't be created.
I have faced the same problem, but the reason was an absence of the annotation
#Table(databaseName = AppDatabase.NAME)
at the top of
public class AwesomeModel extends BaseModel
#PrimaryKey(autoincrement = false)
#Column #Expose long id;
public long getId() {
return id;
}
}
class...
Ok so I was also facing similar issue -
And like someone else has also pointed out, the app needs to build to solve this. But removing all _table references first and removing them is a long task. I followed following steps -
try to rebuild the app, it will fail
Now head over to Problems tab in Android Studio
Try to identify any issues other than _table - fix that issue and build again - voila!
I recently activated ProGuard for my Eclipse Android project. After adding external libs and dynamically referenced classes to the proguard.cfg, I don't get any errors when building the apk. I get however a NoSuchMethodError when I try to start the installed app.
I narrowed it down to a specific method called in the onCreate method of the main activity. To simplify things, here's what the class and method look like (I left out a lot of code, but I think this should illustrate it):
public class TestMain extends TabActivity implements OnSharedPreferenceChangeListener{
...
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
testMethod();
}
}
testMethod() is defined as follows:
private void testMethod() {
int charsLeft = maxPostMessageLength - someEditText.length();
...
}
When I remove the "someEditText.length()" part, the app starts. So, the way I see it, the method that can't be found is the EditText.length() method. Strangely, though, the app also starts when I remove "someEditText.length()" from the testMethod and put it directly into the onCreate method:
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
test = someEditText.length();
testMethod();
}
Does anyone know how I can get rid of this error and why I can call someEditText.length() directly in the onCreate method but not in a method called by the onCreate method?
Without using Proguard the app works fine, of course.
Edit:
I tried the -dontshrink, -dontobfuscate and the -dontoptimzie options in the proguard.cfg. With -dontoptimize the app starts without errors.
Still, it would be interesting what exactly causes this specific error.
The Proguard documentation proudly states: "The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes".
Well, I gave up with the 'shrinking' part of it after getting runtime errors like you describe. I added the line
-dontshrink
to the proguard.cfg
You can see which routines have been removed from your code by inspecting the file usage.txt.
I'm happy to say that in my projects it's always missing, meaning that the code is obfuscated but nothing has been removed. I don't get any runtime errors now.
I accidentally stumbled upon a possible solution. Well, it totally works in my case, so this IS a solution to the original problem:
Today, I implemented some code with #Override annotations, which didn't work, at first. Luckily, someone else already had the same problem and an easy Eclipse-related solution:
'Must Override a Superclass Method' Errors after importing a project into Eclipse
Now, I thought, well, if I was always using Java level 1.5 before, why not try ProGuard again, without the -dontoptimize option, now that I set it to 1.6. Can't hurt...
And what can I say, now the app starts and I don't get the strange error when EditText.length() is called in a method.
The optimizer may remove the method invocation and the method if it comes to the conclusion that the method doesn't have any side-effects. It should never create inconsistent code though, and I'm not aware of a problem like this. You should check if it persists with the latest version of ProGuard. Otherwise, you should file a bug report on the ProGuard site, preferably with a small example that illustrates the problem.
I had a similar problem to the OP and it ended up being a proguard config option I set -allowaccessmodification, removing this solved the issue.