I'm not sure if the Wizard forum has particular trouble with virii/trojans or maybe I just notice it more but I thought I would cross-post a thread I started in the General section.
Howto verify uploads and downloads
I'll respond here as i seem to only fly around the Wizard forums...
How will this actually help? I don't mind a uploader posting an MD5 hash or SFV file to verify the file is what they uploaded, but if they are attaching it to the forum post or providing a direct link to the file on their server (or another server) then it wouldn't be tampered with. This kind of protection is only useful then you have a large number of mirror sites. As in the case of a virus or trojan it wouldn't detect that in any way...
It would only tell us that the file is what the uploader says it is. To that regard we end up still having to put a lot of trust in the uploader...
As I said I don't mind an uploader posting a hash, but in the context of what you're promoting it for I think it is useless...
You are right, for attached files the problem is already solved. However files available from 3rd party sites (rapidshare, etc) are not necessarily uploaded by the author. Often the author's rapidshare link (for example) may be broken so users end up sourcing the file elsewhere.
I believe it will help because the files being 'impersonated' seem to be popular files from recognised users such a mUn, Faria, and so on. In this instance the author has a reputation attributed to them. What file verification does is associates a certain file with that author. Forum users should already be evaluating the legitimacy of an upload based on the user. Someone with 1 post uploading a ROM should not be as trusted as someone known in the forum.
In the recent case of ShellTool being replaced I believe a hash would work. In this instance a trusted forum user uploaded a tool but duplicate copies were made available. Had the file being identified as different to the trusted version based on checksum it should have cast doubt on its legitimacy.
The problems found here are usually caused by people going to XDA FTP and downloading stuff based on their names directly, not with respect with any post, hence MD5 will not help much in this situation. And, when certain software were suggested on the forum, somehow, some people tend to look at FTP instead of the forum.
ANYWAY, using MD5 is good if people dont find it troublesome to take the extra security precaution. Still, I hope that people will at least state their file size of their uploaded file. It is unlikely to have a functional EXE with the same file size while performing totally different thing (at least it is not easily done).
So, I've been following this thread recently and I need to ask a very basic question about some bootloader basics.
Someone referenced a post that explained the difference between locked and encrypted bootloaders but I cannot seem to find it.
From what I understand, in the simplest of terms, locked is good news and encrypted is bad news. In other words, a locked bootloader will enable us to eventually install custom ROMs from a different kernel not currently supported by the latest OTA update. Whereas with an encrypted bootloader, it is pretty much impossible to install ROMs from a different kernel and are limited to installing from the same kernel.
I'm not sure if some (if any) of the above is right.
So, I go back to check on that thread today and I notice the OP has been updated to say that the bootloader is signed is the same as either locked or encrypted? Or is it a completely different term?
I really home it's the same as a locked bootloader, but I have no idea.
If anyone has a good link describing this, or feels like explaining it themselves, it would be appreciated.
Thanks!
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
perdurabo2 said:
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
Click to expand...
Click to collapse
Thanks for the reply!
So, is signed better news than encrypted? Sorry for my confusion but I'm not the best with understanding this kind of stuff.
But in the mean time, I'll be checking those wikipedia articles.
qcom100 said:
Thanks for the reply!
So, is signed better news than encrypted? Sorry for my confusion but I'm not the best with understanding this kind of stuff.
But in the mean time, I'll be checking those wikipedia articles.
Click to expand...
Click to collapse
For the most part, it's better news because the payload can be examined for exploits.
PKI (public/private key crypto) is a good thing to have an understanding of because it's use is so widespread in the computing world.
perdurabo2 said:
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
Click to expand...
Click to collapse
OK, thanks!
I recently got into tinkering with my Sprint Galaxy S4 and spent quite some time going through the whole process to get to Cyanogenmod, then back to stock, the reasons which I hope to share with you throughout this tutorial. I went to multiple sources from all over the web to answer all the questions I had, so I'm hoping to gather everything in one place so you can too learn the intricacies of playing with the OS on your phone.
This will be a work in progress for a bit, as I plan on going back to stock and working through the process again to capture everything I had to learn in order to get my phone to where I wanted it.
Hopefully once complete, this guide will help you do that same thing.
Thanks.
PS; I am placing the phrase "<link>" where I will eventually will insert the actual links, but until I leave new status, Google searches will have to do.
OverviewIn general, installing Cyanogenmod (or any other ROM, specific quirks notwithstanding) should consist of the following steps;
Pre-installation setup
Gathering Tools
Installing a custom recovery
Backing up your device
Flashing your custom ROM
Step-by-Step Walkhrough
Pre-installation setup
When installing a custom ROM, or conducting any sort of flashing/recovery/rooting etc, you may mess up your phone somehow. Sometimes this will void your warranty, leave you with a brick, or somehow otherwise go belly up. Before you start doing anything to your phone, you should make sure you understand what you're doing, read through all of the steps, and familiarize yourself with the process. Sometimes you may need to gather additional information, software, tools, etc. Google is your best friend! When you encounter a block, stop what you're doing and investigate what happened, and see what the consensus is on the subject of that error, so you can tread carefully. In the end, this will make you a better tinkerer in general. Also, if you mess your phone up, I'm not responsible for your environment conditions, actions, or mistakes.
With all of that being said, if you're going to blaze forward anyways, welcome to the path of making things do what you want them to do, regardless of what someone said you could or couldn't do with said things! Before you get started, you're probably going to want to gather basic info first;
What do I want out of my custom ROM?
There are many types of ROMs out there; Cyanogenmod is one of the most popular, but millions of people have created or assembled their own favorite OS' for Android devices. This particular ROM offers you more control over your phone. You can install custom apps, use established apps, execute root/admin tasks on your phone, and much more. Custom icons? Custom boot screen? Remove all of the carrier/manufacturer bloatware? All of these and much more are at your disposal.
Where can I find the model for my phone? What Android build do I have?
Before choosing to undertake a particular endeavor, make sure you know what phone you're actually working with. Using the wrong software or tool can brick your phone, or increase the time it takes to finish dramatically since you're going to have to go and find all of the fix information. In some cases, a phone may come with a certain version of Android, or a certain firmware. You should consider what may happen if you upgrade it, maybe you'll find you can't go back!
Do I want to use this phone with service?
This was irritating for me when I first was flashing my phone; I found out that when I called Sprint to switch the phone over from my HTC One, they said they couldn't port the new modded phone onto their network. This required me having to search down the original firmware, which is a hassle in and of itself. I'm sure there are ways to get your phone onto a network that I don't have any knowledge of, but why not save yourself the trouble and make sure you take care of things before starting.
Windows or Linux?
What operating system you are most comfortable with may vary, and your intentions with regards to flashing a custom ROM also will vary; do you just want to get something installed? Do you like to learn? Traditionally most folks will say that if you want the most control over the process, use Linux. It's open-source and gives you the most freedom to do as you wish, and in addition, untold numbers of tools exist for the platform that you have access to for free. Not that there's anything wrong with Windows, but if you want to flash a ROM, chances are you're interested in technology as a whole. Throughout this tutorial, I will do my best to provide options for both OS' where possible. In my case, I'm not interested in this process on a Mac environment, but you'll find most of the concepts here can be mirrored on the Mac OS, you'll just have to search for specifics on your own.
How comfortable am I with things like command lines?
Understanding how to use the command line, as opposed to graphical programs, will enable you to undertake the flashing process with much more control than otherwise allowed. Learning the command line is outside the scope of what I'm trying to teach you, but you can find information all around the web. Search for a cheatsheet for the Windows Command Line, or maybe if you're interested in learning about Linux, you can find information all over the web. With Linux, there can be a bit more variance on command lines as different flavors of Linux use different command lines.One such flavor of Linux is Ubuntu, which comes bundled with bash, a rather common and popular command line shell.
Again, where possible, I will try to provide options between the command line and GUI choices, but I will off the bat recommend that you familiarize yourself somewhat with the command line. You'll be a better person for it.
Gathering tools and info
Before you get started, it's a good idea to ensure that you have everything you're going to need at your disposal before getting started. I will do my best to document whatever I think is necessary to know on each tool/item you need;
Workspace
Sort of a no brainer, I would suggest creating a folder that you can store everything in the flash process, ideally one where you possess admin/root privileges. I will conduct this tutorial as if you were working from a folder titled 'Cyanogenmod.'
Phone Information
For the purposes of this tutorial, I am using the Sprint Samsung Galaxy S4 in black, which has the model number SPH-L720 (I don't think color influences model at all). At the moment, the phone is known as JFLTESPR at http://cyanogenmod.org/ specifically, though much of the process is the same across int'l/US carriers, so the phone also falls under the JFLTE family.
You'll want to have a few other pieces of info on hand as well. Most of these can be found either on the phone physically, or in the "About device" section in the Settings menu.
To get your model number, you can either remove the plastic rear panel, then the battery to find the model number written on the sticker underneath. Otherwise, you can go to Settings > About device > scroll to Model number.
In the same menu as above, you can also get the Android version, Baseband version, and the Build number. All of these help determine what features are available to you, what Android OS you have if you want to know about specific differences between numbers, what radio type you may have, and so on. Having these handy will let you look things up with a higher degree of accuracy.
Check Your Knowledge, or Are You Listening?
Did you make sure and go find the above information? If you care about your phone's warranty or you know, your freedom to mess with your SPH-L720 as you see fit, you should care enough to make sure you have this info!
Why does it matter? See your Baseband version and or Build number? Check those last 3 letters on there, they represent the firmware version you have installed on your phone. Certain firmwares have certain characteristics, but there are two in particular that you, as someone following this tutorial should care about; Whether or not the firmware comes with the Knox bootloader, and if you want the ability to downgrade/upgrade as you see fit. I also believe that the firmware can affect your hardware in sometimes undesirable ways. If you've recently flashed and your Wifi or radio (interface into the carrier's ecosystem for voice, messaging, and data) isn't working, research about the firmware is usually the first place to start looking.
The Knox bootloader contains a flag that is tripped if you install a custom recovery/bootloader, which doesn't affect any operation on your phone, however this flag, as of this writing, is not un-trippable. That's right, this is how Samsung will know if you've gone all rogue on the device. With this tripped, they can deny you warranty service, force you to pay for repair, and any other number of irritating things. Not knowing what firmware you can cost you dearly.
As to being able to change firmware freely, you can change between the Android 4.2.2 firmwares as you like, but if you move to 4.3, you cannot go back to 4.2.2, and 4.3 includes the Knox bootloader (though you can still move between 4.3 firmwares). Same for the firmware based on 4.4.2; if you move to this firmware, you cannot go back. In addition, as far as I know at the time of writing this, there's only one firmware in the 4.4.2 family.
For reference, here's a list of the firmwares;
MDC - This was the first firmware for the phone and was based on Android 4.2.2, and was pre-Knox bootloader
MDL- Based on Android 4.2.2, and was pre-Knox bootloader
MF9 - Based on Android 4.2.2, and was pre-Knox bootloader
MJA - Based on Android 4.3 and includes the Knox bootloader
MK2 - Based on Android 4.3 and includes the Knox bootloader
NAE - Based on Android 4.4.2 and includes the Knox bootloader
Besides influencing the above characteristics (and whatever other features are available per version), the firmware type also influences what software you might need in some cases. For instance, flashing back to stock requires you to use a firmware with the same 'class' of version, aka 4.2.2, 4.3, or 4.4.2. If you accidentally use the wrong version, you may regret it. Of course, if you're off warranty, or just don't care, you can go about this as you see fit. Just don't come to me if you fail to go learn what you need to know before flashing your phone. With all that being said, you can still install ROMs based on other versions of Android, just not a full flash.
I'm not sure of the correct XDA way to thank someone, but cruise350 provided me with this information directly, so if this helps, kudos goes to him.
Cyanogenmod ROM/OS
You can find everything you need to know (including the direct tutorials) for Cyanogenmod on their site <link>.
From the main page, you can get to the SPH-L720 by going to http://http://wiki.cyanogenmod.org/ > Devices > Hit 'show all devices' > enter 'JFLTE' in the search query to get to the landing page for our phone. From that page you can read more about Cyanogen and what you can do with it and our phone together. For now, we can just download the ROM.
Go to the download page at http://download.cyanogenmod.org/, where you'll find a list of devices and their various ROM builds. Since developers around the world are working on Cyanogenmod at any given time, there are many different builds/versions of the ROM. If this is your first time with Cyanogen, you will want to stick with the 'Stable' build. This is considered the latest 'finished' build, or represents the latest release the developers consider complete. The other builds represent ROMs which are nearing completion and moving to Stable (Release Candidate), a build at a particular point in time (Snapshot), builds which were created at a certain point in the development history of Cyanogen (Milestone), the absolute latest and greatest build as it's uploaded (Nightly), or just plain random (Experimental). Some of these builds are more fully featured than others, and others may be missing features, may be buggy, or somehow undesirable to us at this moment. As I said, for now, stick with Stable.
Remember how I mentioned that the SPH-L720 is called JFLTESPR by Cyanogen specifically? That's the download we're searching for. Click Stable under the Type menu, and scroll down to JFLTESPR. At the time I'm writing this, there are 3 versions of Cyanogen available to us; 10.1.3, 10.2.0, and 10.2.1. As a beginner, the differences between versions may be minimal, or minimally noticeable. I'd suggest getting the latest build for now, then futzing around with versioning later in your tinkering career.
In addition to Cyanogenmod, if you look on the installation page at http://wiki.cyanogenmod.org/w/Install_CM_for_jflte, under the heading 'Installing CyanogenMod from recovery' (we will get there), they mention the 3rd party app 'GApps,' which provides an interface into the Google ecosystem, so you'll have access to stuff like Gmail, Calendar, and the freakin keyboard! If you find your keyboard constantly failing, remember to go back and make sure you have the correct GApps version based on your Cyanogenmod version. The Cyanogen wiki provides a handy-dandy chart at http://wiki.cyanogenmod.org/w/Google_Apps to help you choose what GApps version you need.
Custom Recovery Mod
Cyanogenmod's wiki also provides you with info on what a recovery mod is at http://wiki.cyanogenmod.org/w/All_About_Recovery_Images.
Basically, when you receive a stock phone, the recovery/boot mode is limited in scope. As they say, it's mainly for installing manufacturer updates, and not much else of use to us. With a custom recovery, you gain access to many more features and things you can do outside the manufacturer's original intent. In the scope of this tutorial, we are using our custom recovery mod to first back up our phone's data, and second, actually install Cyanogenmod.
Just like the fact that there exists a large number of custom ROMs, so does there exist custom recovery mods. I'm choosing to use ClockWork Recovery Mod (CWRM) because it looks pretty and gets the job done. The specifics of a particular recovery are left up to the curiosity of the reader.
You can download CWRM at http://clockworkmod.com/rommanager; just scroll down to the Sprint GS4 and pick the version that is shown. Again, other versions may exist, but for the intrepid reader who's made it this far, stick with the latest, greatest, and easiest.
USB Cable
"Hurr durr no **** I need a USB cable" you say, but you wouldn't believe how irritating it is to attempt to diagnose a faulty cord issue. Sure, maybe you're the type of person who actually tries the easiest fixes first, this isn't revelatory, but if you're like me, I feel sorry both you and I.
Ensure you have a nice clean, un-kinked and untangled USB to Mini-USB cable on hand, preferably the cable that came with your phone. This will have the best chance of working properly. In addition to a cable, keep in mind that if you're using a USB hub, you may encounter errors. I've not used a powered USB hub in this process, but again, trying to diagnose the USB hub as the point of failure is annoying too. Save yourself the irritation.
Heimdall
Heimdall is a powerful open source program that lets you interface with the file structure of your phone and flash custom firmware, Heimdall was created by Benjamin Dobell of Glass Echidna and was designed specifically for Samsung devices. You can find a list of the phones they test on at the Heimdall page at http://glassechidna.com.au/heimdall/.
Some of you may have heard of Odin, another program used to flash firmware onto Samsung devices. Odin was an internal tool developed by the manufacturer that made it's way into the wild somehow, and can achieve the same effect as Heimdall (more or less), however there are a few reasons I suggest using Heimdall if you have a choice;
Heimdall is open source
You can freely access the code for Heimdall and make changes if you ever needed to, but the fact that the code is transparent and for all to use means an easier time flashing for you. The fact you can use Heimdall on Windows, Linux, and the Mac OS' is just a whole bunch of whipped cream on the flash-cake.
Odin is an internal Samsung tool
This means you don't have a way to go ask the maker of the tool for help, or explanations on how to use it. Samsung will offer customer support for this tool equal to the amount of existence that flash-cake has; none. There is documentation from all the smart people out there who have dug into Odin if you do want to use Odin. Also, it's Windows-only. You might not care about this fact, but if you're a tinkerer, Linux would be nice no?
Support!
In my flashing journey, I've had to troubleshoot a few things as far as Heimdall goes, and many times on some pages, I've seen Benjamin reply to people with information that he and only he can provide as the maker of Heimdall. I don't know him personally or really at all, but at least we can go ask him for support if necessary.
In order to use Heimdall, you just need to unzip the contents of the download into the Cyanogenmod folder, in our case, create a folder titled 'Heimdall' inside of Cyanogenmod.
Android SDK
The Android Software Development Kit (SDK) is the software Google provides for developers to create things in the Android ecosystem. The kit contains the code editor Eclipse, a plethora of support tools and tricks to create the best apps/ROMs/whatever you can think of, as well as interface with your phone in manners beyond ordinary users. There is a lot of stuff in the SDK, but we are specifically interested in the Android Debug Bridge (ADB) tool, which allows you to send data back and forth from your phone.
You can find the SDK at https://developer.android.com/sdk/index.html, but keep in mind you will most likely need admin/root privileges in order to use the SDK (and Heimdall). From that page, you can choose the Android Developer Tools (ADT) bundle, which comes with Eclipse, or you can choose to download an SDK kit without the IDE. For the scope of this tutorial, you only require the SDK. Once downloaded, you can unzip the SDK into the Cyanogenmod folder (the first thing to come out the SDK zip is a folder titled sdk, plus the SDK manager).
Open up the SDK Manager program (if you're on Windows, if running SDKManager.exe briefly shows a command prompt window, then disappears, you can go to sdk > tools > android.bat. This will open the SDKManager for you). The SDK will provide you with a list of packages you can download for various parts of Android development, but the ones we care about are the Android SDK Tools and the Android SDK Platform-tools. Check the box by each one, then hit install packages. The SDK Manager will prompt you for some license agreementing, then install the software for you. I believe that the manager installs the software in the sdk folder that the manager also resides in, so keep this in mind.
Installing a custom recovery
Backing up your device
Flashing your custom ROM
Reserve 1
For more info.
Reserve 2
Just in case.
If you happen to be reading this for the content, can you answer this; should I include the basics such as installation processes and whatnot? Or just skim the basics?
Would anyone be willing and able to create a dump of a clean Windows 10 for Phones system image and share it with me? I searched around in the installation for non-supported devices threads, but did not see a reference to anything.
An FFU image extracted from the updater would also work, thanks in advance!
Why is that?
I see.
But at least it's possible, even if not very probable.
Although, we should check if we can use WinRAR, since it's possible to edit the images without breaking the signiture.
Assuming we have a signed image.
Not possible. There are many threads trying to achieve what you're hoping to do with cabs and such, and it's not possible when the bootloaders are signed and damn near everything in the system requires a signed cert.
But how does that prevent us from opening and modifying them with WinRAR?
Even if we can't boot the new files, it's still a step.
So open it with WinRAR, if possible.
At least to get an idea of the structure of the OTA, that peice of information may help us form an idea as to at least part of the structure of the system.
It's better to have (theoretical) partial read access, than no access at all.
feherneoh said:
FFU is not OTA
Click to expand...
Click to collapse
Alright, but can you open it inside WinRAR?
Now we're talking, what we need now is someone to examine the partitions and their layouts.
Unfortunately , I'm not at that level but at least I can understand these things, so I would like to hear the results.
Is anyone exporting the partitions yet?
Unfortunately, I don't know the partition layout in Windows 10 Mobile, but perhaps they should all be exported and examined?
Not for myself, however I had thought that it may help others attempting to port Windows 10 Mobile in the future.
you can try to download MI4 rom
http://en.miui.com/thread-189556-1-1.html
I have seen allot of about vendor images in rom threads and Q&A
I figured allot of people dont even know what a vendor image is well its where the proprietary binaries sit now on their own partition called the vendor.img
they used to sit in /system but now have their own partition much like the bootloader and modems do. its use is to house the device specific files etc.
This was done for a multitude of reasons including legal/licensing issues .
heres a really good discussion on it i found very informative
https://plus.google.com/+JeanBaptisteQueru/posts/akHWypRNEn3
PS: you dont have to flash the newest vendor every time you flash a ROM :good::highfive:
on most devices you can flash it from twrp 3.0.0-1 and above by going where you normally do to flash a zip and selecting flash image and choosing vendor
Dreamlogix said:
I have seen allot of about vendor images in rom threads and Q&A
I figured allot of people dont even know what a vendor image is well its where the proprietary binaries sit now on their own partition called the vendor.img
they used to sit in /system but now have their own partition much like the bootloader and modems do. its use is to house the device specific files etc.
This was done for a multitude of reasons including legal/licensing issues .
heres a really good discussion on it i found very informative
https://plus.google.com/+JeanBaptisteQueru/posts/akHWypRNEn3
PS: you dont have to flash the newest vendor every time you flash a ROM :good::highfive:
on most devices you can flash it from twrp 3.0.0-1 and above by going where you normally do to flash a zip and selecting flash image and choosing vendor
Click to expand...
Click to collapse
I dont know why,but I cant open that link..error 404
Sent from my Nexus 9 using Tapatalk
"A step forward for the Android Open Source world
There's a hidden gem in Nexus 9, which was announced by a short sentence in the middle of a reply in a long mailing-list thread:
"No proprietary binaries are needed for Volantis. The proprietary vendor binaries are on a separate 'vendor' partition."
Until now, in Android devices, the proprietary device-specific files that live underneath Android itself were stored in the same /system partition as the Android files.
This made sense from the point of view of software architecture, but it had a major drawback in the Open Source world: in order to distribute a functional system image of Android, it was necessary to also distribute those proprietary device-specific files, since those files were aggregated into the same distribution medium.
Starting with Nexus S, those files had been somewhat available, with two caveats: not all files were available for all devices, and the files that were available were controlled by licenses that allowed the most common use cases but didn't give the same freedom that can be expected for Open Source components.
On Nexus 9, things are different: those proprietary device-specific files are stored in a separate partition. As a result, it is now practical to distribute functional versions of the Android system without having to distribute or copy those proprietary files. Therefore it becomes possible to enjoy the freedoms associated with Open Source in a broader range of situations, including (e.g.) commercial distribution.
While Android has always been distributed under Open Source licenses (i.e. in the world of lawyers), this brings it closer to the spirit of the Free Software definition in the real world (i.e. in the world of hackers).
This makes me happy, as this is the conclusion of a task that had been started 3 1/2 years ago with Galaxy Nexus, and in which I had been closely involved when I worked on AOSP. Chances are, this is probably also the last aspect of Android to get released in which I've been closely involved while at Google."
Maybe you can help me?
I tried flashing vendor.img from 5.11 after I upgraded to Marshmallow because SMS/MMS stopped working on my N9 LTE after the update. It still doesn't work on N either. Anyway, doing this restored my SMS/MMS but screwed up some other things making the tablet unreliable. Should I have wiped cache etc when I did this? Would it even help?
So I'm guessing the radio is now in vendor.img? Can I/should I extract and use that?
Last question, what are the advantages to updating the vendor.img in later updates? Does anything important get changed in it that might affect system performance (other than me SMS problem) like battery drain, or device efficiency?