tree 9315e510b152cea6ea75a5d35abe7b4c3cc73123
parent 356d68054d60d8bc43da10b9267447043ea301af
author Paul Duffin <paulduffin@google.com> 1589369329 +0100
committer Paul Duffin <paulduffin@google.com> 1590666604 +0100

Switch framework-tethering to use java_sdk_library

The names of the individual modules do not quite follow the pattern
that java_sdk_library uses so this temporarily sets the following:
    naming_scheme: "frameworks-modules"

That causes java_sdk_library to use a naming scheme that matches the
one used by the individual modules of this. It will be cleaned up
later.

Part of the purpose of the java_sdk_library is to hide the
implementation code and force users of the library to depend on stubs
for a well defined API. Ideally, it would allow access to the
implementation in those cases where it is safe, e.g. from within the
same APEX, or from tests for the implementation. Unfortunately, due to
limitations in the build it does not yet have enough information to
make that decision correctly which means that any code that needs to
compile against the implementation is broken which would prevent us
from converting the module to java_sdk_library.

However, the only way to provide the additional information to allow
the implementation to be correctly exposed is to convert the modules
to java_sdk_library; a cycle.

In order to break that cycle the java_sdk_library creates a special
<module>.impl target which is used directly by tests and any other code
that needs it. Once all the modules have been converted to a
java_sdk_library then we can resolve the limitations in the build and
remove the direct references to <module>.impl.

Test: m Tethering InProcessTethering checkapi
Bug: 155164730
Merged-In: If5c115f482751f9f4b5f047e9e401a18e36799ef
Change-Id: Id1c2e848430c49a2da7402244814cd084f5da77c