1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
<html devsite>
<head>
<title>Namespaces for Native Libraries</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
<!--
Copyright 2017 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<p>
Android 7.0 introduced namespaces for native libraries to limit internal API
visibility and resolve situations when apps accidentally end up using platform
libraries instead of their own. See the <a
href="http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html">Improving
Stability with Private C/C++ Symbol Restrictions in Android 7.0</a> Android
Developers blog post for application-specific changes.</p>
<h2 id="architecture">Architecture</h2>
<p>
The change separates system libraries from application libraries and makes it
hard to use internal system libraries by accident (and vice versa).
</p>
<img src="images/namespace-libraries.png" alt="Namespaces for native libraries" id="namespace-libraries" />
<p class="img-caption">
<strong>Figure 1.</strong> Namespaces for native libraries
</p>
<p>
Namespaces for native libraries prevent apps from using private-platform native
APIs (as was done with OpenSSL). It also removes situations where apps
accidentally end up using platform libraries instead of their own (as witnessed
with <code>libpng</code>).
</p>
<h2 id="adding-additional-native-libraries">Adding additional native
libraries</h2>
<p>
In addition to standard public native libraries, silicon vendors (starting from Android 7.0) and
device manufactures (starting from Android 9) may choose to provide additional native libraries
accessible to apps by putting them under the respective library folders and explicitly listing them
in .txt files.
</p>
<p>The library folders are:</p>
<ul>
<li><code>/vendor/lib</code> (for 32-bit) and <code>/vendor/lib64</code> (for 64-bit)
for libraries from silicon vendors</li>
<li><code>/system/lib</code> (for 32-bit) and <code>/system/lib64</code> (for 64-bit)
for libraries from device manufacturers</li>
<ul>
<p>The .txt files are:</p>
<ul>
<li><code>/vendor/etc/public.libraries.txt</code> for libraries from silicon vendors</li>
<li><code>/system/etc/public.libraries-COMPANYNAME.txt</code> for libraries from device manufacturers,
where <code>COMPANYNAME</code> refers to a name of the manufacturer (such as
<code>awesome.company</code>). <code>COMPANYNAME</code> should match with
<code>[A-Za-z0-9_.-]+</code>; alphanumeric characters, _, . (dot) and -. It is possible to
have multiple such .txt files in a device if some libraries are from external solution
providers.
</ul>
<p>
Native libraries in the <code>system</code> partition that are made public by device manufacturers
<strong>MUST</strong> be named <code>lib*COMPANYNAME.so</code>, e.g., <code>libFoo.awesome.company.so</code>.
In other words, <code>libFoo.so</code> without the company name suffix MUST NOT be made public.
The <code>COMPANYNAME</code> in the library file name MUST match with the <code>COMPANYNAME</code> in the
txt file name in which the library name is listed.
</p>
<p>
Native libraries that are part of AOSP MUST NOT be made public (except the standard
public native libraries which are public by default). Only the additional libraries added by
silicon vendors or device manufacturers can be made accessible to apps.
</p>
<p>
Starting from Android 8.0, vendor public libraries have the following additional
restrictions and required setups:
</p>
<ol>
<li>The native library in vendor must be properly labeled so it can be
accessible to apps. If access is required by any apps (including third
party apps), the library must be labeled as <code>same_process_hal_file</code>
in a vendor-specific <code>file_contexts</code> file as follows:
<pre class="devsite-click-to-copy">/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0</pre>
where <code>libnative.so</code> is the name of the native library.
</li>
<li>The library, either directly or transitively via its dependencies, must not
depend on system libraries other than VNDK-SP and LLNDK libraries. The list of
VNDK-SP and LLNDK libraries can be found at
<code>development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv</code>.
</li>
</ol>
<h2 id="updating-app-non-public">Updating apps to not use non-public native libraries</h2>
<p>
This feature is enabled only for applications targeting SDK version 24 or later;
for backward compatibility, see <a
href="http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html">Table
1. What to expect if your app is linking against private native libraries</a>.
The list of Android native libraries accessible to apps (also know as
public native libraries) is listed in CDD section 3.1.1. Apps targeting 24 or
later and using any non-public libraries should be updated. Please see <a
href="https://developer.android.com/preview/behavior-changes.html#ndk">NDK Apps
Linking to Platform Libraries </a> for more details.
</p>
</body>
</html>
|
