{"id":6167,"date":"2019-10-09T21:16:09","date_gmt":"2019-10-09T19:16:09","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=6167"},"modified":"2019-10-09T09:16:32","modified_gmt":"2019-10-09T07:16:32","slug":"android-is-not-open-source","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2019\/10\/09\/android-is-not-open-source\/","title":{"rendered":"Android is NOT open source"},"content":{"rendered":"

Now I know I’ve done the-right-thing <\/strong><\/em>supporting Librem5.<\/h2>\n

I knew that almost all phones comes with a proprietary OS, either the prison-ware iOS or proprietary derivative of Android. Yet I wasn’t aware that the situation is SO<\/strong> bad. Read this.<\/p>\n

\"\"<\/a>Android<\/a> is not open source – The Quantified VC – Medium<\/a><\/em><\/h1>\n

 <\/p>\n

<\/p>\n

Now there are some real issues these days:<\/p>\n

    \n
  1. there are so many applications available “for Android” that non-tech people will want on their hardware,<\/li>\n
  2. most of them are sadly proprietary,<\/li>\n
  3. almost all proprietary are available only on Google Play store<\/li>\n
  4. some of those proprietary, available only throught proprietary store is almost mandatory to access some facilities such as most European home-banking<\/li>\n<\/ol>\n

    Now free-as-in-freedom Android application can be found on the net or conviently on F-Droid<\/a> while access to “apps” (how I dislike this abbreviation!) can be “extracted” using Aurora Store<\/a>. Sadly:<\/p>\n

    Using Aurora Store<\/span><\/span> with your own Google account may cause your account to be blacklisted, use at your own risk.<\/p><\/blockquote>\n

    So this is not a long-term solution. A more long-term way to handle this issue is microg.org<\/a> “A free-as-in-freedom re-implementation of Google\u2019s proprietary Android user space apps and libraries.”<\/p>\n

    But this is not a solution. It is a work-around. A solution would to have free-as-in-freedom software. I fear that their inofficial Google PlayStore Client,\u00a0Phonesky<\/a> will be blacklistable as Aurora.<\/p>\n

    <\/p>\n

    \n
    \n
    \n

    Android is not open source<\/h1>\n<\/div>\n<\/div>\n
    \n

    Cutting through Google\u2019s marketing speak and seeking the truth<\/h2>\n<\/div>\n
    \n
    \n
    \"The<\/a><\/div>\n
    \n
    \n
    \n
    \n

    The Quantified VC<\/a><\/span><\/p>\n

    <\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
    \n
    \n
    \n
    Aug 27, 2016<\/a> \u00b7 5 min read<\/div>\n<\/div>\n<\/div>\n<\/div>\n
    \n
    \n
    \n
    \"\"<\/div>\n<\/div>\n<\/div>\n<\/figure>\n

    I\u2019m getting tired of hearing people claim that Android is open-source. The Android Open Source Project (AOSP) isn\u2019t what ships on most Android devices and can\u2019t be built unmodified<\/em>. Most Android devices are not even shipping an OS that AOSP has the sources for internally. Android has become some proprietary OS that passes Android Compatibility Test Suite (CTS).<\/p>\n

    AOSP code still depends on Qualcomm build utilities which are not provided by the AOSP source tree. Without them, certain functionality ends up missing. The missing Qualcomm code is in many cases open source as part of CAF (a custom Linux kernel branch optimized for Snapdragon phones). Google DOES have a bunch of proprietary Qualcomm code in their internal tree, but takes the easy route of removing it all when converting from the internal tree to AOSP.<\/p>\n

    \n
    \n

    The \u201copen source\u201d Android codebase depends on proprietary applications. Android source is almost entirely per-device code.<\/p>\n<\/div>\n

    \n

    In theory, AOSP could run on open hardware without this nonsense. It becomes a huge problem when it\u2019s not possible to build for the non-open hardware, since that open hardware does not exist yet.<\/p>\n<\/div>\n<\/blockquote>\n

    In 6.0 Marshmallow, it was possible to make an incomplete build of the Android Open Source Project for Nexus 5X and 6P with missing blobs. It\u2019s apparently not even possible to get that far with AOSP in 7.0 Nougat, since Google open-sourced something without providing the dependencies. It\u2019s no longer possible to do an incomplete build without setting up binary blobs (which they don\u2019t offer now), since `device\/huawei\/angler\/location<\/em>` and `device\/lge\/bullhead\/location<\/em>` depend on a having the blob build system. Either way, you need blobs simply to boot, but can get away with unmodified `vendor.img<\/em>` by not having verified boot.<\/p>\n

    Google added this code<\/a> to the source tree of Nexus 5X without providing the dependencies, so the `aosp_bullhead<\/em>` target simply doesn\u2019t work at all. The same applies to the other Nexus devices. This code can simply be removed and bundled as a blob, but it demonstrates that Google hasn\u2019t even built AOSP 7.0 for its Nexus devices.<\/p>\n

    The AOSP codebase is much, much worse than it used to be. It all started going downhill with the Nexus 9<\/a>. Google\u2019s pre-optimized proprietary apps are a massive roadblock. A Google engineer could easily fix that for Nexus devices, but instead Google has chosen to prevent binary releases and make dependencies unavailable in the source code. It doesn\u2019t seem like anyone at Google works on AOSP anymore \u2014 it has become just an afterthought.<\/p>\n

    You pretty much have to reverse engineer the .dex<\/em> files from the optimized code. Copy binaries from the factory images, like CyanogenMod does. Google stopped shipping proper apks with classes.dex<\/em> some time ago, though. You now get only oat files. You can do a giant hack<\/a> and convert the .oat files back into .dex files. Yet it doesn\u2019t fully work. The new version of Android changes the formats of these files, so that mostly working workaround is gone for now.<\/p>\n

    This commit<\/a> gives the impression that Google delayed the release of factory images and OTA updates for 7.0 Nougat on Nexus 6P because it couldn\u2019t play 480p video properly.<\/p>\n

    The 6P release moves a lot of blobs from system to vendor unlike the 5X release. One of the problems is that the vendor partition is likely too small, i.e. they didn\u2019t account for the required growth of the vendor partition since they started with half of the blobs in system. It likely won\u2019t all fit. Regardless, the vendor partition has to be reassembled to make a proper build with functional verified boot among other issues without it.<\/p>\n

    The intended purpose appears to be allowing AOSP builds to bundle a `vendor.img<\/em>` and ship it as is, but that\u2019s broken. So what is the point?<\/p>\n

    The one nice thing about the vendor partition is that every blob on there needs to be included. For system, a list has to be built by hand choosing them. It also ends up fixing the oat issue on a case-by-case basis, but it would need to be fixed in all cases to avoid needing a tool to reverse engineer dex.<\/p>\n

    AOSP 7.0 really only has support for a single device right now: Google\u2019s own Pixel C tablet, powered by the NVIDIA Tegra X1 processor. Building for anything else requires unofficial modifications. Google\u2019s `vendor.img<\/em>` shell game doesn\u2019t work. They can\u2019t move apps needing platform key signatures there; not regenerating that `vendor.img<\/em>` is broken, with verified boot being the main issue. Open-source components now depend on the unpublished build system used to make the proprietary blobs. It\u2019s still not possible to update the Nexus 5X bootloader without using the update-binary from stock OTA firmware due to a proprietary LG library.<\/p>\n

    On the Pixel C Android tablet, Google decided to use the open-source Nouveau DRM kernel driver<\/a> by default for this ARM device powered by NVIDIA\u2019s Tegra X1 SoC. Nouveau has terrible performance on Linux systems, just FYI.<\/p>\n

    What\u2019s surprising is that NVIDIA is actually once of the leaders when it comes to mainlining code for their mobile platform (Tegra). Isn\u2019t that a bit disturbing?<\/p>\n

    The Android kernel drivers are primarily open-source at this point, but few vendors try to land the code upstream. So they have 2\u20133 million of lines of code for their platform out-of-tree for a specific kernel version, with no hope of a mainline kernel ever being used. Users may receive security updates, but don\u2019t hope for more than 2\u20133 years of updates since the kernels age poorly.<\/p>\n

    TLDR: Although the Android platform is advertised as \u201copen source,\u201d Android hardware makers can lock down the devices and prevent users from modifying the software \u2014 and they do \u2014 while carriers can have complete control over user experience.<\/p>\n<\/blockquote>\n

    <\/p>\n

    \n
    \n
    \n

    Running Debian Linux on Android device natively<\/a><\/h1>\n<\/div>\n<\/div>\n
    \n

    No, not chroot<\/code>, but like a matrix.<\/h2>\n<\/div>\n
    \n
    \n
    \"The<\/a>The Quantified VC<\/a><\/span><\/div>\n<\/div>\n<\/div>\n
    \n
    \n
    \n
    \n
    \n
    Sep 12, 2016<\/a> \u00b7 17 min read<\/div>\n<\/div>\n<\/div>\n<\/div>\n
    \n
    \n
    \n
    \n
    \"\"<\/div>\n<\/div>\n<\/div>\n<\/div>
    Debian running natively atop Android, the Matrix Way.<\/figcaption><\/figure>\n

    Last year I picked up a decent mid-end and relatively \u201copen<\/a>\u201d LG Optimus phone while I was in Florida. I rooted it, installed a custom ROM with the latest security patch level, hardened it in every feasible way, and kept it as FLOSS as possible. It worked out great for my needs and traveled with me quite a bit. A few weeks ago, I got a new OnePlus One and decided to turn the LG phone into a development device \/ playdough.<\/p>\n

    \u201cWhy don\u2019t I turn this phone into a full-blown Linux server and run web services on it as if it were a Raspberry Pi?\u201d The thought kept popping into my head. So I spent much of the first week of September investigating the possibilities.<\/p>\n

    There are numerous tutorials on how to run a Linux OS in a chroot<\/em> environment on an Android device, and there are countless apps (e.g., Servers Ultimate, PAW Server) which allow you to run web servers (e.g., VNC, VPN, SIP, FTP, proxy) directly from an Android device. However, I wanted a real full-blown Linux server (e.g., Debian) running seamlessly on my Android phone, where I could access the Android OS from Debian without restrictions and at the same time make no modifications to the Android system itself.<\/p>\n

    I was thinking that perhaps I could implement a new init<\/code> procedure mounting a new root file system at boot, which then transfers control to the Android <em class="md">init<\/em><\/code> in a chroot<\/code> environment.<\/p>\n

    The advantages of this approach over the others:<\/p>\n