Skip to main content

Unlocking the boot loader | unlockbootloader.sonyericsson.com

It is possible to unlock the boot loader for certain releases of Sony Ericsson Android? phone models from 2011 and onwards.

Please note that you may void the warranty of your phone if you unlock the boot loader. Sony Ericsson can then no longer guarantee the full functionality of your phone, and will not be responsible for any unsigned custom software being flashed to the phone after the boot loader is unlocked. Certain functions in your phone might cease to work, and performance might not be ideal. You might also damage your phone permanently. In the worst case, unlocking the boot loader will cause physical injuries or material damage, for example, due to the phone overheating.

Certain content on your phone may also be inaccessible due to the removal of DRM security keys and the secure user data partition while unlocking the boot loader.

Therefore, you should only unlock the boot loader of your phone if you are an advanced user with good knowledge of the technology and risks involved. We strongly recommend that standard users NOT unlock the boot loader, as it is not needed. We are proud to deliver great phone experiences through our rigorously tested and official software releases.

See the Which phones-page to see what phone models are supported by this service.

If you are fully aware of the risks involved, and have a deep knowledge about these technologies, continue to the unlock boot loader instructions page. You should be aware that unlocking the boot loader will not give you root access. The only way to get root access is to flash a custom ROM with root access.

For any questions, Sony Ericsson will monitor this thread on Google groups. However, we cannot guarantee an answer for every question asked in this forum.

Please note that there is no turning back when unlocking the boot loader. You will not be able to revert the phone to a locked or original state if you unlock it. Also, if you brick the phone, it is your own responsibility.

It is currently not possible to unlock the boot loader for CDMA phones. We are however working on this.

Start unlocking the boot loader

I really applaud this open stance from Sony Ericsson. I don't think I would risk a brand new Play on this but it's a cool idea anyway.

Comments

Popular posts from this blog

Creating star ratings in HTML and Javascript

I'd searched around a little for some shortcuts to help in doing this but I couldn't find anything satisfactory that included the ability to pull the rating off again for saving. I'd ended up coming up with this rather cheeky solution. Hopefully it helps you too! This is my first post in a while (I stopped blogging properly about 8 years ago!) It's strange coming back to it. Blogger feels very crusty and old by todays standards too.

Make your objects immutable by default

More about the Good Dojo In my post last week , I discussed creating objects that are instantiated safely. Please go back and read if you are interested. At the end of the post, I mentioned that I'd also written the class so it was immutable when instantiated. This is important!!! I feel like a broken record in repeating this but I am sure at the time of writing your code, you aren't modifying your object all over the place and so are safe in the belief that protecting against mutability is overkill. Please remember though, your code could be around for a hell of a long time. You aren't writing your code for now... you are writing for the next fool that comes along (including you) . Nothing is more upsetting that coming back to fix a bug on some wonderfully crafted code to say "Who has butchered my code?!", but often you were involved at the start of the process. You made the code easy to modify, allowing objects to be used / reused / modified without thi

An instantiated object should be "ok"

I've been QA'ing quite a bit of work recently and one common theme I've noticed across both Java and C# projects I have been looking at is that we occasionally open ourselves up unessacarily to Exceptions by the way objects are being created. My general rule of thumb (which I have seen mentioned in a Pluralsight video recently but also always re-iterate in various Robust Software talks I have done) is that you shouldn't be able to create an object and then call a method or access a property that then throws an exception. At worst, it should return null (I'm not going to moan about that now). I've created an example below. We have two Dojos, one is good and one is bad. The bad dojo looks very familiar though. It's a little class written in the style that seems often encouraged. In fact, many classes start life as something like this. Then as years go on, you and other colleagues add more features to the class and it's instantiation becomes a second