New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/mobile/cmd/gomobile: android resource identifiers are hard-coded without relevant api info #13016
Comments
@crawshaw @hyangah Writing a bare-bones class parser specific to cmd gomobile's needs would be ok I think, so that's one option. Another option is to use With that said, I just recalled an xml autocomplete plugin I had written a long a while back for android layouts. This was possible due resources in a platforms For example: As another short example, in The point is these xml resources can be used to not only auto-generate resource identifiers, but also determine during generation what valid values are. This would allow gomobile cmd to identify bad values during compile instead of finding out you have an invalid manifest when attempting to install the apk. If there's interest in this approach, I can work on a CL. |
I meant taking advantage of android.jar, not R.java (I don't know where I can find it either). I am not so sure about making the 'gomobile build' command depend on SDK yet. I think @crawshaw designed the gomobile tool to work even without android SDK present in the system. |
To be clear, I was not suggesting The platform xml in the sdk appears, at least to me, to provide the most information about how everything connects. As far as I'm aware, the conventions and format used in these xml documents hasn't changed in 4 years (if ever). Parsing files in the android.jar is another option but I didn't immediately see a method to retrieve additional connectivity for validating a manifest during |
a minor update on this while working on #13036, I have not yet confirmed but pretty sure android.jar does contain all relevant info required for resolving resource identifiers. This would be stored in the binary resource table format. If the binary xml implementation can, to a high degree, be proven to be correct, it may be much simpler to simply support the binary resource table format as well instead of creating and maintaining an independent resource resolver. |
Is the title wrong? Are you really proposing to hard-code android resource identifiers without relevant api info? The title should say what you are proposing to do, not describe a bug. Thanks. |
this has been addressed by #13109 |
The current minimum target of gomobile for android is api-9. The gomobile cmd has hard coded resource identifiers to avoid requiring the android.jar from the sdk for that platform.
Resource identifiers that can not be extracted from an api-9 android.jar, gomobile's minimum target, should be excluded. Since resource identifiers are hard-coded but contain no information wrt the api level the identifier was introduced, this may lead to invalid manifests containing resource identifiers for an api level higher than the declared target api of a developers manifest. I'm unaware of the defined behavior in such a case, but this would normally lead to a warning or error in a java app.
It's unclear if this problem has been made aware. I think an additional comment in binary_xml.go is suitable, but also a test in binary_xml_test.go that actually inspects api-9 android.jar to assure a developer has not added an identifier that should not be supported by gomobile's minimum target.
But, excluding resource identifiers higher than gomobile's minimum target is the bare minimum. Does the gomobile cmd need to intentionally exclude other identifiers that simply don't make sense for a pure go app?
For example, while deliberating for an api to allow programmatically setting an app full-screen, there's little reason to not allow a developer to declare the full screen resource theme in their android manifest file. At the same time, there's little reason to add identifiers for other various themes that can be found in api-9's android.jar. What other cases may be excluded?
@crawshaw
The text was updated successfully, but these errors were encountered: