-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Support .aar files #564
Comments
Related: #561 |
This issue should be raised in priority given that the new Google Play Services ships exclusively in AAR format. It no longer ships in a buildable form. Therefore you can't really build an Android application with bazel that utilizes Play Services. What we really need is support for external AAR files, like new_local_repository where you can define all the aar Google Play Service files, and have dependencies on them from your android_library/binary |
@ahumesky This is definitely a P1 now, is this beeing working on? |
Was there some announcement somewhere about Google Play Services no longer updating google-play-services.jar (/extras/google/google_play_services/libproject/google-play-services_lib/libs/google-play-services.jar)? Importing AARs is blocked on the unpredictable action outputs work, which is being worked on, but it's not in a stable state right now. We could possibly come up with a workaround where the android_sdk_repository rule inspects the pom files and aar files in the android sdk's local maven repository where the google play services are, and generates a build file with genrules that unzips the aars and creates the other rules (java_impor, android_library, etc). It would be a pretty big hack. I'm not sure when we could find the cycles for that, it would be at least a few weeks. |
I needed this for personal use, so here's your hack, which I whipped up this morning. How I've run it: $ cd <WORKSPACE>/android Then depend on something like //android/com.android.support:appcompat-v7. Lather, rinse, repeat for other m2repository packages (eg. com.google.firebase, com.google.android.gms, etc). You'll need to modify the script to point to your android-sdk-linux directory. No guarantee of function on any platform, but it works nicely for me so far. |
Turns out it needed some hacking to work on MacOS, and I wasn't dealing with implementation jars, and was getting the custom_packages wrong, but that is now accounted for. Again definitely still a hack, and no guarantees it'll do anything useful for anyone else. |
@ahumesky : ping can we resolve this in the following week? It looks like we need to drop it from 0.4 but that seems serious enough for not dropping it. It might need retriage. |
The underlying mechanism (unpredictable action outputs) isn't ready yet, so it's pretty unlikely to be resolved next week. We could pursue the hacks mentioned above, but we even for that we won't have time to work on this for a few weeks at least. |
Dropping to milestones 0.5 :( [sadpanda] |
Just saying, the script I posted is working great for me. I'd be happier with a real, baked in solution, but if that is a whole extra major milestone away, you might want to include some hints on how to work around it in the mean time. |
Just to confirm what has already been said about google-play-services being .aar only, with the current Google Play Services (version 32) installed:
|
…. Currently only uses AndroidManifest.xml, classes.jar and res/ from AARs. This is sufficient for many of the AARs of Google Play Services and Android Support Repository. The next step will be for AndroidSdkRepositoryRule to scan the SDK and generate aar_import rules for the AARs within. The rule is not yet documented because it is not intended for end users to use it yet. We should probably support more of the features of AARs before that time. See http://tools.android.com/tech-docs/new-build-system/aar-format for all of the files that can be included in AARs. Also note that R.txt from the AAR is intentionally ignored and regenerated based on the contents of res/. This is more correct, because the R.txt inside of an AAR can contain ids for dependencies of the AAR that are not included in res/. See #564 for discussion of supporting AARs and #1745 for motivation to get it done soon. -- MOS_MIGRATED_REVID=133127933
@aj-michael can u kindly give me an example how to use aar_import? I know it's not documented on purpose and people aren't supposed to be using it yet, but I don't mind if it breaks in the future as long as it can unblock us now. |
Hi @sbilkoloft, sorry for the delay. If you build bazel from HEAD, you can use the rule as
This will give your android_library or android_binary access to the classes and resources from the AAR. If you have any questions or feedback, please let me know. |
Hi @aj-michael, For the record, seems like the code snippet posted above doesn't work as is. Does the 'aar' field have to be a path? If so, it doesn't accept absolute paths (says it cannot start with '/'). I also tried creating a symlink to my aar file and referencing it locally. Got an error that bazel-out/.../_aar/unzipped/myaar doesn't exist. |
@aj-michael I'm getting the same error sbilkoloft is reporting. bazel-out/../_aar/ etc doesn't exist |
@sbilkoloft The 'aar' field is a path relative to the BUILD file. Think of it like how "srcs" works on android_binary. It cannot accept absolute paths because Bazel rules only have access to the files in the package. I haven't tried it with symlinks, but it's intended to be used with the AAR in your source tree. From the partial error snippet you posted, that is likely do to this bug, #1928, that occurs if the AAR does not have any resources. The workaround for now is to use the |
I closed this issue a bit too soon. b5f480c was just committed which is also required for There is one change remaining, which is to document this rule. Reopening until that is submitted. |
Probably, I am doing something wrong, but when I am trying to include aar of gvr sdk as shown in the example documentation, I get:
Instead, with android_binary( |
@merryHunter , it looks like commit b5f480c has not made it into a Bazel release yet. Bazel 0.4.3 was baselined from c645a45 which was on Dec 5, whereas b5f480c was committed on Dec 9. The fix will be in the next release, which you can track the progress of here: #2282. Alternatively, if you're eager, you can compile Bazel from head with
|
@aj-michael thank you! I thought I had checked the commit timeline, but I was mistaken. |
Can you help me see how to solve this problem?Thanks. google-ai-edge/mediapipe#1450 |
Fixes bazelbuild/bazel#564. RELNOTES: aar_import rule is now documented. -- PiperOrigin-RevId: 141843994 MOS_MIGRATED_REVID=141843994
... similarly to
java_import
, we need a way to use.aar
files in Android builds.The text was updated successfully, but these errors were encountered: