Android "com.adobe.fre.FREContext.getResourceId(String var1)" doesn't work using Android Gradle plug-in

[pol2095]

Hello,

on Android ANE com.adobe.fre.FREContext.getResourceId(String var1) work correctly using <BuildLegacyAPK>true</BuildLegacyAPK>
but not using Android Gradle plug-in ?

Thanks

[pol2095]

Any news about Android FREContext getResourceId() crash app using the new Android Gradle plug-in ?

I founded a workaround in Java but it's strange that the native method doesn't work ?

[ajwfrost]

Hi

We've just been looking at this .. we're not able to get it to crash though? If you have it actually crashing (rather than just throwing an exception within that call) please let us know, I'll send you a link to get at your APK file if that's a viable option?

With getResourceId, you can pass in a resource name and should either get an integer code back, or it will throw an exception, of type android.content.res.Resources.NotFoundException

But looking at the implementation when building with Gradle:

• If you just have a 'res' subfolder when creation your ANE, and then try to get the resource ID from a string (per the instructions for AIR versions before 4.0), it doesn't work - it looks like we don't actually merge in the resources that are found there. I'll double-check against the original mechanism as this seems to be an omission.
• If you use the -platformoptions mechanism from AIR 4.0 onwards, with a packagedResources element set up for your ANE, then the Gradle project generation will add a package and put the resources into it. But it looks like it creates the package using the Extension ID rather than the packageName value... so e.g. if you had a string resource called "testing" within an ANE called com.myane.test, you could get at this via com.myane.test.R.string.testing (i.e. the direct resource value) - and assuming your ANE name is the same as the namespace for your Java classes, it may then just work..

But it looks like this could do with some tweaks/improvements so that it works a little better with the older mechanism.

Adding @marchbold for input here, but I think most of the Distriqt ANEs now use the alternative approach for resources where they're just included via the extdir option? It would be good if we could avoid breaking things in an attempt to make it work again.. so if you're both able to clarify how you package up resources within ANEs, and how you expect it to work, we can try to improve this!

thanks

[pol2095]

com.myane.test.R.string.testing works for me, thanks.

[marchbold]

@ajwfrost Are you certain about that? I feel several of our extensions wouldn't work if you didn't respect the packageName in a packagedResource and applied the extension ID instead particularly around dependency libraries we package into extensions that use the normal packagename.R resource structure? eg the platform xml for our push notifications extension has:

<platform xmlns="http://ns.adobe.com/air/extension/50.2">
...
	<packagedResources>
		<packagedResource>
			<packageName>com.distriqt.extension.pushnotifications</packageName> 
		    <folderName>pushnotifications-res</folderName> 
		</packagedResource>
	</packagedResources>
...

The package name here com.distriqt.extension.pushnotifications is very different from the extension id com.distriqt.PushNotifications and our default notification icons potentially wouldn't work.

I've just done a test build with this extension and can see the correct package name in the AndroidStudioProject resource module manifest so I think this is working correctly:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.distriqt.extension.pushnotifications" >
</manifest>

---

Our approach to resources over the years has been complicated. We use a combination of many styles of accessing resources, built over many years of struggling with the AIR for Android resource system. We have a custom resource approach for critical resources that searches all the available resources under all available package names for the specific resource, which is still in use today in some of our extensions. This uses reflection and the R. functionality. This approach was required in earlier AIR versions, as we've always had unreliable and restrictive results with the getResourceId() functionality and I don't believe we use it at all now. (so if there is an error with it, it's unlikely we would have reported it).

Now though we find the approach of packageName.R... works consistently with current AIR releases as long as you correctly specify the package name in the platform xml.

For resources that a developer needs to supply (eg notification icons) we ask them to use the extdir approach (previously we used a custom resources extension that developers could use to package up their resources for use by our extensions).

---

So there may definitely be an issue with the getResourceId() functionality however I'd suggest it's functionality that's no longer needed. When AIR used to combine resources into the main application package with AIR it was a solution to access these, however as we can now easily specify a package name and use regular Android resource system to access them I feel this functionality can be deprecated.