Just seen that they've ported Ice Cream Sandwich to the Nexus One.
'They've' done this using the SDK to create a ROM.
Could someone give an overview of how this works? (How you use the SDK to create a ROM)
Why it allows some parts to work but then other bits (like wifi) don't work?
The SDK includes a system.img which contains the bulk of the phone's firmware. Beyond that, the important parts of firmware are the boot loader (which is hardware specific, and not Android-release specific), and the kernel (which is configured for the hardware, though there could be some Android version specifics in it).
Most likely, they just took pieces from the system.img and were able to get an acceptable boot. This generally results in some parts (like wifi, as you mentioned) not working, due to differences in the requirements between the older kernel and the newer system image.
A probable workflow is:
Get the SDK and install it and make sure that it is able to compile programs
Porting means "rewriting system-specific modules to get the whole system working in the new plataform". In a well-designed system, there is a clear separation of what is a system-dependent module (like, e.g., writing bytes to mass storage) and what is a higher-level module (like, e.g., writing to a file). The level of separation and abstraction the underlying system must provide is decided by needs of the operating system (in this case, Android)
The ROM itself is probably a binary image which gets loaded in RAM by the bootloader (and this is why the bootloader is hardware specific). The bootloader then transfers the control to the RAM image which is compiled and built by the SDK in such a way that it contains binary code that the particular processor of Nexus One understands.
Related
I've always liked cheap smartphones ($ 50) because with little money I can have a powerful system with lots of sensors and things like that. So I wondered if it was possible to use the hardware without using the very limited android APIs, programming it at a low level then, of course with the root. In particular I wanted to see how the LTE module worked and experiment with this having full control, the Android API does not allow it to do much.
UPDATE: I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
The first layer of software for the phone is the bootloader. It tells the processor what partition to load into memory for executing the kernel. This is the level that is usually blocked by manufacturers because of greedy corporate reasons that are beyond the scope of this site.
The second layer of the phone is the linux kernel. Rooting is the process of gaining root user access to this layer. Root is the main administrator user account that has permission to do anything to the device. Accessing this layer is what most people refer to rooting. A large portion of the kernel is written in C, with other parts in c++. What happens at this level is where all the magic is. For most phone this is where the code for the modem resides. Talking to this can usually be done via at commands of serial. Sensors are also programmed at this level and communicate via drivers. Root access is not normally needed to read sensor data, its just a case of permissions usually.
The next level is the android operating system, the java instance runs on top of that, which in turn executes the android operating system. This is the portion that most users will see and is primarily written in java. In reality you can run any kind of user interface at this level.
A very brief view of android apps.
The android api provides a way for java developers to write "apps" that communicate with the kernel and access different parts of the phone's hardware. These apps can also be written using c++. Only until recently has google integrated c++ into android studio, but the most common and still most effective method of doing so is using the QT framework.
It's a bit problematic.
Hardware manufacturers do that actually.
Take into account that Android is Linux much like other distributions.
The manufacturers develop hardware and then compile a version Android that sits on top of it. Each Android compilation is specifically tailored to the hardware and equipped with drivers that enable the main OS access to the different hardware capabilities.
For example, some tables will tweak the Android OS to not support cellular communication because they decided to cut costs and deliver the tablet without a cellular module.
From here you have 2 options:
To hack a specific hardware and understand how the OS communicates with the hardware.
Find hardware manufacturers that release some/all of their Android OS code. This is a much simpler way as you can both learn and extend the Android OS for that specific device.
An example of the 2nd way is Sony who has AOSP that allows low-level access to some of the Sony devices.
Also, there is always the Android NDK which gives you a more low-level access to Android but you are still constrained by the KIT API so I'm not sure it will help you.
I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
I want to modify the system apps running on my specific phone. I am stumped about some important steps on how to do that - see my questions further below.
N.B.: I am not interested in deploying these modifications to other phones. Instead I want to play with the original code and improve it. Hence "create your own system app" is no sufficient answer.
Background
I am just starting to get into Android development (have sufficient Java knowledge, though). There are plenty of great tutorials out there (e.g. here and here) but they all seem to cover user application development. I'm more interested in getting (a little) "closer to the metal". Unfortunately I am unable to find good sources teaching how to do that.
Example
As an example let's say I want to modify how the built-in brightness control works (e.g. changing the minimum) or want to add features to the call screen (e.g. "Send SMS instead" when the line is busy).
Specific Questions
I obviously need these things to get started...
Sources
The sources for (parts of?) the OS running on my phone. This is the part that confuses me the most. Can I just download the official sources or is it likely that my vendor made modifications?
In my specific scenario (I use a Fairphone), could those modifications be contained in any of these sources:
some core apps deployed by the vendor
the image binaries (some way down the page)
sources for the Linux kernel and some other libraries
Tools
I really hope to stay in Java-land. But either case I need a development (I hope to use Android Studio or Eclipse ADT) and a debugging environment (I hope the Android Virtual Devices suffice).
Is it a valid assumption that I can use those tools for system apps or are they usually implemented in C?
Process
Assuming I can download the official sources and get started with, e.g. Android Studio. As opposed to developing a user app, do I have to do anything special to emulate the modified system app on AVD?
I'm asking because I assume that AVD already runs an unmodified version of that very app.
I am just starting to get into Android development (have sufficient Java knowledge, though). ... I'm more interested in getting (a little) "closer to the metal".
You can of course follow your own bliss, but you may find it pretty frustrating to learn Android development by hacking on the OS itself. You'll find yourself doing a lot of OS debugging and working with harder-to-use tools than normal.
Example
As an example let's say I want to modify how the built-in brightness control works (e.g. changing the minimum)
I realize this is just an example, but this could be a tough one, because there are a lot of things that contribute to brightness control -- there's the app with the UI that sets it, but that talks to the framework and ultimately the driver for the hardware that actually deals with brightness curves for the display, in coordination with the ambient light sensor.
or want to add features to the call screen (e.g. "Send SMS instead" when the line is busy).
There's a dialer app, but implementing a feature like that will be...difficult, provided it's even feasible. I don't know offhand whether that sort of call state is available to the API.
Specific Questions
I obviously need these things to get started...
Sources
The sources for (parts of?) the OS running on my phone. This is the part that confuses me the most. Can I just download the official sources or is it likely that my vendor made modifications?
If you're replacing system apps, you'll need to run an OS signed with debug keys; you don't have access to the signing keys for the installed system apps on a retail build of the OS that would enable you to replace them. That will mean either getting a debug-keys installation or building it yourself from source, and flashing it to your phone. I would most strongly discourage you from using your daily phone for this sort of work -- you don't want it to be bricked when you need to receive an important call.
If you're not running a Nexus phone, then yes, your vendor has made modifications. The system apps are probably modified, and you almost certainly won't have access to the closed source of those apps. Also, there will be closed-source device drivers that are essential to the operation of the OS that you won't have access to. If you're trying to get AOSP Android up and running on such a device, as an individual hacker it's at best very, very difficult. If you're willing to use something like CyanogenMod, you could look to see if (and to what extent) they support your hardware.
If you are running a Nexus phone, then it's a goal of the AOSP project to try to have the OS bootable on select Nexus devices, though you won't necessarily enjoy the fullest functionality of the retail OS build, depending on the state of drivers -- even Nexus phones can have closed-source drivers and bits that make life more, um, exciting for building with AOSP.
In my specific scenario (I use a Fairphone), could those modifications be contained in any of these sources:
some core apps deployed by the vendor
Almost certainly
the image binaries (some way down the page)
Not sure what you mean by that
sources for the Linux kernel and some other libraries
It's unlikely there are significant modifications to the kernel itself, though vendors sometimes do...interesting...things with system configuration. I already mentioned device drivers. Vendors also have custom implementations/modifications of some framework APIs.
Tools
Vendor-specific tools are rare.
I really hope to stay in Java-land. But either case I need a development (I hope to use Android Studio or Eclipse ADT) and a debugging environment (I hope the Android Virtual Devices suffice).
Much of what you want to do can probably be implemented in Java, though it depends on how close you're getting to the hardware which can be difficult to know.
Is it a valid assumption that I can use those tools for system apps or are they usually implemented in C?
The "system apps" are implemented in Java, but again, you sort of have to know where the dividing line is.
Process
Assuming I can download the official sources and get started with, e.g. Android Studio. As opposed to developing a user app, do I have to do anything special to emulate the modified system app on AVD?
That's actually different, because you're dealing with an emulator system image instead of a phone image. The emulator system images are completely open source, and you can build them from AOSP.
I'm asking because I assume that AVD already runs an unmodified version of that very app.
That's correct.
To come back to my initial point, if you read between the lines of what I'm saying, I won't tell you it's impossible, but the difficulty ranges from freakin' tough on the easy end to spend-years-of-your-life on the hard end. If you really want to proceed, your best bet may be to buy the phone that's best supported by CyanogenMod and work that angle; there's a more active developer community there to help you. I know you're more excited about trying to customize the OS than you are in making a user-space app, but you'll experience less frustration with the latter than the former.
I hope this is the right place to ask this.
I would like to work on an Android build with a completely custom OS. I was inspired by this project that ported Inferno to Android.
I would like to do this legally (obeying all terms of service and what-not) if possible, and I have no problem with disclosing my source code to a carrier.
Do any of you have experience with this? What are the considerations for getting a custom build to work with a carrier?
Since I am building on Android, I probably won't have to worry about cell/3g/4g hardware drivers, and I would like to buy a phone from the carrier anyway just to make sure it will be supportable.
I'm one of the creators of the Inferno project you mentioned. Anyway, making a completely custom OS for an Android phone will be difficult; a lot of the hardware will be undocumented or only drivable by Linux binary blobs. What we did (and what Boeing has also done recently for a commercial project) is strip away all the Java from an Android system, leaving a basic Linux upon which you can build your own custom interface. This lets you use all the hardware (since the drivers are in Linux), but everything that the end users see will be your stuff. There are a variety of ways to go from there. Inferno implements a virtual machine, so we can abstract the Linux stuff into our own Inferno-style world.
I don't think there should be any problems with the carriers. We started with a Cyanogenmod ROM and hacked on that; custom ROMs are just fine! I never had any problems, even when I was swapping my little pay-as-you-go SIM card among several phones running Gingerbread, ICS, and Inferno.
Head over to the AOSP source, and clone it. Strip out what you don't need in your branch and begin the kernel patching! You'll need to modify the kernel in portions to make it compatible (fairly) with the device you're on. The Android kernel is in fact a very close cousin of the Linux Kernel, and in Linux 3.3, they've begun merging the two. After this is done, write your interfacing mechanisms (be it a display, web interface, etc) and you can test it out on your platform.
How open is the source code of android phones? I cannot think of a way that manufacturers can close their drivers, because they have to conform to the GPLv2 as the License of the Linux kernel states. Or do they use write a large part in user space code, where they can choose their own licence?
The information I'm trying to get here is: How difficult is it to get a "cheap" smartphone (htc wildfire-s) and run Linux on top of it full featured. What I mean is every hardware feature is easily accesible without having to implement your own drivers and reverse engineer the device (assuming that the device is rooted).
HTC has the developers area:
http://htcdev.com/devcenter
The kernel sources for the HTC wildfire you can also download there:
http://htcdev.com/devcenter/downloads
Note that not all the functionality is included in the kernel. To add functionality to your system you also have to install basic programs like a shell.
The Android system image already contains all necesary programs to run your system and som Android stuff which is not needed for a Linux-only system.
As an alternative you can have a look in the android source and remove all the unwanted programs from your custom android build.
http://source.android.com/source/initializing.html
I think I found my answer at last. A lot of firmware of a lot of android phones is delivered binary only. Which makes it less open. If I want to run GNU/Linux on top of a stock phone I run in a lot of those issues. See Richard Stallmans article on how free android is:
Is Android really free software?
There is also a project Replicant which tries to create a free (FSF definition of free) android based stack.
I am new to android technology. Can somebody answer few of my question:
What are the similarities and differences between linux kernel and android kernel?
What is the minimum hardware requirement for mobile device to have android support?
Whether it is required to have a touch-screen mobile to run android technology?
Q1. The Android kernel is the Linux kernel with added device drivers for the hardware components that are not supported by the pure Linux kernel. However, there are also other differences. Quoted from here, and here:
The Android kernel code is more than
just the few weird drivers that were
in the
drivers/staging/androidsubdirectory in
the kernel. In order to get a working
Android system, you need the new lock
type they have created, as well as
hooks in the core system for their
security model. In order to write a
driver for hardware to work on
Android, you need to properly
integrate into this new lock, as well
as sometimes the bizarre security
model. Oh, and then there's the
totally-different framebuffer driver
infrastructure as well.
You may also refer to this page for an opinion on this matter.
Q2. You may take a look at the Android 2.3 Compatibility Definition
(I haven't read it). For 3.0 the requirements are (quoted from here):
1GHZ processor, 512MB RAM, a display
screen that is at least 3.5-inches in
size
Q3. No, your device does not need to have a touchscreen to be compatible with Android. Refer to the compatibility guide above, but this is also evidenced by the first Android testing devices, that were running android (picture).