Ed. note: The following article will not present a juxtaposition of marketing and propaganda. The philosophical similarity of such concepts may be left for another time.
Ed. note: The following article will not endeavor to address the ZMOT marketing strategy as published of any singularly advertising-oriented commercial agencies.
Google Android -- as a mobile operating system certainly "more open" than iOS, if not measurably "More fun" than QNX, in any arbitrary measure of statistical popularity -- it being an operating system, it has a source code. It being an operating system based on the Linux kernel, of course it's an operating system extending of a GPL licensed work, moreover. Software licensing not being per se a time-locked concept, it may be a relevant concept even when it is not per se a popular concept. Thus, the author proposes to write about the concept, even in writing in a populist Internet media.
Though the GPL license clearly does not limit the popularity of marketing about the Android platform, but as the GPL's licensing limitations representing a manner of a legal concept, and Google being a gargantuan company, it certainly may not be the veritable poisoned apple in the varnish, if it may be something that Google surely would have addressed, already, to all legal extents, already -- such as would be apparent of Google Android source code distribution and Google Android binary application distribution.
So much as any non-GPL'd applciations may be defined as linking to the Linux Kernel in the Android platform -- that, of course, would not be "On Google," rather "On" the responsibilities of Android application developers. Sure, Google facilitates distribution of non-GPL'd applications for Android, with the Android App Store -- and sure, it may be difficult, if it is not altogether impossible for a software industry to thrive under a toxic licensing strategy such as, to some theories, the GPL represents. So far as estimating any possible risk of Android application development, with non-GPL's applications, "The industry" perhaps seems to "Look away" from analyzing the exact terms of the GPL license and its implications for applications development and public applications distribution on GPL'd platforms. Individual software vendors may not be at such liberty.
A thorough study of licenses applied in the Google Android source code -- such a study being, no doubt, a non-trivial thing to develop -- may not be immediately forthcoming of this singular article, though proposed of this article, momentarily.
A study about source code management practices applied with regards to the Android operating system -- as a study that should be preceded with a study about software licensing, as in regards to terms and practices of software licensing in regards to software development and software distribution -- a study about source code management, itself as a topic, may need not begin with any manner of a review of marketing propaganda.
Of course, Android is designed to be compiled with GNU LibC and GNU Make [requirements]. There's a certain alignment between Java Development Kit (JDK) versions and Android versions, moreover
| Android OS Version(s) | JDK Version |
|---|---|
| "Cupcake" .. "Froyo" | JDK Release 5 |
| "Gingerbread" .. "Kitkat" | JDK Release 6 |
| "Jellybean" .. | JDK Release 7 |
The Android Open Source Project (AOSP) applies Git as a software change and configuration management tool. Thus, the AOSP source code repositories may be presented as changeset management repositories -- of which, there are no few [android Git repositories]
As though in a manner similar to the Google Chromium project, the Google Android Open Source Project applies -- as extending of the Git changeset model -- a custom development tool, named repo.
... a central managing repository of which is represented in the platform/manifest repository of the Google AOSP.
Repo may provide a manner of a service for coordinating Git changeset branches among individual Git repositories published of the Google AOSP. The platform/manifest repository itself is organized with a number of changeset branches and changeset tags, each representing -- no doubt -- a specific application target for the Android platform, as in regards to platform development and software distribution services. The Android Downloading and Building guide, for instance, recommends a branch named 'android-4.0.1_r1', such that -- certainly -- would represent a version 4.0.1 release of the Android operating system, essentially as upstream to any vendor-specific additions to the operating system.
Clearly, a topic of Changeset Management with the Android platform may seem to become to something of a geometric expansion, as with regards to analysis of software repositories, software sources, software destinations, and provenance as in a manner of software platform analysis. So far as that the Repo tool can be applied for accessing Android source code, there is a guide about it online.
Candidly, so, it may not be all of a trivial process to develop a "match" between any single vendor release of the Android operating system, in matching to any single upstream Android open source release -- or, in a logical inverse of such relation, traversing the Android OS distribution chain from any single Android open source release to any number of individual vendor releases.
Beginning with changeset branch 'android-4.0.1_r1' in the AOSP platform/manifest repository [AOSP] ... after a short 'Git clone', perhaps the contents of the repository would then be readily available for expert perusal.
This author will presently take a short break, while mustering up to understand Android.
