-
Notifications
You must be signed in to change notification settings - Fork 519
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
[manifest-attribute-codegen] Automatically generate manifest attributes from Android SDK data. #8781
base: main
Are you sure you want to change the base?
Conversation
e8f8cf7
to
d544aca
Compare
dotnet build -t:GenerateManifestAttributes | ||
``` | ||
|
||
If all found elements/attributes are accounted for in `metadata.xml`, new `*Attribute.cs` files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like some docs for the structure & semantics of metadata.xml
. It has <type/>
and <element/>
attributes; what do they mean? How do they relate? What are the semantics?
For example:
<type
name="activity"
namespace="Android.App"
outputFile="src\Xamarin.Android.NamingCustomAttributes\Android.App\ActivityAttribute.cs"
usage="AttributeTargets.Class" jniNameProvider="true"
/>
Where does activity
come from?
Or for <element/>
:
<element path="activity.exported" type="bool" />
Where does activity.exported
come from?
Is there any relation between these values and data/res/values/attrs_manifest.xml
?
|
||
Required metadata: | ||
|
||
- **name** - The name of the new element in AndroidManifest.xml, like `activity` or `application` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…like here: where do these name
values come from?
Fixes #8272
Context: #8729
Today, we do not have an established process for detecting new XML elements and attributes allowed in
AndroidManifest.xml
and surfacing them to users via our manifest attributes like[ActivityAttribute]
. This leads to users having to use manual workarounds until our attributes can be updated in a future .NET version.Additionally, when we do add new properties to these attributes, it requires manually updating multiple files by hand that must remain in sync, eg:
src/Mono.Android/Android.App/IntentFilterAttribute.cs
src/Xamarin.Android.Build.Tasks/Mono.Android/IntentFilterAttribute.Partial.cs
This commit extends our existing
manifest-attribute-codegen
script that can parse Android SDKs to determine the possible allowed values inAndroidManifest.xml
to additionally generate the code needed by bothMono.Android
andXamarin.Android.Build.Tasks
so that we can make updates easily and correctly.This process is driven by
metadata.xml
(unrelated to Java binding "metadata") which allows process customization and enforces that every availableAndroidManifest.xml
value has been accounted for. This ensures that we are making explicit decisions for every new value.This process is documented in
build-tools/manifest-attribute-codegen/README.md
.Also removed the
ANDROID_*
$(DefineConstants)
forXamarin.Android.Build.Tasks
as we no longer build separate assemblies for old Android API levels.Note this commit does not change any existing manifest attributes or the properties they expose. It merely generates what we expose today. We will determine additional properties to expose in a future commit.