Trying again to get aapt2 working for Android projects… On a new project, when I enable aapt2 and build, I get errors about R.java being unknown. When I compare the intermediate outputs from aapt and aapt2 I see that it is in a different folder. I’m not sure if this is an aapt/aapt2 difference or if EBuild is providing a different path, but aapt it placing it directly in the java folder and aapt2 is placing it in a package hierarchy within the java folder.
After looking at the code, EBuild just passes the “java” folder as the --java argument for aapt or aapt2, so aapt2 must create a package folder hierarchy whereas aapt did not. The problem is that R.java is not discovered when it is in aapt2’s package hierarchy structure. I’m not sure whether that is an EBuild issue, a compiler issue, or a Fire/Water issue though.
Can I get a testcase for this,. though? a new Android project compiles clean for me with aapt2, including the line ContentView := R.layout.main; which depends on R.java. The IDE also sees the generated file just fine:
I am able to build & run a new project with aapt2 now, but I get 20 errors building when including appcompat library. They are coming from aapt2, but again this works fine in Android Studio so it looks like EBuild must be calling aapt2 incorrectly
Is there any way I can help speed this up? Testing? Looking into EBuild code myself? Manually calling aapt2? I haven’t been able to build my project for a week and have a huge deadline to release end of next week, and it looks like I have to move to aapt2 to get my project building (due to the other unfixed bugs I’ve been reporting).
I can repro the issue, but TBH I’m out of ideas what to look at. aapt is a black box to me; we pass in all the refs, ours comes the result. Maybe you can find out how Android Studio/gradle calls it, and see if it passes any other parameters that might be relevant?
Finally able to build using the right configuration of libraries and Oxygene compiler versions. So this is not a critical issue for me now, although EBuild really does need to support aapt2 if Google is now releasing libraries that require it.
That said, I found this aapt2 doc article last night that lists behavior changes from aapt to aapt2. One of the changes says that trying to use a resource name to indicate the type (e.g. name="attr/my_attr" rather than type="attr" name="my_attr") will cause the following error:
Error: style attribute 'attr/attr/my_attr (aka my.package:attr/attr/my_attr)'
This looks very similar to the errors that I’m getting from appcompat with aapt2. I also found that there is a --legacy flag on the aapt2 compile command that causes these behavior changes from aapt to aapt2 to register as warning rather than errors. When I tried manually running aapt2 compile & link with this flag I still got the errors, but it may be worth trying it in EBuild as I may have been calling it incorrectly.
What changed/what did you have to change? with aapt or aapt2?
Indeed it does. question is who’s error is this, if aapt2 flags it? the aapt2 user’s (ie us/ebuild for using it wrong) or the library creator (for having bad xml)? It sounds like the latter, ie the error is valid, and the lib needs to be updated for aapt2?
I’ll add --legacy to EBuild now;’ if that fixes the issue, good, and we can review whether to keep the switch or add an option for it, later?
adding that switch gives me more errors, not fewer: