Develop Bugs

5/6 <DEV> [WIP] {ROM} 'AOSEP' Community Development "Build your own cm7/cm9/?"

5/6 <DEV> [WIP] {ROM} 'AOSEP' Community Development "Build your own cm7/cm9/?"
AOSEP V2.5​
Android Open Source Education Project​See post #191 for updated scripts
By following these instructions and/or using this set of files, you
proceed at your own risk. Under no circumstances would you hold
dizgustipated or anyone, except yourself, responsible for any negative consequences.[/COLOR][/I][/B]
################
***********************
################
I came across a "new" way of thinking over on a different thread, and have decided to adopt it.
I will still be developing and releasing roms,
but
Basically, I want to get you more involved in developing.
Allow you the chance to learn, contribute, and take pride in your accomplishments.
Possibly further the development of android, and see a whole new world open up to you.
That's why and how I got into developing. In was very curious, and unhappy with current rooms and update frequency. Or just with features available.
see post 2 for more info on the philosophy
I'd like to share a little script I found, and modified (with permission, and is still a work in progress) to automate the sync/build/package cycle, and to push the XDA community to get involved on a deeper level.
This whole process is designed for the latest stable Ubuntu (10.04/11.10), though it might work with Debian as well (or even other distros, if you have all the prerequisites already installed).
Alternatively, on tbe last post, you will find a handy script that gives a good shot at automating the whole prerequisites ordeal.
Place it in your root directory, navigate to it in terminal and type
Code:
Code:
sudo ~/installer.sh
Any brave souls willing to try?
I know you're impatient to get started, this script also contains a little guide, so check it out. I haven't had much opportunity to test this script because it takes so much time to start from scratch, so please help me out!
As of now, I have made many full builds this way, as well as a few incremental updates. Feel free to modify the MIT-licensed script. There are two time-consuming steps (4 and 6), so I'd recommend planning accordingly. Also make sure you have plenty of space on your disk; my working directory currently contains about 23GB.
0. I prefer you to start from scratch, (we want a clean start) as follows:
1. Make a folder for all your Android-building needs.
In your home directory, make a folder called "android"
Code:
Code:
mkdir android
and drop the text file in there, (in the new "android" directory, named Makefile (with no extension).
(Alternatively, you can open the make file, and edit the repo init to your preferred sgt7 repo sourcecode. Also, if you change repo address, you will need to make Bacon, instead of make package.)
Then open your favorite terminal app and navigate to that folder.
Code:
Code:
cd android
2. If you don't have any of the tools installed yet, and you're on Ubuntu, do this:
Code:
Code:
sudo apt-get install build-essential
sudo make apt
3. Initialize your working directory:
Code:
Code:
make init
4. Fetch the source code:
Code:
Code:
make sync
nb: It might take a while to fetch ~5.7GB of code off the Internet, depending on your connection. It might also hang, in which case you gotta stop the process, and retry (make sync) until you have everything. When you retry, you might want to do `make sync J=4` to reduce the concurrency. If it then complains about corrupt repositories ("not a repository"), you must delete the corrupt repositories and retry. You'd know it's frozen if "Fetching projects" does not progress for a minute or so.
(after a sync, seeing:
if ! grep -q "<stddef.h>" /home/diz/android/system/external/mesa3d/src/glsl/linker.cpp; then \
sed -i '1i #include <stddef.h>' /home/diz/android/system/external/mesa3d/src/glsl/linker.cpp; \
fi
is normal, it is patching so you can build)
5. (This step is done for you in the sync)
Alternatively, if you are looking to get deeper into dev-ing, you can back up the files, boot into CM7 and do the following to start making your own device files.
Plug in your SGT7 via USB, boot into CM7/BOCA RC1, and make sure debugging is enabled... to get some vendor-specific files (proprietary bits from Samsung and prebuilt bits from CyanogenMod):
Code:*
Code:
make vendor
*This will overwrite my device files, if you do not wish to do so, move on to the next step.
6
Build that stuff:
Code:
Code:
make build
This takes a while, depending on your hardware... perhaps a few hours. It's best to do this step overnight.
*if you error out in the build on: android_reboot.c, download THIS and replace the file already in android/system/system/core/licutils(android_reboot.c)
7. Save a snapshot for later:
Code:
Code:
make snapshot
This is actually required for the next step. But don't worry: snapshots are incremental, so they don't use too much space; and it's safe to remove any snapshot except "current".
8a. Package it up:
Code:
Code:
make package CLEAN=1
Check the snapshots directory for your shiny new update.zip
8b.Or simply make Bacon.
Code:
make bacon
9. It's even easier to keep your source up-to-date:
Code:
Code:
make sync
make build
make snapshot
make package CLEAN=1
(unsigned)
or
Code:
make package CLEAN=1 SIGN=1
(signed)
Or
Code:
make bacon
This makes a GSM P-1000 flashable zip, you can easily exchange the zImage for a L or N kernel, in the zip, & then flash in recovery after clearing user data, dalvic cache and cache then flash ICS gapps
10.
Be joy full and post a screen shot or a build.
11.
Continue developing/contributing to the android community
... and don't forget to thank FatTire and inportb for allowing me to alter and post this script, which made this possible

5/6
Reserved for instructions on how to use different sourcecodes
And things of that nature.

What works if you start building here:
The beginnings of the stuff that makes it BOCA, which include:
auto beagleboard patch
auto cherry pick of cyanogen vold that allows the use of the 4th vold partition (this has been merged)
A bit more HW accel
better video playback in YouTube and your movie files.
better quadrant score
better linpack score
address space layout randomization, as part of the install
WIFI (but takes a long time for the first connection)
Bluetooth
GPS
Accelerometer
Gyroscope
Light
Magnetic field
Orientation
Battery stats
Sound and sound recording
root
a bit of HW acceloration
better video playback (encode/decode)
recent apps button
Auto rotation (for launcher rotation, enable it in CM launcher)
Gallery
Flash
DSP Manager!!!
USB pc trickle charge
Market
Voodoo Sound
sdcard mounts are: internal (sdcard) and emmc (external sd)
USB PC mounting
NOT WORKING SO FAR:
Phone?
Things may/may not be added at some point in the future. You should have no expectations that they will. Anyone who asks for an ETA for something or other gets collectively stoned by the crowd.
Hopefully this project will push some to help fix a few things, as all that is on the NOT WORKING list is NOT WORKING in all and any SGT7 CM9 ports
DO NOT POST BUGS!!!!
ONLY POST "FIXES, OR THINGS THAT HELP FURTHER DEVELOPMENT
THANKS:
JT1134
Fattire
inportb
Spacemoose1
Teknomancer
Github
AOSP
Google (both its search engine and os)
Especially all the sgt7 tab developers
& all android Developers
This list could go on forever!​

Diz, you did it again. Cheers.
Sent from my GT-P1000 using xda premium

massive thread update
REMEMBER, this is still a WIP

We are so lucky to have you here diz. I will send my fourth donation to you at the end of this month! Thank you for educating us so we can learn how to contribute. I would not be surprised if this will be adopted by the whole XDA-community.
EDIT: Happy birthday!
EDIT 2: Is this related to the repo problem at the top of post #1? http://pastebin.com/Hb5rAUFr
Sent from my GT-P1000 using xda premium

stekarson said:
EDIT 2: Is this related to the repo problem at the top of post #1? http://pastebin.com/Hb5rAUFr
Sent from my GT-P1000 using xda premium
Click to expand...
Click to collapse
EDIT
open the makefile
look for these lines:
Code:
else
cd ${SYSTEM}; repo init -u git://github.com/CyanogenMod/android.git -b ics
endif
curl http://pastebin.com/raw.php?i=AGP6wn42 > ${SYSTEM}/.repo/local_manifest.xml
## removes old files and allows init to start from scratch
change it to:
Code:
cd ${SYSTEM}; repo init -u git://github.com/CyanogenMod/android.git -b ics
endif
## removes old files and allows init to start from scratch
then go to android folder, press Ctrl H (to see all the files) and delete everything except the make file.
Then:
in your terminal, in the android directory:
Code:
make init
make sync
Now get the needed files, from the location on the top of the OP.
Place them.
THEN:
Code:
make build
make snapshot
make package CLEAN=1
As soon as its second party verified, I'll update op
From http://review.cyanogenmod.com/p/CyanogenMod/android_system_vold
* branch refs/changes/77/11277/1 -> FETCH_HEAD
# Not currently on any branch.
nothing to commit (working directory clean)
make: *** [sync] Error 1
That just means it has been merged, there is no longer a need to cherry pick it.
Ill take the code out.
This does not ruin your sync.
simple proceed to make build

http://
www.teamovercome.net/common/xDA-Badge-ProudUser.png[/
IMG][/URL]
[B][url]www.teamovercome.net[/
url][/B]: [I][COLOR="Red"]Home of The Overcome ROM
Overcome Kernel ![/COLOR][/I][/LEFT]​

op updated with new directions and a new makefile.
this way we can sync pure cm9 source, and add the vendor and device files of our choice.
And we also don't ever have to worry about "make sync" conflicting with any of the device specific files and causing a sync error.
Although, at this time, I do recommend the files listed in the instructions to get the results implied in post #3

update 1/9
uploaded new makefile:
removed cherry pick vold, it was merged, so no need to clutter the script and get empty repo errors.

First of all thanks for your great work. Im trying to use your guide but got stuck at the "make init" command. If I use this command I get the following error:
Code:
rm /home/lesley/android/sign.tgz /home/lesley/android/update-lite.tgz
if ! grep -q "0x2080" /home/lesley/android/.android/adb_usb.ini; then echo 0x2080 >> /home/lesley/android/.android/adb_usb.ini; fi
cd /home/lesley/android/system; repo init -u git://github.com/CyanogenMod/android.git -b ics
/bin/sh: repo: Permission denied
make: *** [init] Error 126
Nevermind deleted all the folders in the android folder except the make file. After that I did "make init" and it run great.

The make file chmods the bin folder,
Sometimes a reboot is needed for it to take effect.
But sometimes you will still get an issue with bin permissions or paths
Then try this in terminal in the same directory you use the make init command.
Code:
PATH="$HOME/bin:$PATH"
Then
Make build as usual

dizgustipated said:
The make file chmods the bin folder,
Sometimes a reboot is needed for it to take effect.
But sometimes you will still get an issue with bin permissions or paths
Try his in terminal in the same directory you use the make init command.
Code:
PATH="$HOME/bin:$PATH"
Click to expand...
Click to collapse
Thanks, I deleted the folders/files in the android directory except the make file. After that it worked great it's now syncing.

Thank you so much diz !
Making my own CM9 is so damn exciting !!
looking at the instructions , looks easy
Thanks again .
To do list on 15th Jan ( after exam )
Make my own CM9
Diz you are the best !!
Oh btw sorry for this useless post !

I'm stuck at step 5.. how can I download these files....
And what files should be in these folders
Sent from my LG-P999 using Tapatalk
---------- Post added at 05:44 PM ---------- Previous post was at 05:29 PM ----------
tried to follow from step 5 and got this....
http://pastebin.com/vRw7U0Zq
Edit: downloaded whole commit from your git. Included is android folder, device_Samsung_galaxytab folder and Samsung/galaxytab folder
Using cdesi cm9 folder as reference, copied contents in device_Samsung_galaxytab folder. Into Samsung/galaxytab folder then.put that into device folder under android/system then ran step 6b and now it seems to be building since.I have a out folder atm
Edit 2: got same error again. Can you be more specific in your instructions?

Just for p1000 tabs, right? Or for p1010 too?

samcortez said:
Just for p1000 tabs, right? Or for p1010 too?
Click to expand...
Click to collapse
There wont.be support for wifi only.tab......
Sent from my LG-P999 using Tapatalk

samcortez said:
Just for p1000 tabs, right? Or for p1010 too?
Click to expand...
Click to collapse
as the title states, GSM/CDMA?
your device is basically a different device, altogether.
Does your device have cm7 yet?
ayysir said:
tried to follow from step 5 and got this....
http://pastebin.com/vRw7U0Zq
Click to expand...
Click to collapse
yeah thats all part of the original repo error, that i will be fixing today.
But in the mean-time,
navigate to android/system/vendor/cm
open: vendorsetup.sh
add:
add_lunch_combo cm_galaxytab-userdebug
close and save
now make build again

dizgustipated said:
as the title states, GSM/CDMA?
your device is basically a different device, altogether.
Does your device have cm7 yet?
yeah thats all part of the original repo error, that i will be fixing today.
But in the mean-time,
navigate to android/system/vendor/cm
open: vendorsetup.sh
add:
add_lunch_combo cm_galaxytab-userdebug
close and save
now make build again
Click to expand...
Click to collapse
What about galaxytab folder
Sent from my LG-P999 using Tapatalk

The links at step 5 is 404.

FTDI kernel module unknown relocation

Hey guys,
I've spent a few days now researching and attempting to build the FTDI kernel module for my Archos 70b. After following this guide I managed to get a successful compilation. I uploaded it to my device (which was rooted via Paul's root and rebooted into sde). When I attempt to use insmod, I get the following error: insmod: cannot insert '/sdcard/ftdi_sio.ko': Invalid module format (-1): Exec format error. I ran 'dmesg -c' and got the following output: [ 684.472290] ftdi_sio: unknown relocation: 27. I have the usbserial module installed already as well. What is the problem here? I'm assuming by relocation it means it's loading the module into the wrong part of the address space? I could be very off I'm new to this process. I just want to thank everyone in advance for their help, this is my first post and I've used these forums extensively over the last few days. You have a great community here.
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules

whistlinwilly said:
Hey guys,
I've spent a few days now researching and attempting to build the FTDI kernel module for my Archos 70b. After following this guide I managed to get a successful compilation. I uploaded it to my device (which was rooted via Paul's root and rebooted into sde). When I attempt to use insmod, I get the following error: insmod: cannot insert '/sdcard/ftdi_sio.ko': Invalid module format (-1): Exec format error. I ran 'dmesg -c' and got the following output: [ 684.472290] ftdi_sio: unknown relocation: 27. I have the usbserial module installed already as well. What is the problem here? I'm assuming by relocation it means it's loading the module into the wrong part of the address space? I could be very off I'm new to this process. I just want to thank everyone in advance for their help, this is my first post and I've used these forums extensively over the last few days. You have a great community here.
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
Click to expand...
Click to collapse
Hi !
First be sure that you have the same version kernel->module , run modinfo module.ko and vermagic need to be the same with kernel version !
- if it's ok you can try strings module.ko and than insmod module.ko !
( but can be many things wrong in your process of compiling module !!! ) Good luck ...

I can confirm that the versions are the same, I was using an incorrect version before and dmesg was complaining. I've since compiled the module for the right kernel version and now dmesg only gives me the "unknown relocation: 27" error.
I ran the strings command, it outputted over 4000 lines. I'm not quite sure what you could gain from the output but I can attached the text file I piped it to if that will be helpful.

whistlinwilly said:
I can confirm that the versions are the same, I was using an incorrect version before and dmesg was complaining. I've since compiled the module for the right kernel version and now dmesg only gives me the "unknown relocation: 27" error.
I ran the strings command, it outputted over 4000 lines. I'm not quite sure what you could gain from the output but I can attached the text file I piped it to if that will be helpful.
Click to expand...
Click to collapse
Ok!
May be you have a problem when your module "export symbols" -> take a look into Module.symvers ... and see if something export !

I looked around and couldn't find Module.symvers either in the source code or on the actual device. Do you know where I might be able to find it or how I can create the file myself? When the module is compiled, make throws a warning about not being able to find it. I think this is the problem.

whistlinwilly said:
I looked around and couldn't find Module.symvers either in the source code or on the actual device. Do you know where I might be able to find it or how I can create the file myself? When the module is compiled, make throws a warning about not being able to find it. I think this is the problem.
Click to expand...
Click to collapse
Hi !
...maybe it help you => http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html
( module.symvers is created after you run make ( for make module) in directory where you compile module )

I'm not quite sure I understand. I get a warning
WARNING: Symbol fakepath/kernel/Module.symvers
is missing; modules will have no dependencies and modversions.
when I run make in the modules folder. There IS a file created called Module.symvers after I run make, but it is empty; I'm assuming its just a copy of whatever Module.symvers file it is actually looking for.
Has anyone compiled the archos gen9 kernel that might have created this file and can pass it along to me?

whistlinwilly said:
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
Click to expand...
Click to collapse
Hi whistlinwilly
Are you sure you've grabbed the right kernel source - your KDIR says gen9, if your compiling for the 70b you probably need the gen8 kernel source code as I think it's on the Gen8 product line
you can check which kernel version you have by running the following from a command prompt.
Code:
adb shell uname -a
Hope that helps

Hey whistlinwilly,
i don't know if you were successful in the meantime, but here's what i suggest for simple kernel module compilation...
You might refer to my custom kernel thread and check my toolchain, which is ready to rock (only 32bit linux right now):
http://forum.xda-developers.com/showthread.php?t=1328027
To compile custom kernel/modules only, look here as well:
http://forum.xda-developers.com/showpost.php?p=19134490&postcount=8
The archos specific toolchain uses uclibc and is used for kernel and userland.
So if you use stock kernel, but choose a different toolchain (e.g. libc based) to compile your modules, you might run into trouble at some point.
BTW, is it correct that you talk about this device:
http://www.archos.com/products/ta/archos_70b/index.html?country=de&lang=de
Not sure which family it exactly belongs to
If you're talking about this one:
http://www.archos.com/products/ta/archos_70it2/index.html?country=de&lang=de
...the kernel should be 2.6.35 then.
http://gitorious.org/archos/archos-gpl-gen9-kernel
I'm not aware of any config for the A70IT2 though.
Please refer to trevd's suggestion and find out your kernel release first...
Good luck!
scholbert

I had the same problem (Relocation error: 27) when trying to compile a custom kernel module for my Moto xoom running Honeycomb.
I was able to compile successfully by rolling back to Android NDK 5b. I also had to force the vermagic string to read ARMv7 so I know this isn't the right way to solve the problem, but when I compiled with the 5b toolchain, the relocation error goes away and I am able to insmod without error on the tablet.
I would love to know why this works and the right way to get NDK 7 to work with this, if anyone can shed some light??
EDIT:
On further digging and testing- I realize it is not necessarily NDK 5b, but rather the toolchain "arm-eabi-4.4.0" as opposed to using the "arm-linux-androideabi-4.4.3" toolchain, that makes the difference with the "unknown relocation 27" error. It just so happens that NDK 5b is the last NDK that shipped with both toolchains, AFAIK.
It still for some reason likes to compile under ARMv5 unless I force it to use ARMv7 but this issue is probably unrelated- I didn't mean to confuse things with the ARM v5/v7 versus NDKr5 /NDKr7 which don't correlate...
Anyway I hope this helps, or maybe someone else who knows more can help us both!

Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!

the_zuck said:
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
Click to expand...
Click to collapse
Thanks a million, finally got past the relocation 27 error now. Insmod doesn't complain anymore and the drivers load successfully, now to just figure out why I'm getting a backtrace on device insertion.
Thanks for solving my major headache tho

Exec format error
the_zuck said:
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
Click to expand...
Click to collapse
Ok, thanks for the answer. My first post here.
After this got solved. I still have "Exec format error". And! and no errors are display in dmesg. Are there any other places where the error might be displayed? I just created a simple printk("hello world") project.
If i remove the printk it doesn't show the error.
I don't know whether to laugh or cry. I dabbled my self to the brink of madness to solve this. I couldn't find a solution anywhere. Finally solved it after 6 weeks of my time. Probably my boss at work will not be happy if he finds I was working on this instead of working.
And I find the solution here 2 days after I solved it. WOW!!!:crying::crying:
But my saga still continues...

[Q] RIL Development sgh-t999

Hi everyone,
recently I have built and flashed on my sgh-t999 (galaxy S3 US tmobile version) CM11 Nightly. For my pro0ject however I need to modify two libraries of the Radio Interface Layer (RIL), libril.so and libreference-ril.so. I tried to modify the ones in the forlder /hardware/ril/ and build everything again with no results. Any change that I made to those files (such as ril.cpp in the folder libril) would not affect the functionality of the phone.
Finally yesterday I understood that when I build those libraries for the target cm-d2tmo-eng, those files that I have modified are not considered at all! When the libraries are built indeed, the system automatically takes the libril.so and libreference.so present in the vendor folder!
The problem is that those libraries in the vendor folder and already compiled and I cannot modify them. The question is:
Is there any way that I compile those libraries from the source code that I have modified?
Thanks,
brok85

Given that there is a unified D2LTE Build on CM, can you elaborate on what changes you wish to make to these libraries ?
To answer your question, You can do one of two things.
Grab the CM Source Code from the Device Tree of D2LTE. Make your relevant changes and check in the changes if they boot ok on your device. That way those changes will be included in future builds of CM and other Roms that use it.
If you do not wish to do so, then you will have to compile those libraries using C++ Compiler on a *NIX box and replace them in the Vendor folder.

Perseus71 said:
Given that there is a unified D2LTE Build on CM, can you elaborate on what changes you wish to make to these libraries ?
Click to expand...
Click to collapse
Well, as fisrt I just wanted to insert some log to be able to follow the code execution from the logcat or do something similar.
Perseus71 said:
To answer your question, You can do one of two things.
Grab the CM Source Code from the Device Tree of D2LTE. Make your relevant changes and check in the changes if they boot ok on your device. That way those changes will be included in future builds of CM and other Roms that use it.
Click to expand...
Click to collapse
Sorry but I am kind of new on this things. I have already downloaded the source code from the device tree and made my modifications in the files ril.cpp contained in [path-to-android-source]/hardware/ril/libril/ril.cpp. What I did was commenting the whole code within the function RIL_onUnsolicitedResponse() and listenCallback() such that in theory, the phone is not able to display incoming calls for example. However after flashing the re-built android I am still able to receve calls. How can I "check in the changes if they boot ok on my device"?
Perseus71 said:
If you do not wish to do so, then you will have to compile those libraries using C++ Compiler on a *NIX box and replace them in the Vendor folder.
Click to expand...
Click to collapse
I tried to remove the libril.so in the vendor folder and compile again using
# . build/envsetup.sh
# lunch (and select d2tmo)
# mmm [path-to-android-source]/hardware/ril/libril".
The problem is that when I indicate the target after lunch, the compiler looks for the vendor libraries and stop the build. What I am doing wrong?

Sounds like Compiler Dependacy path is set different from the code base. I will look further before commenting.
For when your changes are for the benefit of the community of users, you check in the changed code back to the Device Tree with detailed comments within the code and while checking in.

