Status Update
No update yet.
Comments
xa...@google.com
ja...@gmail.com
je...@google.com
sp...@google.com
Branch: androidx-master-dev
commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020
Create an interface for layouts that can be opened
Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.
Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19
M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java
xa...@google.com
how would androidGradlePluginVersion be different? when you build such an AAR you are going to use the current AGP version, and the current metadata version that AGP supports. So they're always going to be in sync anyway?
also for people building AAR with other build system, what would they put? I think the aar version is easier to document, and guarantee that the content matches a given version.
I'm also not sure what aarBuildInfo gives us. I think consumerConstraints is definitively something we want but if aarBuildInfo is what we used to build, I'm not sure how consumers would use that (and for what)
sp...@google.com
For a given AAR (produced by AGP 5.0, for example), older versions of AGP (starting with 4.1) will parse the consumerConstraints because when the AAR is produced, AGP 5.0 will know which prior versions of AGP it's not compatible with and specify that info via minAndroidGradlePluginVersion.
The aarBuildInfo might be useful for future versions of AGP (6.0, for example), if we discover in the future that AARs produced with Kotlin 1.3.71 have a particular issue, for example.
sp...@google.com
From
This is important if there are resources requiring newer versions of android.jar
xav@, can you give an example of this?
xa...@google.com
I don't have one on hand. one thing you would try is doing diff between the platform attrs.xml files and see when something gets added. In general the platform is more strict about attributes than nodes
sp...@google.com
With the pending CL, the format of this metadata file for 4.1 will look like this:
aarFormatVersion=1.0
aarMetadataVersion=1.0
minCompileSdk=28
where aarFormatVersion and aarMetadataVersion are required values, and minCompileSdk is optional.
(I edited this comment to remove the package property)
al...@google.com
Following up from discussion in chat -- can we make sure that the metadata also covers desugaring requirements? I can file a separate bug, if that's not already covered by the current set of metadata targeted to AGP-7.2.
xa...@google.com
Maybe file a separate bug. This one feels like it should be closed already. Scott?
sp...@google.com
Yes, I think it makes sense to close this bug and open new bugs for any new AarMetadata properties - I just created
Can you file a new bug for #10, Alan?
al...@google.com
Filed
Description
- version of the AAR so that down the line we can have older AGP refuse to consume AARs that rely on more recent features.
- compileSdkVersion: the version required to compile the app depending on the AAR. This is important if there are resources requiring newer versions of android.jar
format of the metadata file should be extensible to add new things (which will likely increment the version of the AAR format)