1 |
Hi Benda, |
2 |
|
3 |
Thanks for the feedback! |
4 |
|
5 |
I’ve filled out the application and shared the link to Gentoo Foundation. The link is here |
6 |
for your convenience: |
7 |
|
8 |
https://docs.google.com/document/d/1v3yA4rkex5DGiPmdlXOSse5QZrZAL8QDJFNY2fFAMRY/edit?usp=sharing |
9 |
|
10 |
> H30/03/18 9:34、Benda Xu <heroxbd@g.o>のメール: |
11 |
> |
12 |
> Hi Pengcheng, |
13 |
> |
14 |
> Very well written proposal indeed! I enjoyed reading it. |
15 |
> |
16 |
> Pengcheng Xu <i@××××××××.moe> writes: |
17 |
> |
18 |
>> After getting in touch with the mentor of the idea, Benda Xu (heroxbd) |
19 |
>> and exchanging ideas, I’ve made a draft on my ideas and a rough plan |
20 |
>> about what I’m going to do, forming a proposal. It’s available as PDF |
21 |
>> in the attachment. Feedbacks wanted! |
22 |
> |
23 |
>> Gentoo GSoC 2018 Proposal |
24 |
>> [draft] |
25 |
>> Portage powered Android |
26 |
> |
27 |
> Just a random thought, you might want to revise the project name to make |
28 |
> it more catchy. |
29 |
|
30 |
I believe that “Portage powered Android” sounds like a good name for this. I’m open to |
31 |
new, catchy names as well! |
32 |
|
33 |
> |
34 |
>> Idea overview: |
35 |
> |
36 |
>> ...from Google Summer of Code/2018/Ideas/Portage powered Android (by |
37 |
>> heroxbd): The Android custom ROM development has been based on |
38 |
>> cross-compilation and flashing whole partitions. This paradigm has |
39 |
>> been serving well for the embedded system developments. But as the |
40 |
>> performance of personal mobile devices boost, it becomes feasible and |
41 |
>> desirable to introduce package management like personal |
42 |
>> computers. Package management will make software installation and |
43 |
>> update reliable, reproducible, incremental and convenient. |
44 |
> |
45 |
>> This project aims to introduce Gentoo's prestiges package manager, |
46 |
>> portage, to manage Android software stack. We are going to use the |
47 |
>> Gentoo on Android as a starting point. Starting from the GNU userland |
48 |
>> provided, we are going to work with the LineageOS build system based |
49 |
>> on the Android Open Source Project, to write ebuilds for the |
50 |
>> individual components. Starting from the linux kernel first, the |
51 |
>> Android will be reproduced from bottom up. |
52 |
> |
53 |
> It will become better if you could reduce the quote into 1-2 sentences |
54 |
> and rewrite the overview in your own words. |
55 |
|
56 |
Rewritten in draft 2. Feedback wanted. |
57 |
|
58 |
> |
59 |
> Also, if you need to get familar with AOSP build system for this |
60 |
> project, better get preapred now. |
61 |
|
62 |
I’ve successfully ran the build process for Lineage OS and fixed some minor problems (most of them |
63 |
due to misconfigured environment); have read through [this](https://elinux.org/Android_Build_System <https://elinux.org/Android_Build_System>) |
64 |
and [this](https://wiki.lineageos.org/devices/angler/build <https://wiki.lineageos.org/devices/angler/build>) for instructions |
65 |
as well, and I believe that’s enough to get started. |
66 |
|
67 |
> |
68 |
>> A more detailed look: |
69 |
> |
70 |
>> 1. The aim of this project, from my perspective of view, is to |
71 |
>> completely rebuild Android from bottom up, starting with getting hand |
72 |
>> on the raw, untouched build system of Android (or more specifically, |
73 |
>> its Lineage OS distribution) and produce a working system, so that we |
74 |
>> can verify that everything is working (unlikely), or fix up whatever |
75 |
>> problems (very likely) we may run into when building up the Lineage |
76 |
>> (large part of it AOSP) tree. Most importantly, this can get us |
77 |
>> familiar with how the existing Android build system works, |
78 |
> |
79 |
> us == traditional GNU/Linux distribution community? Because getting |
80 |
> familiar with the AOSP is not an interest for the AOSP community. |
81 |
|
82 |
Fixed. What I really meant here is that getting familiar with the build system is fundamental |
83 |
for dissecting it afterwards. |
84 |
|
85 |
> |
86 |
>> while in the meantime getting familiar with the various tools to work |
87 |
>> with Android, from cross-compile toolchains, deploying tools to |
88 |
>> maintenance tools on the device (e.g. bootloader & recovery). |
89 |
> |
90 |
>> 2. Then, to gain control of the system and unleash the full power of |
91 |
>> our GNU tools, I believe it necessary to place ourselves a layer below |
92 |
>> the existing Android system, so that we can easily poke around in the |
93 |
>> Android system in order to update it the way we want (the main purpose |
94 |
>> of this project). I’ve come up with two approaches (call it Approach a |
95 |
>> and b). Both of which require tampering the initramfs (maybe more), |
96 |
>> but does not involve touching the whole bunch of mess inside Android: |
97 |
> |
98 |
>> a. From the entry point in the initramfs, we launch a small loader to |
99 |
>> fork our real init into background, |
100 |
> |
101 |
> Is it possible just to have our real init call the Android init? Then |
102 |
> no background forking is needed. |
103 |
|
104 |
That’s possible as well. In fact, IMO that’s nothing different from having a helper launching the two inits |
105 |
and have our Linux init wait for the Android init; we do have to wait in both cases, after all. |
106 |
|
107 |
> |
108 |
>> and then fires up the Android init. Our launched init waits for |
109 |
>> Android init finishing initializing the devices, then we can continue |
110 |
>> our job, with the rest of the Android system booting up in the |
111 |
>> meantime. (This idea originally came from this thread [1]; |
112 |
> |
113 |
> s/this thread/this page/ ? |
114 |
|
115 |
Fixed. |
116 |
|
117 |
> |
118 |
>> the difference is that we’ll be trying to launch a full-blown init |
119 |
>> system, so that a great amount of packages in the existing Portage |
120 |
>> tree can utilize their service files (whether systemd units or OpenRC |
121 |
>> scripts) without modifying. |
122 |
> |
123 |
> s/modifying/modification/ . |
124 |
|
125 |
Fixed. |
126 |
|
127 |
> |
128 |
>> b. Launch the system with our own (real) init, initializing the core, |
129 |
>> necessary devices with udev (as what a normal Linux system will do), |
130 |
>> then launch the Android (sub)system inside a container. This is |
131 |
>> actually the technique used in the Android subsystem in Chrome OS [2], |
132 |
>> with the help of various namespace facilities provided by the Linux |
133 |
>> kernel. |
134 |
> |
135 |
> Also ARC++, |
136 |
> |
137 |
> https://en.wikipedia.org/wiki/Google_App_Runtime_for_Chrome |
138 |
> https://lwn.net/Articles/701964/ |
139 |
> |
140 |
> I am not sure if ARC++ needs to execute Android init. Have you checked |
141 |
> that? |
142 |
|
143 |
I haven’t found much information regarding ARC++ other than the few write-ups and presentation |
144 |
about the talk at XDC 2016. According to my predictions, however, I believe Android init is needed, |
145 |
however, as the aim for ARC++ is to minimize Android Framework changes, so it should require the |
146 |
conventional Android services as well (SurfaceFlinger, etc.); this is the case in the Graphics Overview |
147 |
in the presentation for ARC++. |
148 |
|
149 |
> |
150 |
>> This approach looks more promising and with far less hacky-smells, yet |
151 |
>> it definitely requires more investigation and work. |
152 |
> |
153 |
> If a central idea needs investigation, better do it now. |
154 |
|
155 |
Fixed. |
156 |
|
157 |
> |
158 |
>> 3. After we have acquired the level of control and, meanwhile, have |
159 |
>> the Android environment to deal with running somehow separated from |
160 |
>> our existing Linux system (it’s a complete Linux system at this |
161 |
>> point) |
162 |
> |
163 |
> GNU system? GNU/Linux system? This terminology can be comfusing |
164 |
> because Android itself is also on top of Linux. |
165 |
|
166 |
Fixed. Though IMO something built on top of Linux kernel can’t be called a Linux system thereby. |
167 |
|
168 |
> |
169 |
>> , we can start to move things inside Android territory into the |
170 |
>> management of Portage. |
171 |
> |
172 |
>> I’ve splitted this process into the following stages: |
173 |
> |
174 |
>> a. Get the Android kernel source sorted out and packaged as some sort |
175 |
>> of kernel source package. The final form should be something like |
176 |
>> sys-kernel/android-sources with USE_EXPAND like PLATFORM, which |
177 |
>> denotes the variant of the kernel source according to different |
178 |
>> devices (like PLATFORM=”hammerhead”); or something like |
179 |
>> android-kernel/hammerhead-sources. This enables us to manage the |
180 |
>> source and build process of the kernel more easily, as well as |
181 |
>> tweaking options and applying patches. (maybe merging mainline kernel |
182 |
>> as well, but that’s another story) |
183 |
> |
184 |
> Nice! |
185 |
> |
186 |
>> b. Try building some parts of the Android system (or more precisely, |
187 |
>> some components) separately, and get a more detailed understanding of |
188 |
>> the Android build system (namely Android.mk and friends). This process |
189 |
>> is necessary, as the original Android build system is somehow a tied |
190 |
>> piece of machinery, which is designed to work as a whole. Considerable |
191 |
>> amount of work is needed to take this system apart, along with (maybe |
192 |
>> quite a lot of) investigating, experimenting and hacking. |
193 |
> |
194 |
> If decoupling is difficult, building the whole AOSP from a single ebuild |
195 |
> is also acceptable. I can split them up later. |
196 |
|
197 |
I’ll focus on decoupling, and if I ran into problems I would definitely need help as well. |
198 |
|
199 |
> |
200 |
>> c. After we have got a complete understanding of the Android build |
201 |
>> system, as well as having been able to carve a part of it out without |
202 |
>> much difficulties, we should start composing something like |
203 |
>> android.eclass, so that we can automate the process in handling the |
204 |
>> Android components with Portage. The advantage of this stage is that |
205 |
>> once this eclass is built, we can automate the process of building any |
206 |
>> possible new or changed Android components, as well as reducing the |
207 |
>> hacking work needed for each individual component of the Android |
208 |
>> system. (Needing to hack every piece sounds like an impossible task.) |
209 |
> |
210 |
> Indeed. |
211 |
> |
212 |
>> d. The only job left for now would be to adopt every part of the |
213 |
>> Android system to using the freshly-made eclass. This is also an |
214 |
>> intensive testing process for the eclass, as surely many bugs and |
215 |
>> uncaught corner cases will pop out here and there. This can enable us |
216 |
>> to refine the eclass further. Another important thing at this part is |
217 |
>> to make sure some sort of isolation in different versions of the core |
218 |
>> system, as there’s a compatibility guarantee for Android applications |
219 |
>> called API level. We need to make sure that we leverage Portage |
220 |
>> techniques such as profiles to isolate different API levels apart, so |
221 |
>> as not to mix the system up across different versions, thus breaking |
222 |
>> the compatibility guarantee. Meanwhile, implementing this level of |
223 |
>> isolation with profiles allows us to switch the profile and then roll |
224 |
>> the system up to the new API level (no annoying blockers as that’s |
225 |
>> somehow unrelated to the “base system” that’s used to compile the |
226 |
>> Android land). |
227 |
> |
228 |
> Exactly. |
229 |
> |
230 |
>> 4. After 3, the main Android system would be sitting inside the |
231 |
>> container / chroot safe and sound |
232 |
> |
233 |
> If the Android is in /system, is a container still necessary? |
234 |
|
235 |
I consider it necessary, as we may run into issues caused by Android and GNU/Linux being inherently |
236 |
different in managing the system (networking, device management, mounting, etc.). With namespaces, |
237 |
we can reduce the probability of such things happening. Another consideration is that we don’t want the |
238 |
environment of Android to be mixed up with GNU/Linux, as having one platform’s tools (shell, |
239 |
coreutils, toolboxes, etc.) floating around in another platform’s environment can cause surprises for |
240 |
applications (like something that expects GNU date being greeted by the trimmed version from Android |
241 |
toolbox). |
242 |
|
243 |
> |
244 |
>> , with all parts of it being managed by Portage. This stage 4, as in |
245 |
>> my plan, would be to clean up the work and sort out a way to |
246 |
>> conveniently distribute the work. Required things would be: |
247 |
> |
248 |
>> a. Blog (intensively?) about the work done, so as to enable |
249 |
>> reproducing the entire process from scratch (in case this project is |
250 |
>> later abandoned and forgotten in the dust, yet someone (?) from the |
251 |
>> future wants to pick it up) -I’ve had quite unpleasant memories from |
252 |
>> experience with Gentoo/FreeBSD, trying to guess how things worked from |
253 |
>> void. Related documentation should be summed up and put into Gentoo |
254 |
>> Wiki, perhaps. |
255 |
> |
256 |
> I prefer blogging happening along the work, instead of a series of final |
257 |
> summaries. That will give you early feedbacks. |
258 |
|
259 |
Fixed. |
260 |
|
261 |
> |
262 |
>> b. Develop a way to distribute the initial setup process, as we can’t |
263 |
>> expect every user to start with the bootstrap process. Alternatively, |
264 |
>> offer a way to convert existing systems into the system we’re trying |
265 |
>> to build in discussion. The first method is preferred, though, as we |
266 |
>> reserve right to change the structure of the system instead of using |
267 |
>> what’s determined by the existing Android system, such as partition |
268 |
>> schemes, filesystem choices and filesystem root layouts. |
269 |
> |
270 |
> As the first step, please make sure a Gentoo-Handbook-like documentation |
271 |
> is available. Then we can talk about user-friendliness to the users |
272 |
> outside Gentoo. |
273 |
|
274 |
Fixed. |
275 |
|
276 |
> |
277 |
>> c. Set up build hosts for different devices, and (optionally) handle |
278 |
>> the production of binary packages. Though this may sound contradicting |
279 |
>> with the Gentoo philosophy, but building the Android system can be |
280 |
>> tiring and resource-consuming, while requiring users to set up |
281 |
>> cross-compile hosts sounds cumbersome. Or, at least, encourage the use |
282 |
>> of a building hosts locally or at small scales. |
283 |
> |
284 |
> Same as the above. |
285 |
> |
286 |
>> Expected outcomes |
287 |
>> (tl;dr) |
288 |
>> : |
289 |
> |
290 |
>> 1. What we get: |
291 |
> |
292 |
>> a. A working (perhaps no framebuffer support though; I believe that |
293 |
>> belongs to another project as it would be distracting and too much |
294 |
>> work) |
295 |
> |
296 |
> Avoid writing long sentence in paranthesis. If you want to cover this |
297 |
> point, write it out in the paragraph. |
298 |
|
299 |
Fixed. |
300 |
|
301 |
> |
302 |
> |
303 |
> IMHO, for me I am more interested in a working framebuffer than e.g., a |
304 |
> binary package repository. But you have the final word to prioritize |
305 |
> the tasks. |
306 |
> |
307 |
> Alternatively to a traditional framebuffer, frecon might be insightful: |
308 |
> |
309 |
> https://chromium.googlesource.com/chromiumos/platform/frecon/+/HEAD/DESIGN-DOC.md <https://chromium.googlesource.com/chromiumos/platform/frecon/+/HEAD/DESIGN-DOC.md> |
310 |
|
311 |
Honestly speaking, I’m afraid that I don’t have the required skills to work with graphics stack. Looking back |
312 |
on Wayland on libhybris on Android, the intrinsics of Android EGL made it difficult to act as a Wayland server. |
313 |
And, though ARC++ seems to be working out great, its scale seems to be enormous. I’m not quite optimistic |
314 |
with this direction; rather than creating odds and ends that don’t work together well, I’d prefer something that’s |
315 |
really achievable. Further discussions welcomed on this point. |
316 |
|
317 |
> |
318 |
>> Linux distribution on existing Android devices; |
319 |
> |
320 |
>> b. A working Android environment hosted inside or parallel with the |
321 |
>> Linux environment, with Portage managing it, taking the place of the |
322 |
>> original “System Upgrade” process; |
323 |
> |
324 |
> Nice! |
325 |
> |
326 |
>> c. A Portage overlay and android.eclass available to other general |
327 |
>> purpose Gentoo Linux systems |
328 |
> |
329 |
> We can reuse proj/android.git from the beginning. |
330 |
> |
331 |
> https://gitweb.gentoo.org/proj/android.git/ <https://gitweb.gentoo.org/proj/android.git/> |
332 |
|
333 |
That’s nice to know about. |
334 |
|
335 |
> |
336 |
>> (though further adaption from projects like Android-x86, but that’s |
337 |
>> out of the scope of this project) |
338 |
> |
339 |
> No, I don't think Android-x86 is relevant here. It a dead-end and we |
340 |
> don't need to mention about it. |
341 |
|
342 |
Fine. Section revised. |
343 |
|
344 |
> |
345 |
>> 2. What we can do with this: |
346 |
> |
347 |
>> a. Utilize tools that we’re familiar with to do things on the mobile, |
348 |
>> from more general toolchains available directly on the device, to |
349 |
>> various services we may want to run; basically we have a portable |
350 |
>> micro-server |
351 |
> |
352 |
> Absolutely! |
353 |
> |
354 |
> s/$/./ |
355 |
> |
356 |
>> b. Smoothen the update process of system without having to load up a |
357 |
>> full system image every time (this is especially important for Lineage |
358 |
>> OS nightly users: you need a full rom package to flash even if only a |
359 |
>> few bits of the system (usually just a few new commits) got changed) |
360 |
> |
361 |
> Indeed. But try to get rid of the long nested paranthesis. |
362 |
|
363 |
Fixed. |
364 |
|
365 |
> |
366 |
>> c. Easier adoption to techniques we’re already familiar with to |
367 |
>> perform tasks |
368 |
> |
369 |
>> About me: I’m Pengcheng Xu, a student currently studying in the School |
370 |
>> of Electronics Engineering and Computer Science at Peking University, |
371 |
>> China. Having used Gentoo for over 5 years and still currently using |
372 |
>> Gentoo as my server system (it’s a SPARC I got from Brendan Horan |
373 |
>> <brendan@×××××.hk>on the gentoo-devmailing list) as well as Gentoo |
374 |
>> Prefix on macOS and Ubuntu Linux, I have proposed quite many bugs and |
375 |
>> some patches as well |
376 |
> |
377 |
> Put a list of bugs and patches you worked with in an appendix |
378 |
> explicitly. If you have patches at hand, submit them soon. If you have |
379 |
> pending fixes for Gentoo/FreeBSD, publish them via the bugzilla. This |
380 |
> will make you more appealing to this program. |
381 |
|
382 |
I’ve opened up an Appendix section for links to what I’ve done on the Bugzilla. Is that sufficient? |
383 |
|
384 |
> |
385 |
> |
386 |
> Finally, please check out the student's guide to refine this proposal: |
387 |
> |
388 |
> https://google.github.io/gsocguides/student/ <https://google.github.io/gsocguides/student/> |
389 |
|
390 |
Got it. Thanks. |
391 |
|
392 |
> |
393 |
>> [1]: http://whiteboard.ping.se/Android/Debian |
394 |
>> [2]: |
395 |
>> https://events.static.linuxfound.org/sites/events/files/slides/ |
396 |
>> ContainersPresoLCE.pdf |
397 |
> |
398 |
> Yours, |
399 |
> Benda |
400 |
|
401 |
|
402 |
Pengcheng Xu |
403 |
i@××××××××.moe |