Android Support Library was removed from recent Android SDKs #1745
Comments
kchodorow
added
type: bug
P2
…. 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
…s in <sdk>/extras for sdk in android_sdk_repository. Addresses #1745. -- MOS_MIGRATED_REVID=135679008
|
As of 2fcf0e4, if your WORKSPACE contains android_sdk_repository, the contents of your Android SDK You can put these rules in the deps of your android_library and android_binary as such: The label format is |
|
Thanks so much for working on this! I have tried it in my project and am experiencing an error: ERROR: /usr/local/google/home/zachh/.cache/bazel/_bazel_zachh/8b6a25785bcaef089bf3e18c1286d461/external/androidsdk/com.android.support/BUILD:2982:1: Processing Android resources for @androidsdk//com.android.support:support-compat-24.2.1 failed: linux-sandbox failed: error executing command /usr/local/google/home/zachh/.cache/bazel/_bazel_zachh/8b6a25785bcaef089bf3e18c1286d461/execroot/tmp1FQaA6/_bin/linux-sandbox ... (remaining 27 argument(s) skipped). I haven't tried creating a minimal repro case but can try to do that if necessary, thanks! |
|
Hi @zvh, sorry about the error. That is a bug that I am aware of with the Bazel sandbox that I forgot to mention here. The workaround is to use I will file another GitHub issue that tracks this. The problem is as follows: aar_import is one of the first rules to use a new Bazel feature called TreeArtifacts. TreeArtifacts represent directories that are inputs and outputs of actions. The Bazel sandbox is responsible for ensuring that only the appropriate input files are accessible to actions. However, if the input artifact to an action is an empty tree artifact, the sandbox does not create the empty directory which utlimately causes the "Processing Android resources error" that you've encountered. Please let me know if |
|
I've filed #1928 to track this issue. |
|
Thank you @aj-michael, that flag seems to get me past that error. However, I am now getting a different compilation error: ERROR: /tmp/tmp1FQaA6/java/com/android/dialer/common/BUILD:7:1: Java compilation in rule '//java/com/android/dialer/common:common' failed: Worker process sent response with exit code: 1. If it's useful, when I was looking into extracting the .aar files myself, I think I found that this class was part of the internal_impl-24.2.0.jar in the libs directory (of support-compat) |
|
Ah, unfortunately aar_import currently only gets classes.jar, AndroidManifest.xml and res/* from the AAR. I am working on adding support for jni/* and libs/*, but that is not available yet. As you mentioned, support-compat uses an internal jar for ActivityCompatApi23. |
|
Of course, if you want to get it working, you can extract that jar, and put a java_import of it in the deps of your android_binary. |
|
I should note, unfortunately this change was rolled back due to #1927. I am working on rolling it forward soon. |
*** Reason for rollback *** Rollforward with fixes for android_integration_test.sh *** Original change description *** Automated [] rollback of commit 2fcf0e4. *** Reason for rollback *** Breaks android_integration_test, see #1927 *** Original change description *** Generate aar_import and java_import rules for local maven repositories in <sdk>/extras for sdk in android_sdk_repository. Addresses #1745. -- MOS_MIGRATED_REVID=137407118
|
Oops, I meant to update this thread when the commit went through. The Android Support Libraries should be good to go as described earlier in this bug. Note however, that |
In December 2015, these JARs needed for these targets were removed from all subsequent Android SDK releases. They were replaced by a two local maven repositories: <android sdk>/extras/android/m2repository and <android sdk>/extras/google/m2repository. Furthermore, the new dependencies are AARs and the Maven repositories are sem-ver'd so the developer needs to select the version of the library to use. In 2fcf0e I added support for android_sdk_repository to parse these local maven repositories and generate java_import and aar_import rules along with their dependencies. Since these "extras" do not ship with the SDK by default and are not versioned with the build-tools, you cannot currently download the old JAR versions. As such, anyone who has updated their Android SDK in the last year should not have been able to download the old JARs. See #1745 for the tracking issue and information on migrating from the old targets to the new ones. RELNOTES: Top level @AndroidSDK support library targets have been replaced by @androidsdk//<group id>:<artifact id>-<version> for Android SDK Support and Google Play Services libraries. -- MOS_MIGRATED_REVID=140562616
|
Ok, marking this as fixed.
|
|
@aj-michael, I just tried syncing to head and removing --spawn_strategy but I get: |
|
Ok, the actual problem is that 3f008a0 unconditionally mounts TreeArtifacts into the Bazel sandbox as directories. However, if the TreeArtifact is not empty, the contained Artifacts are symlinked first, resulting in a ERR_DIRECTORY_NOT_EMPTY when we try to symlink the TreeArtifact directory. I have a fix for this. |
ahumesky
added
P1
|
Ok, b5f480c should have fixed this once and for all. |
|
Hi I still facing this not find support package issue. My bazel is 0.4.4 |
|
Hi @coroner4817 , can you please open a separate github issue containing the contents of your BUILD file and WORKSPACE file and that stack trace? |
|
Hi @aj-michael I tried new way of doing this but I still get an error : my workspace: my BUILD I'm new to bazel so maybe I'm doing something wrong. |
|
Hey @charafau, that definitely looks like the same error that other people reported here. What is the output of |
|
I'm using OSX |
|
Ah, I am forgetful today. This was reported in a separate issue (see #2597). It was a bug in the OS X implementation. I checked in a fix a month ago in acdd43b but unfortunately it just missed the cut-off for bazel 0.4.5. The fix will be in the next Bazel release. If you want to get unblocked, you can build Bazel from head following these instructions: |
|
Thank you for answer. I tried your solution but still got error: |
|
@apelle03 or @corbinrsmith-work, do either of you have a guess as to why the BusyBox is failing to validate? |
|
Looks like appcompat is missing from the library -- it should be a dependency on the library not just the binary. And you don't need to duplicate the resources on both the binary and library. Try this: |
|
Thank you for answer and sorry for late reply. After applying that changes I got this: error I get: I can upload this project to github if it helps tracking bugs. |
|
@charafau , can you open a separate GitHub issue for this? Also, uploading the project to GitHub would definitely help us help you :) |
|
(Also, as a quick note, the error that you just posted is same as the original error, which appears to because you forgot to use the new bazel binary). |
|
@aj-michael Sorry for no contact, got busy lately. I checkout new bazel version from git, recompiled and got working project: https://github.com/charafau/BazelTest One thing I would like to suggest is, if I change I also dont know why it takes ~11 seconds to reinstall this simple app with Anyway, thank you for helping me with my issue! |
|
@charafau, thanks for the feedback. Regarding the lack of sources, that is just glob working as intended. It could be the case that all your code comes from another library that you depend on, so this is not an error. You do not need to use glob. In fact, you could use And then the build would fail if either of those files did not exist. If you have an idea for a way to improve this, please open a separate github issue. Please open a separate GitHub issue about mobile-install and we can discuss it there. |
Android Support Library was removed from recent Android SDKs [1] in favor of Android Support Repository, a local maven repository of AARs.
Because of this, the
appcompat_{v4,v7,v7_import,v13}targets in https://github.com/bazelbuild/bazel/blob/master/tools/android/android_sdk_repository_template.bzl are broken.Bazel does not yet support importing AARs (see #564) so the only current workaround for users is to get the necessary AARs from their Android SDK, unzip them into their component JARs and resources and wrap these in
java_imports andandroid_libraries.[1] I can't find a changelog that shows how recent.
The text was updated successfully, but these errors were encountered: