Skip to content
Commit d4a3a137 authored by Jiyong Park's avatar Jiyong Park
Browse files

"current" is implicitly added to stubs.versions

So far, when a library `libfoo` has `stubs.versions: ["10", "11"]`, then
`shared_libs: ["libfoo"]` is linked to the version 11 of the stub.

This requires the author of `libfoo` to manually update the property
whenever a new version is introduced. Otherwise, clients are not able
to use the newly added APIs because the latest stub is for an old
version.

This change eliminates the need for manual updating. "current" version
is always implicitly added to `stubs.versions`. It is added even when
nothing is set on the property, if `stubs.symbol_file` is set. i.e.

```
cc_library {
    name: "libfoo",
    stubs: {
        symbol_file: "libfoo.map.txt",
	// no versions: [...] needed
    },
}

cc_library {
    name: "a_client",
    shared_libs: ["libfoo"],
    apex_available: ["myapex"],
    min_sdk_version: "29",
}

apex {
    name: "myapex",
    native_shared_libraries: ["a_client"],
    min_sdk_version: "29",
}
```

`a_client` links to the "current" stub of `libfoo` that has all symbols
shown in the map file.

Note that, above doesn't mean that the client has unlimited access to
APIs that are introduced even after the min_sdk_version of the client
(29 in this example). The use of such APIs still has to be guarded with
`__builtin_available` check.

Bug: N/A
Test: m
Change-Id: I70bb1600c18e74d36c6b24c3569d2149f02aaf96
parent fdaa5f71
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment