Shared publicly  - 
On HTC's "unlocked" bootloader

arcee: HTC's "unlock" is paying lip service to a publicized promise
arcee: Nothing more, nothing less
arcee: you asked for unlocked bootloaders, you got them
arcee: now stop complaining, and next time ask for what you really want
koush: LOL
ciwrl|work: +1
koush: what they really want is a galaxy nexus
arcee: koush: it's true. Whether intentionally or not, they gave "the community" EXACTLY what it asked for
Jaime Cruz's profile photoChris Harrison's profile photoChristopher Cote's profile photoJoshua Briefman's profile photo
I'm not up on this issue. What did they give vs. what was really wanted?
S-OFF was wanted but only a half unlocked bootloader was given
I was initially torn between the Galaxy Nexus and an HTC One S. Very glad I went with the Nexus, now
you can not install custom kernels is one main point this has becomes a problem
Edit: I missed the detailed context and commented off-the-mark. See further down in the thread for details.


Having the platform-level files in AOSP takes some effort.
Having the device-specific Open Source files in AOSP takes some effort.
Having the proprietary hardware-related binaries available for download with a license that allows redistribution takes some effort.
Having the factory images takes some effort.

The bootloader is just one step, and while it has some non-technical implications, there are some other steps that are significantly more complex.

Edit: plus, indeed, there are typically different bootloader behaviors that can be locked or unlocked, so the notion of an "unlocked bootloader" can need to be clarified if it's not obvious from the context.
+Scotty Brown had a segment last night, it was interesting to hear other takes on it. I do think its pointless to not have a true full unlock. Play on words or not. Name it then.
Still more than what Motorola has done.

But yea, if you want a Nexus just buy a Nexus.
+Koushik Dutta - In some contexts, some people assume that having the ability to flash a custom build on a device is all that's necessary to compile AOSP and have a build that works on that device.
+cody raeth OEM unlock ftw. I like how the unlocked lock shows up on the bootsplashxD
So the kernel partition is locked when booted into the live system and recovery?
+Koushik Dutta - Ouch. That's a bummer. That does take care of the case of flashing one's own custom build, but that's totally ineffective to distribute builds to end-users.
+Koushik Dutta +Jean-Baptiste Queru HTC devices have almost always had a number of protection layers against tampering, mostly around

1 - The ability to fastboot flash something
2 - The ability to run unsigned bootimages
3 - The ability to write the filesystem

They've been doing 1+3 at least since the Desire, and both were "worked around" with either leaked engineering bootloaders or tools that modified the devices to bypass such checks.
Their last 2 generations of devices have enforced all 3 of these, and when people realized that even with write access they couldn't boot a self-built image, HTC was asked to do something generically defined as "unlock the bootloader". For a while, they did 1 and 2, and now they're apparently only doing 1. Which still fits the description of "unlocking the bootloader" :)
+Ricardo Cerqueira - Yeah, even for the HTC devices that Google got closely involved in things have been difficult on my side:

-ADP1 and ADP2 can't flash the bootloader or the radio via fastboot, they have to go through recovery.

-Nexus One can't fastboot erase the userdata partition, and there's no fastboot oem lock.
+1 to Google Plus for letting me "listen in" on this conversation!
+Koushik Dutta Interesting. This seems like it could be reasonable to work around by flashing a stub bootloader to boot that chainloads the kernel from the filesystem in system. There's nothing in HTC's bootloader that specifically requires the next image to be a Linux kernel.

Qualcomm has a tiny OS project that might be ideal for this. I've previously ported this to the Dell Streak without much trouble over a few days. Alternatively, the boot stub kernel could be a stock Linux kernel with kexec and enough magic in initrd to kexec stage 2.
I know this isn't at the level you guys are talking about, but I always thought you should give people who know what they are getting themselves into the option of changing the version of the OS. This doesn't have to be, as some people suggested in the past, an option on first boot whether or not to have the AOSP build or Sense or Touch Wiz or whatever Sony are doing these days. I remember back to an old Walkman Hi-MD player I used to have; you could input a key combination on the in line remote and get into the service menu and adjust things like the volume limit. You could only do this if you actively sought out how to do it for the purpose of doing just that.

If manufacturers can implement a system such as this then you could have a HTC One S with an AOSP build of Android, one that you could download from the OEM site and use a utility such as Odin with a simpler UI. But then you encounter a new problem: Who will optimise AOSP for the One S, or the One X, or the Xperia S or the GSIII? It would be a lot of work for Samsung to maintain AOSP for all of their phones for instance. They use that many different processors and cameras etc.

Now if you could then somehow manage to get versions of AOSP to all the phones, and find a way of keeping them in step with the updates on the Galaxy Nexus (some kind of manpower extravaganza), you then have to distribute them to the phones. This should, however, be easy(er), as people with the AOSP option ticked on their handsets should have the motivation to go and download it from the manufacturers website and be happy about the effort the OEM has made thus far.

The problems are:
Manpower = Money, +Jean-Baptiste Queru how many people do you need to employ to get a new version of Android working on the Galaxy Nexus?
Making it hard enough for people not to stumble into AOSP mode without knowing what they are doing
Managing warranties and the subsequent court cases that would ensue from people bricking their phones by accidentally turning their PC off whilst flashing their phones, or a Windows USB driver error like the one that killed my mouse mid-firmware flash last month and killed it to death.

The benefits are:
A minority (compared to the smartphone using population) of people being happy with their handsets
Good press for the company that implements this system first

