.
This will not be the prettiest post until I have most of the bulk written out. Over time I will refine and improve, but for now I need to get it on paper.
-= READ THIS =-
-= I am not responsible for bricked devices. I know what I am doing when it comes to porting, and am giving you exact details on how to port. These methods have a very small chance of bricking, but if anything happens and you come crying to me, I will laugh at you. Follow this thread carefully and you will have little to no issues. =-
Before we begin, the most important part of android developing is to have Ubuntu (or preferred linux distro) installed on either a separate machine, or dual boot in windows. Most scripts that aid in developing can only be run under linux. A simple installer for dual booting Ubuntu/windows can be found here: http://www.ubuntu.com/download/ubuntu/windows-installer.
You also NEED adb installed, along with necessary Nexus S drivers, and have a basic knowledge of adb commands (I will cover a few). (You will need to install the Android SDK and download the platform-tools addon. This is where adb is located. There are guides online telling how to download these. If you need help, ask and I will include in the OP.) I dual boot Windows and Ubuntu, so I have my adb commands installed on my windows partition. This probably isn't the best way to do it, feel free to install adb under whichever OS you prefer. For this guide, I will be referring to using adb under Windows 7. The most common command needed while porting is simple:
adb logcat
Write this down somewhere if you cannot remember it. I have typed this command over 5000 times, it is used to debug system errors (bootloops, rom not booting, apps not working, etc).
I will also be referring to the "Android Kitchen" throughout this guide, mainly when working with boot.img's. In order to understand it more thoroughly, spend some time reading the first page. Link to Android Kitchen is below.
-= Useful Links =-
Be thankful, I saved you the time of googling
Nexus S adb drivers
Android Kitchen
Android SDK
7zip
Click to expand...
Click to collapse
-= Basics =-
The normal Android ROM consists of 3 main parts;
Boot.img – This is where the kernel and ramdisk are compressed. The ramdisk is what initiates the ROM’s main functions, such as Bluetooth, Wifi, and network connectivity information. The main file to pay attention to while porting is in the ramdisk, called the init.rc. It is a simple text file, and can be editied according to the ROM. A “how to” on unpacking/editing/repacking this file will be later in the guide.
System Folder – This folder contains all of the libs, configuration files, apps, and everything else that is the ROM itself. In this folder is where most of the changes are made, since most libs/framework pieces are device specific. This folder is the main cause of bootloops, and non-booting ports. I will try to explain most of my knowledge on what libs control what part of the phone. Almost all of the fixes for camera, sound, wifi, etc will be made somewhere within this folder. Unzip a ROM and dig around this folder for a bit, understand what folder contains what files, they are somewhat self-explanatory (Apps, framework, libs). This folder will become your best friend, learn to love it.
META-INF Folder – This folder holds all of the initial installer scripts; such as when you flash the ROM in a custom recovery. It is what tells your phone to install the ROM and what files to install. This script controls mount points, important system links, and in some occasions special commands. You can also edit this file to include any custom text you want users to see while flashing your rom. This file is device specific, and should ALWAYS be replaced when porting. Flashing a ROM with the wrong updater-script can either:
a) Corrupt partitions
b) Abort Installation (very frustrating with large ROM’s)
c) Rare occasion, brick your device
Bottom line is, pay very close attention to what exactly is in your custom built ROM before you flash it.
I decided this will be a good preface post. Read here for basic information you need to know BEFORE porting.
Here We GO
In order to port ROM's to the Nexus S, you will need a "base" to pull your files from. In order to port a ROM to the Nexus S, we will need a Nexus S ROM to start with, hence the "base". This base is normally CM7 or Stock Gingerbread, and can also be CM9 - Stock ICS. The base you pull from needs to match with the version of ROM you are porting.
1) Is the ROM I'm porting Ice Cream Sandwhich, or Gingerbread?
-This is very important. Most files are incompatible between versions, so make sure you know for sure, which version your port is going to be.
a) If the ROM you are trying to port is based on Gingerbread, download this ROM as a base to pull from (device specific):
CM7 GSM
CM7 4G
b) If the ROM you are trying to port is based on Ice Cream Sandwhich, Download this ROM as a base to pull from (device specific):
IMM76D GSM
IMM76D 4G
Click to expand...
Click to collapse
2) Download the ROM you are going to port. Place this ROM on your desktop, along with the matching base.
3) Unzip both ROM's (port, and base) using preferred archive utility. Extracted ROM's will be in folders with matching name of the zip, DO NOT mix these up; be very organized with your base and the ROM you are porting.
4) Take a look in your newly unzipped ROM's, they should look exactly as I explained in the first post. We will be starting with the System folder of the ROM you are porting, replacing our needed files.
4a) Click into the System folder; you will see many folders inside. The first one we start with is the lib folder. Click inside; you will now be in the directory /system/lib
4b) In this directory is where all of the libs are located; these are crucial to the ROM. Replacing these without knowing what you are doing will result in a ROM that will not boot.
4c) At the top, you will notice 5 main folders; bluez-plugin, egl, hw, modules, soundfx. The ones that we care about are egl and hw. The egl folder contains the graphics drivers for the specific device, and the hw controls lights, gps, and other hardware features. In the ROM you are porting, delete both of these folders. (egl and hw)
4d) At this point, navigate to your base ROM (Nexus S ROM). Select both the egl and hw folders, and drag them to the lib folder of the current ROM you are porting. Your lib folder will now contain 5 folders again. Moving on.
4e) Navigate to your base ROM folder, into /system/lib again. Select these libs and drag-drop into your current ROM you are porting (this step varies between ICS and GB);
-= Gingerbread =-
-libaudio.so
-libaudiopolicy.so } these libs control audio
-libaudioflinger.so
-libril.so
-libsecril-client.so } these libs control network
-libreference-ril.so
-libs3cjpeg.so
-libFLAC.so } these libs are required for media
-= ICS =-
-libaudioflinger.so (may cause issues with booting in some ports)
-libaudioutils.so } once again, these libs are for audio
-libtinyalsa.so
-libril.so
-libsecril-client.so } these libs control network
-libreference-ril.so
-libs3cjpeg.so
That should be it for the lib folder for now. Exit /system/lib, and return to the main branch of the system folder /system.
Click to expand...
Click to collapse
5) Once we are back into the root of the system folder (/system), observe the two folders towards the bottom; usr and vendor.
usr - contains files that relate to touchscreen, softkeys, keyboard, and other hardware buttons.
vendor - mostly nexus specific, contains additional network libs, graphics, hw, and extra configuration files.
5a) In the ROM you are porting, delete both of these folders. They are of no use, since they are specific to devices.
5b) Copy both the usr and vendor folders from your base ROM, to the current port's system folder. As you can see, there is a lot of copy and paste from our Nexus ROMS to the ports, although we keep the important folders that pertain to the ROM itself.
Click to expand...
Click to collapse
6) Navigate back to the /system folder. You should see a folder named etc. Click into it.
6a) The etc folder is a wonderful place; it is one of the most used folders in the ROM. Observe a few of the folders inside. In our base ROM, you will see a few folders that are pretty self explanatory (wifi, permissions, init.d)
TO BE CONTINUED - I'M TIRED AND HAVE TEST ALL DAY TOMORROW AND WEDENSDAY. I WILL UPDATE WHEN I FIND TIME IN BETWEEN
and also this one. Just in case.
I like this already
Sent from my tweaked aosp Sensation
Swamp spreading your knowledge is 10x more beneficial to the community than releasing a ROM. Thanks man.
Sent from my Nexus S 4G using Tapatalk 2
dreamsforgotten said:
Swamp spreading your knowledge is 10x more beneficial to the community than releasing a ROM. Thanks man.
Sent from my Nexus S 4G using Tapatalk 2
Click to expand...
Click to collapse
+1 on the fishing lessons. Goblin your contribution is appreciated.
You without me is like Harold Melvin without the Blue Notes....
Thanks for this. Will attempt working on some of your ROMs like the Epic Touch one.
Sent from my Nexus S 4G using xda premium
This needs a kick
Sent from my Sensation using XDA
great start, can't wait to read the rest!
I've been super busy this last week, had no time for anything really. I'll finish writing this up, there are so many parts that need to be covered, I guess "simple porting" isn't all that simple to explain
I am just impatient to get this entire guide!! Thanks you
I will take my pain with patience.. haha..
waiting for the second part!!
Looking forward to the rest of the guide! Much appreciated swamp!
I will be following this thread closely. I haven't so much as coded a hello world in years but once this guide is complete, it may serve as the segue to get me started again. Waiting with baited breath.
Does this guide work with any rom port? Or is this Nexus S specific?
sivarticus85 said:
Does this guide work with any rom port? Or is this Nexus S specific?
Click to expand...
Click to collapse
I was actually going to add this to the op. The files I have included are nexus specific, but the actual process should work on tons of other devices.. There are a few areas that are nexus specific, such as build.prop edits and vendor folder, but other than that you should be able to follow this for other devices.
Or do you mean nexus s roms? This guide is kind of general porting; more of the basics. With htc sense and fancy roms like that, there will be more edits that need to be done, etc.
swamp goblin said:
I was actually going to add this to the op. The files I have included are nexus specific, but the actual process should work on tons of other devices.. There are a few areas that are nexus specific, such as build.prop edits and vendor folder, but other than that you should be able to follow this for other devices.
Or do you mean nexus s roms? This guide is kind of general porting; more of the basics. With htc sense and fancy roms like that, there will be more edits that need to be done, etc.
Click to expand...
Click to collapse
Well I own a Photon, another member pointed me here because I wanna learn how to port. My intention is to port HTC Sense to it, and learn something new in the process. I'm using the Photon-specific CM7 as a base, and the Energy Rom from the Sensation as my rom port. Since both run GB and are qHD devices, I figured these would be good starting points.
Thank you very much for your guide.
sivarticus85 said:
Well I own a Photon, another member pointed me here because I wanna learn how to port. My intention is to port HTC Sense to it, and learn something new in the process. I'm using the Photon-specific CM7 as a base, and the Energy Rom from the Sensation as my rom port. Since both run GB and are qHD devices, I figured these would be good starting points.
Click to expand...
Click to collapse
Yeah, you're set up perfectly. I am pretty sure you could follow this guide, although there may be some photon specific libs that have to be added..
swamp goblin said:
Yeah, you're set up perfectly. I am pretty sure you could follow this guide, although there may be some photon specific libs that have to be added..
Click to expand...
Click to collapse
Ok cool. I'm pretty sure it'll be a while before I ever get this port running, so in the meantime I'll be brushing up on what makes my phone tick, and for you to finish your little guide here.
I knew my EVO inside and out almost, so I'm hoping the Photon is easy to learn too. The file system for both is pretty similar, with the exception of Sense-specific files of course.
Related
This project is no longer being updated. Feel free to use the code.
Android Builder (AB v.5)
kiel123 has joined the AB team!
Thanks to dsixda, Armin Coralic, and cteneyck. I do have permission to reuse their code.
Requirements:
Ubuntu Linux or variant
dsixda's HTC Android Basic Kitchen - http://forum.xda-developers.com/showthread.php?t=633246
In my crazy quest to learn more about Android, I decided to create a companion to dsixda's kitchen that will take some of the drudgery out of downloading and compiling AOSP and the HTC kernel.
Here's what the current menus looks like:
Code:
Select the device that you would like to build for.
1) HTC Droid Eris
a) About Builder
0. Exit
Please enter option number:
and then
Code:
1. Sync AOSP - Cupcake (1.5) repo
2. Sync AOSP - Donut (1.6) repo
3. Sync AOSP - Eclair (2.1) repo
4. Sync AOSP - Froyo (2.2) repo
0. Exit
Please enter option number:
You can follow these two steps, and you will get a freshly compiled, but unsigned ROM in the original_update folder. After running it through the kitchen, it boots up just fine. Of course, most of the hardware doesn't work. That's the part that I am working on now (seriously, I am). I've been working on this for a while, because as I said - this is really about me learning. If I can make a tool that someone finds useful, then great!
Install instructions:
1) download and unzip dsixda's kitchen to whatever directory you want
2) download Android Builder into kitchen's scripts/plugins folder and unzip
3) back out and start the kitchen
4) select 'Run plugin scripts' from Advanced menu and select 'Android Builder'
5) you're there!
NOTE: This will try to install/update all of the packages that it needs, including Java5. Please look at the code so that you know what it's doing. That's just a good general practice with any code that you can actually look at and that you have to run as root...
Future plans:
1) add more kernels (devices)
2) add more vendor trees (goes along with devices)
3) add more repos (CM5, CM6, AOSP Master)
I hope someone finds this useful, and feel free to post useful suggestions/bug reports.
DOWNLOAD - (https://github.com/gnarlyc/android_builder)
CHANGELOG -
v5. - kiel123 re-wrote v.4 as a plugin to dsixda's kitchen with me testing afterward, minor fixes, removed Java6 as no longer needed by kitchen
v.4 - re-wrote to add structure to support more devices in the future
added option for Cupcake, Donut, and Froyo
added .config files that enable touchscreen in kernel by default
v.3 - unreleased build
v.2 - corrected misspellings in code and dialogs
added sudo to launch setup script (Still need to sudo bash first. Sorry.)
v.1 - initial release
Very nice. I have been doing the same. I have used darchstar's post here as the basis of my work. But, I am always glad to look how others are doing things. Thanks for the post.
arockj said:
Very nice. I have been doing the same. I have used darchstar's post here as the basis of my work. But, I am always glad to look how others are doing things. Thanks for the post.
Click to expand...
Click to collapse
Thanks for the thanks! I don't quite get the vendor tree thing, but I just need to look at it again a few times. And, that's where I'm at. It would be really neat to be able create a working AOSP ROM from scratch with minimal manual intervention. It might not be possible, but I haven't found that out yet. (But wait! If you can do it manually, it can be scripted. Right?)
there's typo in your install script
look for line: android_builder*
should be android-builder*
and your install script should use mv command instead of cp to avoid files duplication
EDIT: also you should use sudo command along with ./ab_setup script or include within script as well.
When i ran ./abmenu and i get this message
Code:
Please copy 'menu-kd' to the root of your kitchen folder with 'menu'
menu-kd?.... don't you mean abmenu? turned out it was looking for menu file which i had it renamed to kitchen_menu but I fixed that on my part and all is working well.
Dont let any of my criticism scare you away, I can see there's a lot of potential use for this scripts, great start by the way.
firestrife23 said:
there's typo in your install script
look for line: android_builder*
should be android-builder*
and your install script should use mv command instead of cp to avoid files duplication
EDIT: also you should use sudo command along with ./ab_setup script or include within script as well.
When i ran ./abmenu and i get this message
Code:
Please copy 'menu-kd' to the root of your kitchen folder with 'menu'
menu-kd?.... don't you mean abmenu? turned out it was looking for menu file which i had it renamed to kitchen_menu but I fixed that on my part and all is working well.
Dont let any of my criticism scare you away, I can see there's a lot of potential use for this scripts, great start by the way.
Click to expand...
Click to collapse
I renamed all of the scripts at the last minute and thought that I had them fixed. I'll make the corrections and repost. The goal is to get this thing working well. Your criticism is just more motivation. Thanks!
I'm new to all this but I would love this to work with Froyo source.
Geo411m said:
I'm new to all this but I would love this to work with Froyo source.
Click to expand...
Click to collapse
The current 'internal' build works with Cupcake (1.5), Eclair (2.1), and Froyo (2.2). It's not ready to release though. Give me another week or two. I'm working on proprietary bits now, so that you get a more usable ROM from the start.
Although from your sig, it appears that you don't have an Eris, so you probably don't care much about it's proprietary bits. If you want it to get Froyo instead of Eclair, you can just change 'eclair' to 'froyo' in the script that creates the repo.
I'm with you on Froyo. I have a feeling in a month or two very few people will want to run a pre-Froyo ROM. It's really nice.
rm error on install
i keep getting "rm: cannot remove './bkup': No such file or directory"
the file is there untill i run the ./install script then it disappears and shoots me an error any help would be appriciated
Sjflowerhorn said:
i keep getting "rm: cannot remove './bkup': No such file or directory"
the file is there untill i run the ./install script then it disappears and shoots me an error any help would be appriciated
Click to expand...
Click to collapse
That files was used by me while developing the code. It's not needed. I'll fix the install script for v.5, but if you really want to fix the script now... Just remove the line -
'rm ./bkup'
from the 'install' script
You should still be able to start Android Builder by typing './abmenu', as long as it's in the same folder with the kitchen's menu. The error shouldn't matter.
gnarlyc said:
That files was used by me while developing the code. It's not needed. I'll fix the install script for v.5, but if you really want to fix the script now... Just remove the line -
'rm ./bkup'
from the 'install' script
You should still be able to start Android Builder by typing './abmenu', as long as it's in the same folder with the kitchen's menu. The error shouldn't matter.
Click to expand...
Click to collapse
k thanks i think it worked the same even with the error but got it =)
Sjflowerhorn said:
k thanks i think it worked the same even with the error but got it =)
Click to expand...
Click to collapse
Good deal. Let me know how it goes.
gnarlyc --
Have you thought of making this into a .plugin file that can be placed in the scripts/plugins folder of the HTC Android Kitchen? Then that way you won't need to update your scripts each time I update my kitchen
In my thread I could provide a link to your tool, so that people can add that plugin if they want.
dsixda said:
gnarlyc --
Have you thought of making this into a .plugin file that can be placed in the scripts/plugins folder of the HTC Android Kitchen? Then that way you won't need to update your scripts each time I update my kitchen
In my thread I could provide a link to your tool, so that people can add that plugin if they want.
Click to expand...
Click to collapse
The thought has occurred to me.
Give me a bit. A link in your thread would be great. It might even motivate me to add more devices. Getting stuck on adding Eris proprietary bits has lead me down the road of making a ROM (http://forum.xda-developers.com/showthread.php?t=725447) and documenting the process. I'll get back to Android Builder soon though.
Ok, so...
TO-DO
-------
1) rewrite AB as a plugin to dsixda's HTC Android Kitchen
2) add proprietary bits for Eris
3) add more devices
4) add CM repos
5) add Gingerbread repo
6) add compatibility with more distros
i am getting line 28: update-java-alernatives: command not found?
lord194409 said:
i am getting line 28: update-java-alernatives: command not found?
Click to expand...
Click to collapse
Interesting... I've tested from a freshly installed Ubuntu installation several times. It should install everything you need.
You could try 'update-alternatives --config java' and let me know what it says. You could also look for a file called 'setup_ran' in the root of the Kitchen, and delete it. Start './abmenu' after that and try again.
thanks for answering. Could the problem be that i installed it on cygwin.
lord194409 said:
thanks for answering. Could the problem be that i installed it on cygwin.
Click to expand...
Click to collapse
Yes. Android Builder will not work under cygwin. I don't know that it ever will. That's on the TO-DO list, but it's so far down that it's not on the posted TO-DO list.
I've only tested under Xubuntu 10.04 and minimal Ubuntu 10.04.
If you happen to work it out on cygwin, let me know! I'm sure others would be happy to have the option. Heck, I might even be. I'm mainly using Ubuntu because of AB anyway. (Although, it is kind of growing on me.)
thanks i will look in to it.
Sent from my Eris using XDA App
just wanted to let you know that it didn't work for me. It runs, gives some errors and outputs a update.zip called AOSPbase but the file is only 1.1kb in size.
Geo411m said:
just wanted to let you know that it didn't work for me. It runs, gives some errors and outputs a update.zip called AOSPbase but the file is only 1.1kb in size.
Click to expand...
Click to collapse
make sure you have java5 and java6 jre/jdk installed. it should work then. i had a similar issue the first time through... took it literally 10hours plus, then output was the 1.1k AOSPBase.zip file.
manually installed all java components, and everything worked perfectly then (and took half the time)
Thanks to anomalous3 over on the vibrant forum he was nice enough to port over his rom to our side based off of the new source code released by samsung
"If you feel like being a guinea pig, or know anyone who does, the deodexed build is here:
http://getyourboneon.com/CaptivateDeodexed.zip
Since I don't have a captivate I can't really test it, but it should work fine. It's based off that UCJH2 build. I didn't include any lag fixes since they've proliferated out of control, but I did include ext manipulation libraries and e2fsck to make life easier for people who want to use one of the lag fixes."
Please note I have NOT tested this rom yet, I don't have my captivate. Please somebody could test this and let us know if there's any problem so we can let him help us fix it.
Again, not responsible for whatever happens to your phone.
Here is the original thread I posted for reference.
http://forum.xda-developers.com/showthread.php?t=746466
EDIT: I'm going to assume you would install this like any other rom via update
EDIT2: anomalous3 has updated the link with corrections. Let us know how it works
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Zilch25 said:
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Click to expand...
Click to collapse
let us know how it goes
Do I just rename this to update.zip and go recovery and reinstall packages?
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Will do, flashing back to a stock JH2 while I download! I've been waiting for something like this
Clienterror said:
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It probably was my fault anyway =P
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
damn it, wish this was around 2 hours ago when i was bored! its too late now to ruin my phone haha.. tomo sometime maybe i'll try..
Question...Do I have to install the stock Captivate ROM first as it states in the linked post? I have the stock ROM that is rooted with the AT&T bloatware removed. The only other mod is the lagfix version 2.3...Can I just flash this over that?
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
nammyczc said:
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
Click to expand...
Click to collapse
That's what's taking me so long... seems like JH2 is having some issues with update.zips... namely it's getting to the "Opening installer" then "Install Aborted". The(not new) update.zip for root still works, so I'm tossing on clockwork to see if I can get this thing crammed on here with that.
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Zilch25 said:
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Click to expand...
Click to collapse
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
BuglessPete said:
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
Click to expand...
Click to collapse
I'll pm him about this
nammyczc said:
I'll pm him about this
Click to expand...
Click to collapse
Also ask him why superuser.apk is in the xbin folder.
vietphunguyen said:
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
Click to expand...
Click to collapse
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
golemaw said:
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
Click to expand...
Click to collapse
This is correct. Deodexed ROMs can be themed...
BuglessPete said:
Also ask him why superuser.apk is in the xbin folder.
Click to expand...
Click to collapse
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
anomalous3 said:
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
Click to expand...
Click to collapse
updated original post with info
Cornea's coming back! This thread will have a link to another thread for the new Cornea. Wow, threadception.
Cornea
Cornea is based upon my Motorola XOOM program, XOOT.
It's hard to explain...so I'll try my best.
Check out Cornea's official site at Site is down
THERE ARE TOO MANY ONE-CLICK SOLUTIONS FOR ANDROID.
Cornea has the ability to combine these into one application.
All you need is a toolkit for your Android device. (You can find these in the post below). Copy this into Cornea, and Cornea can suddenly do so much more with your device.
CAN'T FIND A TOOLKIT FOR YOUR DEVICE?
The best thing is, you can develop your own toolkits too. You can find out how to do this in Post #3
In my eyes, this is a revelation for Android hacking.
The possibilities are infinite. Make a toolkit that operates with your bootloader, or one that hacks your recovery. Or make an AllInOne toolkit that has the best of both worlds.
n00b FRIENDLY
It's easy to use for n00bs and hax0rs alike. It eases you through the first worrying steps of hacking, and you've also got a whole forum full of moderators and developers to help you out.
THE KEY TO THE LOCK OF RECOGNITION
If you've made your own toolkit, send it to me and I'll add it to the below post for public download!
Created by Epic118/FaizSaleem118
[Below post: Download Center - download Cornea and toolkits for your device]
[Post #3: Cornea Development Guide]
Download Center
Cornea's coming back! This thread will have a link to another thread for the new Cornea. Wow, threadception.
Change logs
v4.0 (TBA)
A fantastic, easy to use, intuitive GUI.
All toolkits upgraded to GUIs!
The Toolkit Download Center - download toolkits that work on your device only to reduce risk
Fastboot Flash UI - a user interface for the fastboot tool
Internet integration, with Help and Q&A built straight into the application. No need for fiddly websites!
Automatic OTA updates thanks to a new OTA daemon
Works on Windows XP properly. In fact, to guarantee this, the entire of Cornea will be built on XP.
Automatic %PATH% association: No need for administrative privileges like before
Even more!
v3.0 (planned) (NEVER RELEASED)
UNKNOWN
v2.0 (03/24/2012) (LOST)
No more metadata or EXEs - a simple BAT that'll work on all Windows computers
Many more tools for devs!
Official support for Cornea GUIs
OTA toolkit downloading
Universal toolkit enhanced
v1.2.2 (02/13/2012)
Changes version metadata from 0.1.2.1 to 1.2.2.0
Cornea now recognises if a toolkit exists or not, rather than stating "Toolkit not signed" and then FCing
Revamped Readme for easier usage (now includes tiimestamp)
Cornea.sc.bat included in case you want to modify it (find it in the sc folder)
v1.2.1 (03/12/2012)
Icon added (eye with HTC phone in the middle)
Converted into EXE format (no more twiddly batch files)
'Obese' toolkits (toolkits with adb binaries) are now rejected by Cornea
v1.2 (02/11/2012)
Universal Toolkit added
v1.1 (02/10/2012)
Removes ADB binaries from toolkits and adds them to C:\Cornea
v1.0 (02/08/2012)
Initial release
TOOLKITS
3 Toolkits Available.
That's not a lot. However, expect more, both from me and from the XDA community!
To use a toolkit, use WinRAR to EXTRACT HERE and then copy the new folder to Cornea's tooklit folder
Downloads can be...downloaded from the bottom of the page.
Motorola XOOM (Wi-Fi tested, 3G/4G may not work)
Bootloader lock and unlock
Flash CWM recovery (Tiamat)
Root (thanks solarnz, for your Universal Root thing)
Flash to stock images/convert to GED
Flash a non-CWM bootanimation.zip
SAMSUNG Galaxy Ace (limited. S5830, will be updated to have more features soon)
Flash CWM recovery (official)
Enter recovery mode if you have jammed buttons
Odin mode (copies Cooper.ops to Desktop, kicks device to DownloadMode and then opens Odin)
Universal toolkit
Included from Cornea 1.2
Install APK files to /system/app, /data/app and /sdcard
Send shell commands via ADB shell
Push and pull files
Remount system as r/w
Reboot into any supported mode (system, recovery, fastboot, download, rsa)
Show logcat
Cornea's official download site is down, use the mirrors!
Mirrors - Mediafire
Mirror - Cornea 1.2.2
Mirror - Cornea toolkit - S5830
Mirror - Cornea toolkit - XOOM
Cornea Source Code Center
Cornea's coming back! This thread will have a link to another thread for the new Cornea. Wow, threadception.
For the meantime, there'll be nothing here.
Looks great.... waiting for the galaxy ace version...
Anyone brave enough to have tried 3G xoom, as it states it might not work.?
I like the sound of this. Might look into making one for the EVO 3D.
What functions can be written in scripts?
Sent from my SCH-I400 using xda premium
I think something like this (ONE common, extensible 'hacker' platform) is sorely needed. I see tweak threads, but each dev goes his/her own way about it.
One suggestion: Remove the adb files from the toolkit folder, so toolkits are much smaller and one doesn't have 20 copies of adb.exe.
Cornea/
cornea files
adb.exe
AdbWinApi.dll
AdbWinUsbApi.dll
MySampleToolkit/
toolkit .bat files [Provide a template to setup ../adb.exe reference.]
other files (opt)
Hmm... I don't use ADB, but could the toolkits be written in "sh" style. That way Cornea could also exist as a sh script for rooted BusyBox users?
Just my $0.02.
P.S. I vote option 4: I do/don't know how, but I would rather use other peoples' toolkits.
ciscogee said:
What functions can be written in scripts?
Click to expand...
Click to collapse
From inferring and a 30 second review of the code...
A) On the PC, toolkits are "DOS" batch files. For functions (in the program flow sense), you can do whatever you want with all the quirks of batch files.
B) To change something on your phone, you are using ADB. Read the documentation to learn more. (Personally, I've never used ADB.)
I'm glad to hear that people like the idea of Cornea. I'm a n00b too.
Implementing ADB into Cornea would be a good idea. I was contemplating that but it'd be pretty difficult to do that, particularly if people are browsing through folders during runtime and the like. I had found a way to do it, which was to do it via calling the *.bat instead, but when I got up, my inbox already had a few toolkits in there, and I really couldn't be bothered!
One way I could do this is make an installer for Cornea that copies ADB-required files to C:\Windows\system32 and then update Cornea...tell me what you think!
Also you can execute BusyBox SH files...if I'm right, you could adb push it to a working directory, then do adb shell sh, and then when done you could use adb shell rm to remove the file?
Haraldr Blaatand said:
I think something like this (ONE common, extensible 'hacker' platform) is sorely needed. I see tweak threads, but each dev goes his/her own way about it.
One suggestion: Remove the adb files from the toolkit folder, so toolkits are much smaller and one doesn't have 20 copies of adb.exe.
Cornea/
cornea files
adb.exe
AdbWinApi.dll
AdbWinUsbApi.dll
MySampleToolkit/
toolkit .bat files [Provide a template to setup ../adb.exe reference.]
other files (opt)
Hmm... I don't use ADB, but could the toolkits be written in "sh" style. That way Cornea could also exist as a sh script for rooted BusyBox users?
Just my $0.02.
P.S. I vote option 4: I do/don't know how, but I would rather use other peoples' toolkits.
Click to expand...
Click to collapse
Oh, sorry! I completely forgot your last question! Erm...no, I can't write it as an sh file because I'm uneducated on the subject. Maybe someone could help who could?
I'm keeping my eyes on this because I think it's a good idea and sorely needed. Before I try to get this in the portal can you add a list of tweaks included in the kits you have already released? Also, any new kits expected soon?
Bentenrai said:
I'm keeping my eyes on this because I think it's a good idea and sorely needed. Before I try to get this in the portal can you add a list of tweaks included in the kits you have already released? Also, any new kits expected soon?
Click to expand...
Click to collapse
1) I will do so, yeah.
2) No kits from ME expected soon, because I only own a Galaxy Ace and a XOOM, both of which have a kit from me.
Provided you still have those retired devices, you could make quite a few kits - it's pretty simple and easy to do. Even if you don't, it'd be interesting to see some Nook hacks.
Error (509)
This account's public links are generating too much traffic and have been temporarily disabled!
Dropbox isn't too happy.
Anyway we can get a mirror?
Thanks for your hard work! I can't wait to take a deeper look into this.
epic118 said:
1) I will do so, yeah.
2) No kits from ME expected soon, because I only own a Galaxy Ace and a XOOM, both of which have a kit from me.
Provided you still have those retired devices, you could make quite a few kits - it's pretty simple and easy to do. Even if you don't, it'd be interesting to see some Nook hacks.
Click to expand...
Click to collapse
Yeah I was gonna try to make a bloat removal script for the E3D but I'm not too versed in the workings of my Nook so I don't have any decent idea there. Actually, on second thought, I can probably whip up one that fixes the market, netflix and the screen density but that's aboot it. I'll get started on it later tonight.
Anybody got a mirror up?
Bentenrai said:
Yeah I was gonna try to make a bloat removal script for the E3D but I'm not too versed in the workings of my Nook so I don't have any decent idea there. Actually, on second thought, I can probably whip up one that fixes the market, netflix and the screen density but that's aboot it. I'll get started on it later tonight.
Anybody got a mirror up?
Click to expand...
Click to collapse
Mirrors now up on both mediafire.com and cornea.site40.net (preferred, Cornea's official site!)
Most new toolkits'll be up on Cornea's official site. Usercreated ones will not be uploaded to mediafire by default. If you want a mirror, you'll have to upload it by yourself and send the mirror URL to me.
Does anyone get a compatibility error message when trying to start Cornea.exe?
Using Win7 32bit. Should I be starting it from a command prompt? I read the README but it didn't specify anything besides moving & renaming the files directory to the root and appending the environment variables path.
I have a feeling this post is going to be REALLY embarrassing for me.
OK, lay it on me. I'm ready. Which stupid human error did I commit?
R1150GSA said:
Does anyone get a compatibility error message when trying to start Cornea.exe?
Using Win7 32bit.
Click to expand...
Click to collapse
That shouldn't be. I've tested a lot, and Cornea has been mostly flawless.
R1150GSA said:
Should I be starting it from a command prompt?
Click to expand...
Click to collapse
No.
R1150GSA said:
I read the README but it didn't specify anything besides moving & renaming the files directory to the root and appending the environment variables path.
Click to expand...
Click to collapse
That's all you SHOULD have to do. Of course, you're having problems.
R1150GSA said:
I have a feeling this post is going to be REALLY embarrassing for me.
Click to expand...
Click to collapse
No, it won't. Even the best of us make mistakes.
R1150GSA said:
OK, lay it on me. I'm ready. Which stupid human error did I commit?
Click to expand...
Click to collapse
None. In fact, if anything, it's probably my fault. You see, I use a BAT-EXE converter to finish off my batches, and I must have accidentally chosen 64bit compiling instead of 32. (Sorry, I'll fix it when I've got time!)
In the meanwhile, you can use the Cornea batch sourcecode, which is included with the Cornea download. It's in the same folder as Cornea.exe, but it's called Cornea.sc.bat (or it's in the /sc folder, depends which version you've got). It's exactly the same thing, and there's not much (if any) difference other than the missing metadata/icon.
Have fun using Cornea!
Epic118
You call this a website?
SHUT UP!
Makes me remember smosh! haha
If you want I'll make you a nice site for free
Take a look at my stuff in my signature......I started making toolkits for different devices some time ago. If you look at my source you can get some new ideas and features
I would like to mess with trying to install my own customized ROM's to my Nexus 7, but the first place to probably start is with being able to build AOSP as-is from source.
As I understand currently, building is only supported on Linux and OS X, but I can easily get Ubuntu 10.04 and re-partition my HDD to give it about 100GB (if that much is even needed).
Looking at:
http://source.android.com/source/initializing.html
I need to choose a branch and setup the Linux environment. I'm a bit confused as to what branch I should choose though. I want the latest source of Android available at the time, so I should pick the master branch? Or since I'm only building for the Nexus 7, should I choose it's device-specific branch instead? Although looking at:
http://source.android.com/source/build-numbers.html
the Nexus 7 is only at android-4.1.1_r1.1, but I could of sworn I heard there was r4 out already.
As for setting up the Linux environment, I hope I can just follow all the commands listed there without any problem.
Proceeding on with:
http://source.android.com/source/downloading.html
It looks like a pretty straightforward process that I'm also hoping can be done successfully if I follow the commands exactly as presented. I don't have a proxy nor the need for a local mirror either.
And then moving onto:
http://source.android.com/source/building-devices.html
Some stuff there I find a little bit confusing. It would seem I have to first get proprietary drivers, which all 4 seem to be placed conveniently at:
https://developers.google.com/android/nexus/drivers#grouper
From there, I imagine I can move the script that's bundled inside to the root of the source folder, run it, and follow the instructions. I don't exactly know what the root of the source folder is, but it would probably be obvious once I did start trying to build this. But once I did find it, I would run (using Nvidia's Graphics driver for the example) sh extract-nvidia-grouper.sh in Terminal, and it would place the right files where they need to be.
I don't understand the make clobber part too well at all; should I run this on the very first build, later builds, or all builds?
And once the source and drivers are all downloaded and available, I should then run lunch full_grouper-userdebug and then finally make -j# (# being some number in accordance with how many cores on my CPU I have). I have a triple-core CPU at 3.5Ghz, and I have the ability to unlock to quad-core at 3.3Ghz (but prefer to stay on triple). Should I just run -j32? Also will this build the Kernel as well, or will I have to get the source for that and compile it separately?
And once the build completes, my plan from there was to just go back to Windows and flash it. And if I managed to get it to flash and boot properly, I assume I would of succeeded with compiling AOSP from source
I noticed that userdebug part on full_grouper-userdebug gives "root access and debuggability". Does this mean it comes with some program like Superuser or SuperSU already installed? Or does this mean I can easily install those?
Perhaps after I get comfortable with the basics of flashing AOSP as-is, I can then try to mess with different types of optimizations, like Linaro and perhaps even messing with many types of optimizations from different kernels like faux123 has done .
I also have a 360kb/s DSL connection, so downloading the entire source the first time will probably take a good while. But once I have the source, I take it I don't have to redownload the entire thing for patches and stuff?
Any and all guidance is welcome
Bump before I go for tonight
Bump
You have a bunch of questions. I will answer some. And while I whole-heartedly support learning to build you don't need to build to flash roms.
The best advice I can give you is to just start building. You have found a bunch of instructions and links, obviously. Go ahead and begin, and tackle problems as they arise.
Environment
Okay...really the hardest part is setting upi the environment, if you don' t know linux. After downloading and installing Java and the SDK, make sure you add them to your path.
Most guides will have adding the path in the directions. But make sure to check that it works! It will be extremely frustrating, and you won't know what is wrong. Go to a random directory, Documents would be good, and enter java -version and then adb devices. If the computer says it cannot find the commands, then your path is the problem.
Make sure to setup udev. It is easy, Google it.
Building
Branch
You want to build from the tags.
Code:
repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.1_r4
For the proprietary blobs, whatever directory you repo sync from (~/android/system or whatever) is the root directory. run the extraction from there.
when the proprietary blobs are extracted, and the source has been downloaded, these are your commands.
Code:
. build/envsetup.sh
lunch
Lunch will return a list of devices, Grouper is the Nexus 7, it is number 4. eng and user-debug do have root access, but SU and SuperSU are more than just root, they manage the root access for your apps as well. You can download them from Play or install them as a flashable-zip.
Choose 4 and then
Code:
make otapackage
don't worry about the -j# part. Your machine almost definitley cannot handle -j32. It is -j4 by default, that should be fine for your cpu.
If you want to enable faster builds, you can enter
ENABLE_CCACHE=1
before make otapackage, but it will take up a lot of space on your hd. Your subsequent builds will use some thing from your intial build instead of rebuilding them each time (kernel and other things). So even if you repo sync, some changes won't be reflected in your later builds. For instance, if you do not clean your prebuilts and build system, your build date in the build.prop will always stay the same as the first build.
The way you clear the build directory and make new everything is with make clean or make clobber. You can run it before any build, but the build will take much much longer than one that uses prebuilts. Non-clobbered and with ccache enabled are the fastest of all. But subsequent builds are pretty fast even without ccache.
When you want to update your source, you can just go to your root dir and repo sync. It will only update your source, it won't take nearly as long.
Okay, I answered more than I intended. There are a million guides that show you every step in the process.
Don't ask anymore generic worry questions...you're ready. You understand more than most people do before their first build before I even posted. Get started and if you run into problems, search. If you can't find the answer, then come back and ask us.
Good luck. it is easy, and very satisfying.
I finally got around to installing a Virtual Machine, and Ubuntu 10.04 After doing that, I fully updated Ubuntu, installed VMWare Tools, and then proceeded to start trying to acquire the AOSP source.
Getting sun-java-6 was a bit tricky, but not too hard (I ran the commands exactly as listed on the site, but the package didn't exist; had to get it from somewhere else). After that, I proceeded to do everything else, except CCache (I didn't know what .bashrc was, but I'll look further into this with future AOSP builds).
I then made the folder, did repo sync, and I'm now acquiring the source now from android-4.1.1_r4. As a quick question, does it matter whether I choose to build from android-4.1.1_r4, or master? Would master be more up-to-date?
espionage724 said:
I finally got around to installing a Virtual Machine, and Ubuntu 10.04 After doing that, I fully updated Ubuntu, installed VMWare Tools, and then proceeded to start trying to acquire the AOSP source.
Getting sun-java-6 was a bit tricky, but not too hard (I ran the commands exactly as listed on the site, but the package didn't exist; had to get it from somewhere else). After that, I proceeded to do everything else, except CCache (I didn't know what .bashrc was, but I'll look further into this with future AOSP builds).
I then made the folder, did repo sync, and I'm now acquiring the source now from android-4.1.1_r4. As a quick question, does it matter whether I choose to build from android-4.1.1_r4, or master? Would master be more up-to-date?
Click to expand...
Click to collapse
Sorry for late answer, no, use the r4 branch as it is more up to date. Also, make clobber every time isn't needed but you should as it remove then entire out folder (wich is where compiled stuff go) and this make sure you rebuild a clean thing.
Building CyanogenMod 10
Dunno if this is of any interest, but I have a thread started with a complete walkthrough for building CyanogenMod10 for Nexus 7.
Most of the info is the same, and there are some tips in the comments as well.
espionage724 said:
I would like to mess with trying to install my own customized ROM's to my Nexus 7, but the first place to probably start is with being able to build AOSP as-is from source.
Click to expand...
Click to collapse
So, how did you get on? I've been following the same path I think - repo sync the source and follow Google's own tutorial on compiling Android but with the added step of incorporating the binary drivers for the grouper.
I've built the .img files using make -j8, that all works, fastboot flash worked, but I get no video out when booting up using the new OS. I can ADB into the Nexus and it's certainly booted and working okay apart from, I'm guessing, the missing binary drivers.
I've used each of the 5 binary driver scripts to populate the "vendor" directory in the root of the downloaded source before compiling from scratch, but perhaps I've missed a step, so I'm curious as to whether you've got a fully working AOSP+binary driver compile working.
(By the way, my build environment was Ubuntu 12.04 64bit, SDK r20.0.3, Android 4.1.1 (JRO03R) source, Sun Java 1.6, and it all seems to work well using 8 threads on a Core i5 2500K + 4GB RAM).
Edit:
I re-ran the binary extraction, did a make clean; make clobber, and re-compiled - and now video works. Everything works now apart from the compass, camera and rotation sensor. I also tried compiling CyanogenMod from source, too, and had the exact same three problems. Everything works, and works well, apart from camera, compass and rotation sensor. All of which work in the stock Google ROM. Weird.
OK, So I've just compiled an OTA update package from AOSP source... my question is this:
I already have unlocked the bootloader on my wife's Nexus 7, installed Clockworkmod, rooted it, installed busybox, etc, manually on the stock 4.2 update I downloaded from Google on the device when it asked me to upgrade.
Is the otapackage I just compiled going to replace my custom recovery if I flash it as is? I've looked, and it has a "recovery" folder in the .zip, whereas any of the custom ROMs I have downloaded for my phone do not. Do I simply delete this recovery folder, and flash away? Do I need to edit the updater-script? I'm still trying to read and learn about this, but I haven't gotten a good answer from google or searching this site for my specific problem... maybe I'm wording my searches incorrectly.
I would just rather not have to go back and reinstall Clockworkmod... I know that if I want to have busybox, SuperSU, and other apps installed when I flash I'm going to have to add them to the zip and resign... I just don't want to mess my recovery. And being that this is my wife's tab (and not mine to play with, as she pointed out ) I don't want her to get the impression that I'm having to "fix" something I "broke" lol.
hallowed.mh said:
OK, So I've just compiled an OTA update package from AOSP source... my question is this:
I already have unlocked the bootloader on my wife's Nexus 7, installed Clockworkmod, rooted it, installed busybox, etc, manually on the stock 4.2 update I downloaded from Google on the device when it asked me to upgrade.
Is the otapackage I just compiled going to replace my custom recovery if I flash it as is? I've looked, and it has a "recovery" folder in the .zip, whereas any of the custom ROMs I have downloaded for my phone do not. Do I simply delete this recovery folder, and flash away? Do I need to edit the updater-script? I'm still trying to read and learn about this, but I haven't gotten a good answer from google or searching this site for my specific problem... maybe I'm wording my searches incorrectly.
I would just rather not have to go back and reinstall Clockworkmod... I know that if I want to have busybox, SuperSU, and other apps installed when I flash I'm going to have to add them to the zip and resign... I just don't want to mess my recovery. And being that this is my wife's tab (and not mine to play with, as she pointed out ) I don't want her to get the impression that I'm having to "fix" something I "broke" lol.
Click to expand...
Click to collapse
Sorry if a bit late, but here are some answers:
yes, the rom will replace your recovery. but if you delete the recovery folder and delete every line containing the word "recovery" in the updater-script, you should be good to go.
And if you accidentally remove the recovery, you can always flash it back very easily using: "fastboot flash recovery [filename.img]" (your n7 has to be in the bootloader)
And again, yes, you will have to put the extra apps into the zip and update the updater-script to install them too.
Also, you will need the gapps package if you want to use the play store and other google apps.
Hope this helped
Nexus 7 3G does not boot after flashing AOSP
Hi,
I followed the steps provided on source.android.com to build and flash the AOSP for Nexus 7 3G Tilapia. After successful flash, the device does not show anything after Google logo. Please help me out.
Thanks,
Veeren
Compile with ccache makes build time extremely fast.
How to do:
_Open a terminal
_Install ccache:
sudo apt-get install ccache
_Open .bashrc:
sudo gedit ~/.bashrc
_Add these lines:
#ccache
export USE_CCACHE=1
_Save and exit
_Sync source code
_After source synced, run in same terminal (in root directory of your source):
prebuilts/misc/linux-x86/ccache/ccache -M 20G (20G is the size in giga of space allocated for ccache, change it as you want)
_Start building
How to see if ccache works:
_Open another terminal in the root directory of your source and type:
watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s
First build using ccache may be a little much longer but the others will be faster...
veerndra said:
Hi,
I followed the steps provided on source.android.com to build and flash the AOSP for Nexus 7 3G Tilapia. After successful flash, the device does not show anything after Google logo. Please help me out.
Thanks,
Veeren
Click to expand...
Click to collapse
Did you pull the proprietary files for your nexus and include them in the build? I believe things like your video drivers are included in there, so if those are missing....
I think the prop files are available for download from Google on source.android.com... If not, they tell you how to use an included script to pull them via adb. I can't remember... It's been a while since I built vanilla AOSP.
Sent from my Inspire 4G using xda app-developers app
Modifying stock AOSP
I have built AOSP following the Google tutorial.
I am compiling using the master branch and
Code:
aosp_grouper-userdebug
.
I have downloaded and extracted the appropriate proprietary binaries.
I am modifying two files in the source tree (see attachments; search for "// MODIFICATION ADDED HERE" to find my changes). Will these changes work? I am using Eclipse, set up in the exact way the tutorial explains, and I am not receiving any new errors.
When I compile the source using the following commands
Code:
$ . build/envsetup.sh
$ lunch aosp_grouper-userdebug
$ make fastboot adb
and flash it to my device with
Code:
$ fastboot -w flashall
BEFORE my modifications, it works just fine. The android-info.txt file and all the image files are produced properly.
However, AFTER adding the modifications, the build completes with no errors, but android-info.txt and all image files are no longer produced.
Why am I experiencing these problems? What can I do to make it work the way I want?
P.S. YES, I am aware that my modifications are not secure; these are for my own purposes, not for a public build.
I put this here because I have only tested with my s5, and its not done yet so wanted a general topic for feedback before putting in a dev section. But please feel free to move this as you see fit moderators.
While playing with making the hotspot mod and other general investigation into things on my s5, it dawned on me that its kind of a PITA to keep things organized. Kitchens do a pretty good job at helping to give you a method to the madness when making ROMs but I haven't found anything too helpful for making mods. So that gave me an idea, I have decided to call it modStudio for now, a place to keep needed tools and a workflow to keep things organized and not chaotic.
This project is far from complete but I think its in a good place now and was hoping to possibly get a little feedback.
I am running on a 64 bit linux machine, and right now that is all that is supported. If you are already building things for android chances are you have a machine like this around already anyway.
I don't have a full tutorial written up, and I would rather spend time adding functionality for now but you can pull down the latest copy by doing:
Code:
git clone https://github.com/miked63017/modStudio.git
There are some examples in the readme, but basically go into the directory that the repo created and source the toolbox file
Code:
source tools/toolbox
This sets up a few commands that I find useful, and hopefully you will too
I will paste what I have in the readme for now, and work on the tutorial as functionality is added, please let me know what you guys think. Any comments, suggestions, requests or contributions are welcome.
In the README.md:
This is a tool I made to aid in the process of making mods for Android phones.
I was tired of having multiple tools in different places and wanted to bring everything together with some easy shortcuts.
This should work on any 64 bit linux distro at the moment, but I have only tested on OpenSuse 13.1 since that is what I use.
Things that are assumed:
you are running on linux 64 bit
you have adb correctly setup and in your $PATH
you have aapt and java setup and in your $PATH
you know how to make changes once you have a decompiled apk
A few commands require you to have your phone plugged in, plug it in.
Some general notes for now:
You must always generate a source directory from which files will be used to modify
The source directory always stays untouched, so if you want to start over you can clean your playground and begin again
If you deodex an apk or ar that does not have a .odex it will be basically the same thing as the playWith command
If you have a source dir populated from your phone decompiling will take a while to search for framework files, unless you trim your source dir down
Example usage:
Code:
#setup modStudio, only need to do once
git clone [url]https://github.com/miked63017/modStudio.git[/url]
cd modStudio
#Need to source this file in your shell everytime you want to use modStudio
. tools/toolbox
#Basic workflow working with a stock odexed system image, must be rooted and have busybox installed
#example given for services.jar but should work with any
cleanSource
cleanPlayGround
pullSystemFromPhone
deodex services.jar
decompile services.jar
#make your changes in playground/system/framework/services.jar.out
build services.jar
odex services.jar
installFromPlayground
#Workflow from zip file, assuming already deodexed ROM
cleanSource
cleanPlayGround
pullSystemFromROM romname.zip
playWith services.jar
decompile services.jar
#make your changes in playground/system/framework/services.jar.out
build services.jar
installFromPlayground
Very nice will check this out when I get some time. Great work this could prove very helpful to the devs.
Sent from my SM-G900P using Tapatalk
vinman12 said:
Very nice will check this out when I get some time. Great work this could prove very helpful to the devs.
Sent from my SM-G900P using Tapatalk
Click to expand...
Click to collapse
Made a few updates, if anybody is testing please do git pull often
Sent from my SM-G900P using XDA Free mobile app
Wicked cool! I assume the re-odex happens right on the phone? I need to get a VM setup so I can play with it..
Sent from my SPH-L710 using Tapatalk
rocket321 said:
Wicked cool! I assume the re-odex happens right on the phone? I need to get a VM setup so I can play with it..
Sent from my SPH-L710 using Tapatalk
Click to expand...
Click to collapse
The re-odex does happen on the phone and the files are pulled back onto the pc so you can install them when ready. The install command puts everything from your "playground" into the right place on the phone. I plan on still making a function to create a flashable zip, but haven't gotten there yet. Even without the flashable part it still makes things a lot quicker for developing and testing. Also plans on storing mods as patch files and scripts to log your work so you can repeat the same processes on different base systems in one command.
Sent from my SM-G900P using XDA Free mobile app