summaryrefslogtreecommitdiff
path: root/apex/prebuilt.go
diff options
context:
space:
mode:
author Spandan Das <spandandas@google.com> 2024-08-09 17:37:25 +0000
committer Spandan Das <spandandas@google.com> 2024-08-09 22:27:47 +0000
commitdee1a7419f6d28451500a3e2a9b49440fce4c8f9 (patch)
treefce2b3b469f9b92d79666f45c168ed7ef76979a2 /apex/prebuilt.go
parent6e8bd1cc371f9e37ab81ed7ed3f3f4e129e476d4 (diff)
Add .internal modules to IDEInfo.deps of top-level java_sdk_library
libraries and apps can depend on the top-level java_sdk_library like such ``` java_library { name: "mylib", libs: ["somesdklib"], } ``` and soong will automatically resolve mylib's classpath to either the stub or impl library based on the api container these libraries are in. Since the top-level java_sdk_library has no compilation actions, code completion of `mylib` is not feasible today via `module_bp_java_deps.json`. This CL adds support for this code completion by registering the .impl (or public stubs) as a transtive dependency of `mylib`. The implication of this change is that implementation symbols of the sdk library will be surfaced during code-completion of mylib, even when mylib is in a different container. Long term, this should go away when all the library dependencies are made explicit in Android.bp files. Test: go build ./java Test: verified that symbols of android.car.builtin (a java_sdk_library) can be resolved with the repro instructions in b/356572093#comment5 Bug: 356572093 Bug: 358613520 Change-Id: Ia3887bae34bbd25b8c6346f43602835da32af84a
Diffstat (limited to 'apex/prebuilt.go')
0 files changed, 0 insertions, 0 deletions