And after all, there is a phone that just comes pure Google in the first place, so is this really a problem?
+Chris Harrison - It's hard to guess how much extra effort it'd take to do 2 parallel ports of Android. I'd guess that the order of magnitude is 10 man-years, i.e. in the millions of dollars.

However, I'm not even convinced that this is the right way to look at things. Engineers are hard to find, so the limiting factor tends to be supply (i.e. how many engineers there are), not demand (i.e. how much the company is willing to pay them), and from a company's point of view the real question is whether this is the best way to use limited engineering resources.
+Jean-Baptiste Queru Exactly. You need good engineers to get things to work as well. They are a limited resource. And OEMs would much rather spend the time making their own personalised experience better for the 99.9% who use the phone and are happy with it and hope to make it more bearable for the 0.1% who aren't in one go, which I think is something Samsung did this evening, even though people WILL disagree with me.
For me, I want a phone that is always running the latest version of Android. I think this could be solved if manufacturers just released one device per year and US carriers didn't fork them into unmanageable permutations.

It also wouldn't hurt if Google could somehow develop the kernel and drivers for Android completely in the open, so manufacturers could at least have that part close to being solved by the time the AOSP was released.

I do enjoy being able to get under the hood, but I think if they solved the Android update problem, they'd also have spare resources to do these other things for us. Right now they squander their resources on wasteful activities like encrypting boot loaders, etc.
+Jean-Baptiste Queru Sony engineers blogged about a "HAL", and that they basically don't start work on this until after AOSP. If the phone and component manufacturers all have access to the Android kernel source, the HAL should be something they can basically have ready to go prior to AOSP, right?

Also, how does this explain manufacturers waiting for the 4.0.3 code? Did that have a slightly better HAL? I'm struggling to think of good reasons (besides resources) that explain why they wait...
+Ron Waldon - Ah, sorry, I took "kernel and drivers" too literally. There's no firm definition of "the HAL", and specifically there's no firm definition that also falls on git project boundaries. In addition, developing a HAL in public is tricky because it tends to call out future features quite clearly (as a well-known example, the major HAL difference between frooy and gingerbread was the front-facing camera, and if those had been done in public it'd have been known that gingerbread would target a flagship device with a front-facing camera).

The part that was really specific about 4.0.3 is that it had all the ICS APIs (4.0.1 was missing some), plus about 2 months of additional fine-tuning.
I'm learning so much by reading these comments!
+Jean-Baptiste Queru how about developing the HALs as a separate project with the chipset / SoC manufacturers under NDA? Microsoft works with AMD and nVidia when it designed the next DirectX...

So do we call HTC's actions progress towards unencrypted SPLs? The other fly in our ointment is closed-source drivers that break with new Android kernels. Is there anything Google can/will do to endorse/enforce better drivers and officially safe root/flash methods?
Samsung had closed source drivers on the GSII, which made it a heck of a job to get the Bluetooth working on CM7 if I remember correctly... The chip had closed source drivers. They do make things awkward to hack around with. Then again, they are in the business of making money. There are that many companies involved in actually making a handset in today's market. In the GS2 you had mostly Samsung components, but the audio chip was from Yamaha, the camera was from Sony, the Bluetooth I can't remember etc, they all have margins to maintain and open sourcing the drivers is just that little bit extra work that eats into those margins. Even with that said, most of the drivers were open source, you just can't rely on everyone to do the same thing.
The HTC Rezound has an S-Off method. I did it to mine. It does work. Check the xda rezound forum.
Sorry to hijack but: Can someone provide a URL for the official support channel for ROM Manager/CWM?
I appreciate HTC's effort with their unlock, truth be it does allow dev to do what we wanted. I was happy with their unlock, much happier than I'll be with any Motorola phone. I am greatful to all the HTC hackers who always manage to S-OFF these things and if I have to wait a little bit for S-OFF it doesn't bother me as HTC's unlock fulfills the needs we have to root, flash and run custom ROMS. That's my two cents! :-)
I thought the issue was that you still couldn't run custom roms despite the unlock. They need to be signed still.
I also have the Rezound and hackers got S-OFF like a week ago. But custom kernels and ROMS have been possible since HTC gave us unlock which let's us flash unsigned system, kernels, and recovery. Only catch for unlock is that kernels and recovery must be flashed via HBOOT. A minor inconvenience for those demanding a custom setup like myself. 
I did compare the Rezound to the Nexus before I made my purchase and I was not impressed by the Nexus. Overall I felt the Rezound was the better device and the software that the Nexus had that I did want will eventually make it's way to the Rezound. 
These types of decisions from manufacturers just reinforce my latest choice to go Nexus and future choice to never buy anything but a Nexus.

That is all I recommend to people.

I hope more people vote that way. If a trend develops maybe more manufacturers will support aosp. Something tells me that they won't make that connection.

I am surprised there hasn't been at least one manufacture that hasn't tried to support aosp on a phone at the retail/consumer level.

Wouldn't it be easier to take aosp and work on the hal then skin/customise/hal?
I can tell you exactly why they don't support AOSP. And that is because of competition with other manufacturers if 1 of them come up with a really neat idea they don't want the other to be using it. Because the hardware alone any of them can get and they can each copy each other's hardware per device so the software is the only thing really about the phones that is unique. To say we should be AOSP is to say hey we should all be the same just like apple, unique this is what makes android stand out from an iphone. I personally could care less about most of the overlays that the manufactures put on top of the android. The open source community having issues putting AOSP on a brand new phone is not an issue with the overlay it's an issue with the underlying code that is tied into the system files that those companies did not release, thus breaking the stock experience. And that is the problem for the overlays are tied into the system so deeply that they cannot be removed without breaking the entire system.
Add a comment...