Database Users

building a kernel with device driver

Hi,
I am new to the android development and a bit confused from all this (root, no root etc).
Say I want to write a new kernel driver to handle keyboard input, and want it to run only on my phone. And my phone is not the developer phone, nor exploitable for root privilege escalation.
Can I download the source files and compile a new kernel with my driver? I guess I cannot use the Android sources, but need my phone specific branch. e.g if I own an HTC Hero I need to get the specific sources from HTC, and they don't publish kernel sources for all their models...
But if I found the source, add my sources and compiled it, It should be easy (and legit ) to load the new image to the consumer phone right ?
Thanks
Roee

More or less that is correct. The source code will contain the license terms, if it says GPL then you are golden. If you get the source from a questionable route and it's not necessarily "public" then it goes into a gray area. Generically speaking, if you get the Android source, and the source code for your keyboard, build an image with it, flash it to your phone, then you are perfectly fine. If you choose to redistribute that code that you mashed together, it's arguable you'd then also have to publish your mashed up code or at the very least the 2 sources you used to mash it together. Mash is the best word I can think of right now
-Chad

Thanks for the reply Chad.
If the software is GPL, and I don't intend to publish the code, I just want to play and check couple of things.
I wonder if i can only compile a new keyboard driver (for example), and just load the ko file somehow without flushing the whole kernel.
I don't have much experience in the linux world, but I would guess it will be something like :
get the branch from the android git
compile a new kernel object for the keyboard
use adb to load the ko file to the device
insmod the new device
somehow remove the current keyboard device and map a new device with the new kernel driver
is this the correct flow ? is there example of how to do it somewhere ?
Cheers
Roee

Ok, I think I have a little better understanding after I played with my G1 today...
So now I understand how to enumerate all the devices in the system, and find the proper devices (e.g using cat /proc/bus/input/devices , or in /devices/virtual/input/ ), but I fail to understand how to replace the proper lkm module. When I run lsmod, the only module loaded is the Wlan module.
How can I find which file is responsible for the keyboard and replace it with my driver? Or must I recompile the whole kernel in order to replace the driver with my modified driver?
I guess it became an easy linux questions.... (just not easy for me )

Building the Kernel from Samsung's Open Source Site?

Has anyone successfully compiled the kernel and opensrc directories from the download from Samsung's Open Source site? I am running into compiler errors for things like xt_CONNMARK.c since the file doesn't exist in the source tree. Is the Galaxy i9000s download actually compilable, and is it actually compatible with the Captivate?
Thanks,
-Atin

Oh cool, I had no idea they had the source available. Samsung just got a lot more awesome in my book. I'll be looking into this when I get back to a computer, and hopefully devs can do something interesting with it.

From my understanding of previous Samsung phones and there source code its that the source code provided is not complete. Anything proprietary is not included which includes some drivers and some extra bit of code.

I don't know if they skipped stuff but I do see binary modules, so maybe they did put every thing out, just didn't open source every thing. Given that we can still link the binary modules, this shouldn't be a problem just like under linux. My problem is more simple, the danged code won't compile because either the config or the dump itself is incorrect (missing files like xt_CONNMARK.c which is gone in later versions of the kernel, but should still be present in what they dumped).

atinm said:
I don't know if they skipped stuff but I do see binary modules, so maybe they did put every thing out, just didn't open source every thing. Given that we can still link the binary modules, this shouldn't be a problem just like under linux. My problem is more simple, the danged code won't compile because either the config or the dump itself is incorrect (missing files like xt_CONNMARK.c which is gone in later versions of the kernel, but should still be present in what they dumped).
Click to expand...
Click to collapse
If they handled the Galaxy S like they do other phones then I believe Eugenes comments apply here
http://forum.androidspin.com/showpost.php?p=12840&postcount=13

Vendor.img info

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?

Upcoming Kitakami Platform changes - should I wait or?

Hello,
humberos mentioned in irc this morning that I shouldn't use the Kitakami tree as they were being changed soon.
I just wanted to ask here because I can't leave IRC connected while AFK at the moment.
Are the changes moving the tree from /device/sony/kitakami to /device/sony/kitakami-common?
and, also: Should I wait for a device tree to be made for the Suzuran instead of trying to build one that I started with the Bootable Recovery?
I have an AOSP base working for it, but it was mashed up between the 7.0.0 R32 build instructions on the Sony Developers page, and the 7.1 branch for Omnirom/android_bootable_recovery.
I would still like to attempt to build a device tree to use as practice, and flash the entire OmniROM image to my device if I manage to successfully build the entire image.
I was able to build the kernel out of the 7.1 Omni - using msm8994-perf_defconfig and also aosp_kitakami_suzuran_defconfig, but I'm pretty sure that there are some projects in my build environment that are in the transition phase (of what I mentioned above with the "kitakami-common" changes) so I don't think I have everything linking correctly to export the kernel to the correct output directory.
I'm still new to this, (I'm a student) but I've been able get the TWRP recovery working and flashed to my device in the last 2 weeks (having zero experience with Linux and Ubuntu beforehand), and sort out the busybox/toybox problems with unzip... I thought changing my project from just a 'Recovery' to the entire System, Kernel and Recovery would be good practice and actually get me involved with some programming, instead of just finding premade templates and copying them and fault finding.

Xposed x86_64 for Yoga Tab 3 Pro

Hi xda,
I've been working on building Xposed x86_64 for our tablet and, even if it's not working yet, the results look promising to me
The tablet is not booting, which could sound really bad, but actually, after applying some required patches to the original rovo89 code (https://github.com/rovo89), there are no scary errors in the boot log (i.e. kernel panic, raw level, art related, native code errors). :fingers-crossed:
The current issue is related only to some odex files not correctly generated for some system packages, which leads to a non booting UI, even if the tablet is actually up and running.
I will keep on working on it, but it would be great if someone here on XDA would be interested in helping me ( @alquez what do you think?), since there is not a lot of documentation and @rovo89 is quite busy.
Just write to me if you are up for it.
PS: here is the boot log with the failure I'm facing in the latest version I built: https://gist.github.com/Gia90/f1cc9170f423883a9384205305f39ce7

Any progress?