Jiyong Park 1cc9566ee2 glob pattern is used for AIDL files under frameworks/base
This change removes the manullay curated list of AIDL files and replace
them with globs.

In addition, framework-aidl-mappings no longer sets frameworks-defaults
to its src property, but instead uses the several variables like
framework_srcs, framework_aidl_local_include_dirs, etc. to get the
same files/dirs list as the framework.

The variables will eventually be replaced with filegroups when aidl
include paths are better handled (i.e. 'path' property of all filegroups
for a module contributes to the AIDL include paths for all AIDL files in
the module).

Bug: 70046217
Test: m

Change-Id: I59728ed06d66d44bc19bcd8530042c01add5fc2b
2019-08-14 12:25:06 +09:00
..

This library (com.android.location.provider.jar) is a shared java library
containing classes required by unbundled location providers.

--- Rules of this library ---
o This library is effectively a PUBLIC API for unbundled location providers
  that may be distributed outside the system image. So it MUST BE API STABLE.
  You can add but not remove. The rules are the same as for the
  public platform SDK API.
o This library can see and instantiate internal platform classes (such as
  ProviderRequest.java), but it must not expose them in any public method
  (or by extending them via inheritance). This would break clients of the
  library because they cannot see the internal platform classes.

This library is distributed in the system image, and loaded as
a shared library. So you can change the implementation, but not
the interface. In this way it is like framework.jar.

--- Why does this library exists? ---

Unbundled location providers (such as the NetworkLocationProvider)
can not use internal platform classes.

So ideally all of these classes would be part of the public platform SDK API,
but that doesn't seem like a great idea when only applications with a special
signature can implement this API.

The compromise is this library.

It wraps internal platform classes (like ProviderRequest) with a stable
API that does not leak the internal classes.