Perseus71 said:
Given that there is a unified D2LTE Build on CM, can you elaborate on what changes you wish to make to these libraries ?
To answer your question, You can do one of two things.
Grab the CM Source Code from the Device Tree of D2LTE. Make your relevant changes and check in the changes if they boot ok on your device. That way those changes will be included in future builds of CM and other Roms that use it.
If you do not wish to do so, then you will have to compile those libraries using C++ Compiler on a *NIX box and replace them in the Vendor folder.
Click to expand...
Click to collapse
Perseus71 said:
Sounds like Compiler Dependacy path is set different from the code base. I will look further before commenting.
For when your changes are for the benefit of the community of users, you check in the changed code back to the Device Tree with detailed comments within the code and while checking in.
Click to expand...
Click to collapse
Actually this is what I get after deleting
libril.so in vendor/samsung/d2tmo/proprietary/lib/
and after executing mmm /hardware/ril/libril :
No private recovery resources for TARGET_DEVICE d2tmo
make: *** No rule to make target `vendor/samsung/d2tmo/proprietary/lib/libril.so', needed by `/home/brok85/Documents/android/system/out/target/product/d2tmo/system/lib/libril.so'. Stop.
make: Leaving directory `/home/brok85/Documents/android/system'

If u want to build from source, delete the line that copies in vendor-blobs.mk
If u want to copy the blob instead of building it from source, keep the line
It'll be better if u provide us the device and vendor trees links

blackbeard said:
If u want to build from source, delete the line that copies in vendor-blobs.mk
If u want to copy the blob instead of building it from source, keep the line
It'll be better if u provide us the device and vendor trees links
Click to expand...
Click to collapse
I am not sure to understand what should I provide Sorry, as I said I'm kind of new here...
Also, I can not find vendor-blobs.mk...Where it should be?

brok85 said:
I am not sure to understand what should I provide Sorry, as I said I'm kind of new here...
Also, I can not find vendor-blobs.mk...Where it should be?
Click to expand...
Click to collapse
You said you built a cm11 for ur device. So for that you needed the device and the vendor trees. Give the link of those, if they are on the git
And vendor-blobs.mk would be present in the vendor folder under your device folder

blackbeard said:
You said you built a cm11 for ur device. So for that you needed the device and the vendor trees. Give the link of those, if they are on the git
Click to expand...
Click to collapse
Well I have followed the guide in the following page
http://wiki.cyanogenmod.org/w/Build_for_d2tmo
The link from where I have obtained the repository is
$ repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0
and then
$ breakfast d2tmo
blackbeard said:
And vendor-blobs.mk would be present in the vendor folder under your device folder
Click to expand...
Click to collapse
Actually now I think I was able to compile the library following your instructions. Unfortunatly, when I have built and flashed everything in the galaxy S3, I was not able to use the network. Probably some compatibility issue?
When I compiled libril.so, I have obtained it from the folder /hardware/ril/libril which should contain google source code, maybe not compatibale with my device...is it right?
thanks a lot for the help guys

brok85 said:
Actually now I think I was able to compile the library following your instructions. Unfortunatly, when I have built and flashed everything in the galaxy S3, I was not able to use the network. Probably some compatibility issue?
When I compiled libril.so, I have obtained it from the folder /hardware/ril/libril which should contain google source code, maybe not compatibale with my device...is it right?
Click to expand...
Click to collapse
You know, silly question. But just so we can rule out. Did you at any point compiled the CM11 code as is and flashed to the phone ? How did Network behave ? Was everything ok ?
Galaxy S3 is a very open platform with standard hardware and chipsets. So the Default google code should work out of box with it. If you have network issues, then just for kicks you can flash a custom Kernel on top of your compiled CM 11. See how that goes.

Perseus71 said:
You know, silly question. But just so we can rule out. Did you at any point compiled the CM11 code as is and flashed to the phone ? How did Network behave ? Was everything ok ?
Click to expand...
Click to collapse
No silly question at all
I have compiled CM11 as it is and worked perfectly. I could use the network.
Perseus71 said:
Galaxy S3 is a very open platform with standard hardware and chipsets. So the Default google code should work out of box with it. If you have network issues, then just for kicks you can flash a custom Kernel on top of your compiled CM 11. See how that goes.
Click to expand...
Click to collapse
The procedure I have followed is the following one:
1) Delete the llibril.so and libreference-ril.so from the vendor library. These are the pre-compiled vendor libraries that I need to modify.
2) commented the lines from the vendor-blobs.mk that were including those two precompiled libraries.
3) go to android/system/ and run "mmm /hardware/ril/libril" and "mmm /hardware/ril/reference-ril" to obtain the modified libril.so and libreference-ril.so respectively.
4) copied the new libraries just obtained in the vendor folder where the pre-compiled libraries were
5) re-include the lines commented in point 2).
6) run brunch d2tmo
7) flash the .zip obtained
Any mistake?

Perseus71 said:
You know, silly question. But just so we can rule out. Did you at any point compiled the CM11 code as is and flashed to the phone ? How did Network behave ? Was everything ok ?
Click to expand...
Click to collapse
No silly question at all. Yes I have built everything out of the box and worked perfectly. I could use the network.
Perseus71 said:
Galaxy S3 is a very open platform with standard hardware and chipsets. So the Default google code should work out of box with it. If you have network issues, then just for kicks you can flash a custom Kernel on top of your compiled CM 11. See how that goes.
Click to expand...
Click to collapse
I followed the following procedure to include my modified libraries:
1) Eliminate precompiled vendor libraries: libril.so and libreference-ril.so from the vendor folder
2) comment lines in the vendor-blobs.mk that included those two precompiled libraries
3) from /android/system/ executed command "mmm /hardware/ril/librail" and "mmm /hardware/ril/reference-ril" to obtain the modified libril.so and libreference-ril.so
4) copied the new libraries in the vendor folder in the same places were the precompiled libraries were positioned
5) re-include the two lines that were commented in point 2)
6) build everything again with brunch d2tmo
7) flash the .zip obtained
Any mistake?

Unless I am having a brain fart that process seems about right. I wonder if your RIL changes are related to the network
What kind of issues do you see ?

Perseus71 said:
Unless I am having a brain fart that process seems about right. I wonder if your RIL changes are related to the network
What kind of issues do you see ?
Click to expand...
Click to collapse
It cannot even find the network operators. It says that it is impossible to connect and to try later...
mine is the Tmobile version of S3. May this influence?

That would depend on the changes you made. But otherwise not really. The underlying Device tree is unified for all US S3 devices.

[SOLVED] concerning zlib and aromafm

@Hazou @ketut.kumajaya
okay so,
my first question is, after building philz and going through static_libraries folder i find libz.a .
is this zlib built static, and if so can i relocate it to aromafm source in place of building zlib?
there seems to be too many dependancies that i'm not sure how to locate/point to that largely
seem to be in my kernel source, [cpuset.c,cpuset.h,adler32.c[x86] ?
if so please explain completely as i am still fairly noobish
getting better though :victory:
aromafm is a must have !
thank you for reading
m

moonbutt74 said:
@Hazou @ketut.kumajaya
okay so,
my first question is, after building philz and going through static_libraries folder i find libz.a .
is this zlib built static, and if so can i relocate it to aromafm source in place of building zlib?
there seems to be too many dependancies that i'm not sure how to locate/point to that largely
seem to be in my kernel source, [cpuset.c,cpuset.h,adler32.c[x86] ?
if so please explain completely as i am still fairly noobish
getting better though :victory:
aromafm is a must have !
thank you for reading
m
Click to expand...
Click to collapse
Aromafm is new for me, i have used it, but never build it in any way.
The zlib u build when buildibng your recovery is static, so it is a static library.
I don't know if u can replace it for the source in aromafm. Aromafm (quick look) uses his own source. But u can alway try. Out comment every line about zlib:
Code:
## ZLIB SOURCE FILES
LOCAL_SRC_FILES := \
libs/zlib/adler32.c \
libs/zlib/crc32.c \
libs/zlib/infback.c \
libs/zlib/inffast.c \
libs/zlib/inflate.c \
libs/zlib/inftrees.c \
libs/zlib/zutil.c
## ZLIB NEON SOURCE
ifeq ($(AROMA_ARM_NEON),true)
LOCAL_SRC_FILES += libs/zlib/inflate_fast_copy_neon.s
endif
and add "libz" after "libc".
Code:
## INCLUDED LIBRARIES
LOCAL_STATIC_LIBRARIES := libm libc libz
I can't find your "dependencies" so quick. Where did u find them? Most off them will probably just work.
Hazou

okay, go !
hazou,
thanks for the speedy reply,
okay so, first, cpuset.c i located in my kernel source, in aroma it's refered to in libs/zlib at
320 # if defined(__i386__) || defined(__x86_64__)
321 # include "x86/cpuset.c" <==== typo in souce said cpudet.c
322 #endif
neither the directory or the file exist in the source as it is.
i mkdir x86 in libs/zlib for libs/zlib/x86 , then searched cm11 from top and located what i can only
assume was the correct file [cpuset.c] in my kernel source and cp > aromafm/libs/zlib/x86 and naturally
now i have to either cp everything jn that chain or, drag my kernel source into aromafm directory.
can i point to an 'off-world' source outside of build directory? if so what does that look like?
as to zlib libz.a, the down side of a static lib is it doesn't necessarily fit to a specific purpose/function right?
thanks for your help as always.
m

moonbutt74 said:
hazou,
thanks for the speedy reply,
okay so, first, cpuset.c i located in my kernel source, in aroma it's refered to in libs/zlib at
320 # if defined(__i386__) || defined(__x86_64__)
321 # include "x86/cpuset.c" <==== typo in souce said cpudet.c
322 #endif
neither the directory or the file exist in the source as it is.
i mkdir x86 in libs/zlib for libs/zlib/x86 , then searched cm11 from top and located what i can only
assume was the correct file [cpuset.c] in my kernel source and cp > aromafm/libs/zlib/x86 and naturally
now i have to either cp everything jn that chain or, drag my kernel source into aromafm directory.
can i point to an 'off-world' source outside of build directory? if so what does that look like?
as to zlib libz.a, the down side of a static lib is it doesn't necessarily fit to a specific purpose/function right?
thanks for your help as always.
m
Click to expand...
Click to collapse
About that zlib. I still don't know if it will work. There may be a call from other files to the zlib files. And if so, i dont think it will work.
As for the cpudet.c, its not a typo. It looks like they were present in the source of zlib. But put outside by the developer because of ARM. U need to find the cpudet.c, put it into the following folder inside the source of aromafm: include/x86/cpudet.c. The same thing goes with: include/x86/adler32.c. But maybe it only works when u have it at aromafm/x86/cpudet.c/aromafm/x86/adler32.c.
I found the zlib variant the developer uses (old one i think, but maybe nessecary) and it includes the missing files, here From Koush

Heee heeee heeee!
hazou,
cool, will check out,
okay so, this is what i did,
forced compile for non neon
replaced uncompiled source for both zlib and libpng and mmm
result aromafm-santos10wifi
flash in recovery and......it works! .......mostly [lag, can i pull libenc trick with this?]
i need to adjust for display and figure out a way to enable/facilitate scrollback in terminal
at terminal #whoami
returns #uid0 :good:
busybox :good:
m

moonbutt74 said:
hazou,
cool, will check out,
okay so, this is what i did,
forced compile for non neon
replaced uncompiled source for both zlib and libpng and mmm
result aromafm-santos10wifi
flash in recovery and......it works! .......mostly [lag, can i pull libenc trick with this?]
i need to adjust for display and figure out a way to enable/facilitate scrollback in terminal
at terminal #whoami
returns #uid0 :good:
busybox :good:
m
Click to expand...
Click to collapse
Nice that it works! The pixelflinger (libenc) trick wont work here. I think that aroma can be enhanced with the libenc trick, but it needs heavy modding on graphical (framebuffer) part. And i don't have the skills to get that sorted.

good deal
Hazou said:
Nice that it works! The pixelflinger (libenc) trick wont work here. I think that aroma can be enhanced with the libenc trick, but it needs heavy modding on graphical (framebuffer) part. And i don't have the skills to get that sorted.
Click to expand...
Click to collapse
hazou,
thanks for the pointer, i wasn't sure of which direction to look. I am starting to get the hang of this stuff. got philz done, getting aromafm done.
thanks so much.
m

[Q] Working & stable SSHD/sftpd for ZE55xML ?

Apologize for possible OT, but I can't find an always working (and stable) SSH daemon app for the Zenfone2's Lollipop
This is what I tried, any of them PAID apps:
QuickSSHd - too old, not even starts
SSHDroid Pro - sometime starts, only first time after reboot, but only without root and higher ports (>1024)
RRooted SSH/SFTP Daemon - always refusing connections
Ssh Server Pro (olive tree) - seems promising, but very poor of binaries
The Dropbear service hanging issue seems the root of this problem
Thanks for any hint

I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir

Blades said:
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Click to expand...
Click to collapse
Hi,
I followed the following guide which you can get from googling "Compiling-Dropbear-for-a-Nexus-7-tablet". Sorry, I can't post any links yet as my post counts are still below 10
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Cheers.

wolfdude said:
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Click to expand...
Click to collapse
Thanks for your answer.
Sorry but I can't get the exact entry-point, bypassing all the NDK / X-compiling stuff, as we're on a x86_64 architecture
Referring to the "simplified" version of your link (here: https://nerdoftheherd.com/articles/cross-compiling-dropbear-rsync-android/ ),
how should I compile the Dropbear source ?
Something like this ?
Code:
./configure \
--disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog \
CFLAGS='-Os -W -Wall -fPIE' LDFLAGS='[COLOR="Red"]-static[/COLOR] -fPIE -pie'
... right before make-ing ?
Thanks for any further hint in the right direction

Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
From that site, what I did was :-
1) Download dropbear v58 (dropbear-2013.58.tar.bz2). I know this is older but the patch available is based on this version.
2) Download patch (dropbear-patch2) from that site.
3) Apply patch to the original dropbear (v58) source.
4) Run configure :-
./configure --disable-zlib --disable-largefile --disable-loginfunc \
--disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
5) Run make :-
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
6) You should end up with "dropbearmulti" which is a static binary that you can then copy over the the phone & go on from there.
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.

wolfdude said:
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
[...]
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
Click to expand...
Click to collapse
Yes of course. The main link you weren't able to post is:
http://blog.xulforum.org/index.php?post/2013/12/19/Compiling-Dropbear-for-a-Nexus-7-tablet
Actually that procedure seemed too complex as mostly dealing with the cross-compiling issue, which didn't apply to x86 case.
So I named the derivative one
Thanks for pointing out the static compiling is done within MAKE and not CONFIGURE phase... I'm quite newbie in those flags so I do appreciate any of your words
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time

Val3r10 said:
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Click to expand...
Click to collapse
Hi,
Yes, the patch for v58 does not work for v67. I think one just have to go through the patch and "adjust" it slightly for the newer v67. Hopefully there isn't much changes from v58 to v67. There may be more than just commenting out the password prompt as there are certain functions that don't work in Android as in *NIX. When I have some time, I will attempt to patch v67 meanwhile, I'm running v58 fine on my ZE550ML so no complains there.
Cheers.

Hi,
I've created a guide on compiling the latest dropbear (2015.67) :-
http://forum.xda-developers.com/zenfone2/general/compiling-dropbear-2015-67-zenfone-2-t3142222
Hope it helps.
Cheers.

wolfdude said:
I've created a guide on compiling the latest dropbear (2015.67)
Click to expand...
Click to collapse
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?

Val3r10 said:
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Click to expand...
Click to collapse
Of course. I've managed to compile tcpdump, iperf, gdbserver, etc... successfully and working fine on the Zenfone 2.
Cheers.

I found that "Servers Ultimate" SSH/SFTP modules work on the Zenfone2 once properly configured. Its not working 100% but its already more then most solutions out there.