Android 4 bug with "resToastText"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. annotation "@ReportsCrashes(formKey = "", mode = 
ReportingInteractionMode.TOAST, resToastText = R.string.unexpected_error)" does 
not compile with android 4: resource ids are not constants anymore but 
resToastText asks for a constant...

What is the expected output? What do you see instead?
Build should work

What version of the product are you using? On what operating system?
4.2.3 on Android 4 (API 14) developing on an iMAC

Original issue reported on code.google.com by nicona...@gmail.com on 19 Oct 2011 at 10:21

[GoogleCodeExporter]

Sorry, I forgot to add that it's when we point to a resource from a library. 
only these ones are not constants anymore...

Original comment by nicona...@gmail.com on 19 Oct 2011 at 12:25

[GoogleCodeExporter]

I'm afraid we can't do much about that. The constant limitation is a Java 
language limitation on Annotations parameters.
I'll have a look at that but I think you should consider implementing ACRA 
parameters in your main project and not in a library project.

Original comment by kevin.gaudin on 19 Oct 2011 at 1:10

[GoogleCodeExporter]

Thanks for the answer.
I'll follow your advice or I'll use the Silent mode and display the Toast from 
my custom ReportSender...

Original comment by nicona...@gmail.com on 19 Oct 2011 at 1:31

[GoogleCodeExporter]

He might be a solution for you guys : provide alternative annotation parameters 
that will use the qualified name of the ressources, as string. For instance, 
instead of :

@ReportsCrashes(formKey = "", mode = ReportingInteractionMode.TOAST, 
resToastText = R.string.unexpected_error)

You would use :

@ReportsCrashes(formKey = "", mode = ReportingInteractionMode.TOAST, 
resToastTextStr = "com.mycompany.R.string.unexpected_error")

Then it's only a matter of making a reflection call to get the value of the 
resource id.

Original comment by py.ricau on 20 Oct 2011 at 6:53

[GoogleCodeExporter]

Thanks for the idea Pierre-Yves. This is a solution. But I would prefer not 
adding  complexity to 
the API without a real demand for the feature. 

If more people complain, this will be the way to go. 

Original comment by kevin.gaudin on 20 Oct 2011 at 7:08

[GoogleCodeExporter]

And kevin, thanks for sharing this ;-) . I added a related issue in 
AndroidAnnotations 
(http://code.google.com/p/androidannotations/issues/detail?id=115), and a post 
on the RoboGuice mailing list: 
http://groups.google.com/group/roboguice/browse_thread/thread/aaf63f1a6657b5d8

Original comment by py.ricau on 20 Oct 2011 at 7:15

[GoogleCodeExporter]

Wouldn't it be possible to provide setters for all the annotation fields so one 
could configure ACRA in the Application.onCreate method?

I would think that sharing the Application class is something that happens all 
the time in bigger projects, where different end products (e.g. free/paid) or 
different customizations are available.

Original comment by michi.zo...@gmail.com on 20 Oct 2011 at 11:57

[GoogleCodeExporter]

I'm experiencing this issue too. It is a fairly major one for those of us who 
are using a library project to compile multiple APKs. I agree with the previous 
comment. Wouldn't programatic setters be easy enough to implement?

Original comment by michael....@gmail.com on 20 Oct 2011 at 4:14

[GoogleCodeExporter]

Please add support for library projects, its worth it for those of us who use 
them.

Original comment by chris.sm...@gmail.com on 24 Oct 2011 at 3:55

[GoogleCodeExporter]

I hereby formerly complain :). A programmatic API for setting all preferences 
is the real solution. 

Original comment by nikolay....@gmail.com on 24 Oct 2011 at 8:29

[GoogleCodeExporter]

Well, it looks like this issue will require a new ACRA version... I'll try to 
find some time to release something soon. And this will be on top of a new 
"code cleaned" version commited by William Ferguson during the summer, so it 
will be a beta. I don't have time for branches and we need to ensure that the 
new version from William is good (he has been using it with success for months) 
so you will be the happy testers :)

Kevin

Original comment by kevin.gaudin on 24 Oct 2011 at 8:36

• Changed state: Accepted

[GoogleCodeExporter]

There's a snapshot build here:
http://code.google.com/p/acra/source/browse/repository/snapshots/org/acra/acra/4
.3.0-SNAPSHOT/acra-4.3.0-20111101.153002-1.jar

I have added a setter to org.acra.ACRA for each res* annotation setting.

Would you mind testing this ? I'm having troubles setting up a working 
environment to test it with a real Android Library Project.

Kevin

Original comment by kevin.gaudin on 1 Nov 2011 at 10:50

[GoogleCodeExporter]

I'll switch my projects tomorrow to the snapshot build and let you know if 
there are any problems.

Thanks,
Michael

Original comment by michi.zo...@gmail.com on 1 Nov 2011 at 11:05

[GoogleCodeExporter]

Got the following exception:

W/ACRA    (15322): org.acra.ACRAConfigurationException: NOTIFICATION mode: you 
have to define at least the resNotifTickerText, resNotifTitle, resNotifText, 
resDialogText parameters in your application @ReportsCrashes() annotation.
W/ACRA    (15322):      at org.acra.ACRA.checkCrashResources(ACRA.java:241)
W/ACRA    (15322):      at org.acra.ACRA.init(ACRA.java:125)
W/ACRA    (15322):      at 
at.co.hlw.remoteclient.RCApplication.onCreate(RCApplication.java:46)
W/ACRA    (15322):      at 
android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:969)
W/ACRA    (15322):      at 
android.app.ActivityThread.handleBindApplication(ActivityThread.java:4244)
W/ACRA    (15322):      at 
android.app.ActivityThread.access$3000(ActivityThread.java:125)
W/ACRA    (15322):      at 
android.app.ActivityThread$H.handleMessage(ActivityThread.java:2071)
W/ACRA    (15322):      at android.os.Handler.dispatchMessage(Handler.java:99)
W/ACRA    (15322):      at android.os.Looper.loop(Looper.java:123)
W/ACRA    (15322):      at 
android.app.ActivityThread.main(ActivityThread.java:4627)
W/ACRA    (15322):      at java.lang.reflect.Method.invokeNative(Native Method)
W/ACRA    (15322):      at java.lang.reflect.Method.invoke(Method.java:521)
W/ACRA    (15322):      at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:871)
W/ACRA    (15322):      at 
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:629)
W/ACRA    (15322):      at dalvik.system.NativeStart.main(Native Method)

I looked at the source and imo you're not using getConfig() to get the 
ReportsCrashes object that actually uses the RES_* fields.

Is there somewhere documentation on how to build an ACRA jar so i can try to 
fix it by myself?

Original comment by michi.zo...@gmail.com on 2 Nov 2011 at 12:34

[GoogleCodeExporter]

Sorry about that, I've been going way too fast releasing this snapshot.

Here is a new one:
http://acra.googlecode.com/svn/repository/snapshots/org/acra/acra/4.3.0-SNAPSHOT
/acra-4.3.0-20111102.232440-2.jar

You now have to set your resource settings with 
org.acra.ACRAConfiguration.setRes*() methods prior to calling 
ACRA.init(Application).

This might lead in a few days to a fully dynamic annotation configuration 
overloading system as requested by some users in Issue 71.

Kevin

Original comment by kevin.gaudin on 2 Nov 2011 at 11:31

[GoogleCodeExporter]

That fixes the previous issues, but there is a new one.

Getting a "java.lang.IllegalAccessException: access to class not allowed" when 
ACRA tries to open the CrashReportDialog. Imo the problem is that the class is 
package-scoped and not public.

Original comment by michi.zo...@gmail.com on 3 Nov 2011 at 9:39

[GoogleCodeExporter]

OK, I warned you that it was on a new beta codebase :-)

Here's your daily SNAPSHOT with the IllegalAccessException fixed:
http://acra.googlecode.com/svn/repository/snapshots/org/acra/acra/4.3.0-SNAPSHOT
/acra-4.3.0-20111103.232318-3.jar

Thanks a lot for your help !

Original comment by kevin.gaudin on 3 Nov 2011 at 11:31

[GoogleCodeExporter]

The latest jar works for me. Did a few test runs and couldn't find any problem.

Original comment by michi.zo...@gmail.com on 7 Nov 2011 at 1:34

[GoogleCodeExporter]

Great, thanks for testing!

Original comment by kevin.gaudin on 7 Nov 2011 at 2:03

[GoogleCodeExporter]

No problem, thanks for resolving the issue so fast. I've already switched all 
my projects to the SNAPSHOT jar. If I find any other issues i'll let you know.

Original comment by michi.zo...@gmail.com on 7 Nov 2011 at 4:59

[GoogleCodeExporter]

Original comment by kevin.gaudin on 25 Nov 2011 at 11:40

• Changed state: Fixed
• Added labels: Milestone-Release4.3, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by kevin.gaudin on 7 Sep 2012 at 9:31

• Changed state: Verified

[GoogleCodeExporter]

Can anyone provide a real example that works?  The standard documentation is 
quite vague:  One failed approach:

        ACRA.getNewDefaultConfig(null).setResToastText(R.string.crash_toast_text);
        ACRA.setConfig(ACRAConfiguration);

        ACRA.init(this);

When an application with ACRA is put into a library, there is no related 
application, so I used null, which doesn't feel right. Not clear what 
"APPLICATION" is supposed to be.

On the second line, ACRAConfiguration does not exist, but any attempt to assign 
something to the first line has also failed. For example:

        ACRAConfiguration config = ACRA.getNewDefaultConfig(null).setResToastText(R.string.crash_toast_text);

Gives you a "Type mismatch: cannot convert from void to ACRAConfiguration" 
error.

It would also be great if the documentation would address how to do this (at 
"https://code.google.com/p/acra/wiki/AdvancedUsage#Dynamic_Configuration").

Original comment by frank...@gmail.com on 22 Oct 2012 at 10:22