Related
ok ive just set up EGIT with eclipse and i cant seem to get the hang of it. can someone tell me how i would import a package from a git respitory or import an entire git respitory into eclipse, e.g. all of the cyanogen package into eclipse or asop into eclipse?
no one knows of any tutorials or anything to help me out?
http://wiki.cyanogenmod.com/wiki/Loading_source_in_eclipse
Since you have to use repo to sync AOSP and/or CM you won't have any need for EGit. If you want to use Git for your own personal use (for apps you are developing, etc...) I would strongly recommend not using EGit at all because it's a pain in the ass (my own personal VERY biased opinion). Just use git from a terminal/command prompt. Github has nice tutorials on how to do this in linux/OS X/Windows.
I would agree that EGit CAN be a pain in the ass but personally, for my uses which is mainly app development, it's fine. I'll get back to this thread when I get back onto my Ubuntu machine (haven't got eclipse nor Java installed on this computer) and I'll get instructions. If you're not doing ROM or kernel development, EGit is fine and it's quite convenient (having all the buttons for merging, commiting, pushing and pulling in the context menu).
Sorry, I'd forgotten about this but here's how to clone a Git repository just in case you wanted to know.
File->Import->Git->Projects from Git->URI->then put in your remote's URI e.g. [email protected]:myusername/projectname.git->then select the branch you want to clone->change the directory to your workspace directory (my personal preference)->then import the project into eclipse as per usual
Hi people, this is my first post here, I think is the best place where I can discuss my programming issues. If this post isn't in the correct place, please move it and forgive my dumbness.
I'm working in some personal projects, android apps, in my house. There I have my PC with Eclipse and Git, at the end of the weekend I'm always commiting changes and uploading them to GitHub. When I go to my office, sometimes I have some spare time and I open Eclipse to start working, but of course I synchronize the GitHub repository data with my local data (in order to work with the latest changes I've made in my house), but I'm always having troubles with this action: I don't know how to discard my local old files, keep the files that haven't been modified and download the latest version of my modified files. I always end deleting the folder and cloning the repo again because I mess the files... I'm sure there is a better way.
So, I'd be delighted if you could assist me on how should I work with this feature of Git. I'd like too to take advice to improve my workflow. I've checked lots of sites and tutorials about Git but I haven't been able to get useful info to match with my workflow...
Thank you in advance
kyomuga said:
Hi people, this is my first post here, I think is the best place where I can discuss my programming issues. If this post isn't in the correct place, please move it and forgive my dumbness.
I'm working in some personal projects, android apps, in my house. There I have my PC with Eclipse and Git, at the end of the weekend I'm always commiting changes and uploading them to GitHub. When I go to my office, sometimes I have some spare time and I open Eclipse to start working, but of course I synchronize the GitHub repository data with my local data (in order to work with the latest changes I've made in my house), but I'm always having troubles with this action: I don't know how to discard my local old files, keep the files that haven't been modified and download the latest version of my modified files. I always end deleting the folder and cloning the repo again because I mess the files... I'm sure there is a better way.
So, I'd be delighted if you could assist me on how should I work with this feature of Git. I'd like too to take advice to improve my workflow. I've checked lots of sites and tutorials about Git but I haven't been able to get useful info to match with my workflow...
Thank you in advance
Click to expand...
Click to collapse
Hi, this should be the right section for talking git, don't worry
My understanding is that you have some local (uncommited) changes on your machine at work, and you want to pull the latest commits from your distant repository while avoiding merge conflicts, is that correct ?
If it is, then you have several solutions at your disposal:
The easiest and cleanest way is to stash your local changes, pull the new commits and then pop the stashed changes to commit them over the up-to-date repo later on:
(replace <remote> and <branch> with your actual remote and target branch, for example git pull origin master)
Code:
git stash
git pull <remote> <branch>
git stash pop
The branch is now up to date and your local changes are still there for you to commit or to continue modifying.
If instead you decide that you don't need the local changes you stashed anymore, instead of popping them you can clear the stash:
Code:
git stash clear
If you want to fetch remote changes for all the branches, replace the git pull with:
Code:
git fetch <remote>
If all you want is to get rid of your local changes and sync with upstream repo, you can use:
Code:
git checkout .
git pull <remote> <branch>
Hope this helps, let me know if you need further help, or if I didn't understand your question properly :silly:
Androguide.fr said:
If all you want is to get rid of your local changes and sync with upstream repo, you can use:
Code:
git checkout .
git pull <remote> <branch>
Click to expand...
Click to collapse
Thank you very much. This is what I need, or at least what fits best with my workflow, as I'm always starting programming from the point i've stopped working in another place, being like this:
When I get to work:
Code:
git checkout .
git pull <remote> <branch>
So I'm getting my updated code as I stopped programming at home
Minutes after going home:
Code:
git add .
git commit -m "another day, another commit"
git push origin master
When I get home:
Code:
git checkout .
git pull <remote> <branch>
So I'm getting my updated code as I stopped programming at work
Minutes after going to bed:
Code:
git add .
git commit -m "another day, another commit"
git push origin master
This is a correct workflow? or I'm misusing the benefits of Git?
kyomuga said:
Thank you very much. This is what I need, or at least what fits best with my workflow, as I'm always starting programming from the point i've stopped working in another place, being like this:
When I get to work:
Code:
git checkout .
git pull <remote> <branch>
So I'm getting my updated code as I stopped programming at home
Minutes after going home:
Code:
git add .
git commit -m "another day, another commit"
git push origin master
When I get home:
Code:
git checkout .
git pull <remote> <branch>
So I'm getting my updated code as I stopped programming at work
Minutes after going to bed:
Code:
git add .
git commit -m "another day, another commit"
git push origin master
This is a correct workflow? or I'm misusing the benefits of Git?
Click to expand...
Click to collapse
Yeah, this looks correct, as long as you don't need your local changes this is probably the best way.
DexPatcher
A toolchain for modifying Android APK files at source-level using Java, graphical resource editors, and the full power of Android Studio in all major platforms.
Fully integrated with Android Studio and the Gradle build system.
Includes support for coding assistance and on-demand class decompilation.
Patch Java code in Java using declarative syntax provided by the DexPatcher tool.
Manifest merging enables piece-wise changes to the original app manifest.
Modify existing resources or create new ones using Android Studio's standard resource editors.
Use Android Studio's code template wizards for creating activities, etc.
Pull in Android libraries (a.k.a. '.aar' Android archives) and have their manifests, code and resources automatically merged into the patched app.
And enjoy debugging support.
All in your favorite platform: Linux, Windows or macOS.
DexPatcher tool (Dalvik bytecode patcher)
Release notes: https://github.com/DexPatcher/dexpatcher-tool/releases
Sources: https://github.com/DexPatcher/dexpatcher-tool
DexPatcher Gradle plugins (Android build system and Android Studio integration)
Release notes: https://github.com/DexPatcher/dexpatcher-gradle/releases
Artifacts: https://plugins.gradle.org/search?term=dexpatcher
Sources: https://github.com/DexPatcher/dexpatcher-gradle
Samples: https://github.com/DexPatcher/dexpatcher-gradle-samples
Deprecated tools
Release notes for DexPatcher Gradle v1 plugins: https://github.com/DexPatcher/dexpatcher-gradle/releases?after=v2.0.0-alpha1
Support tools for DexPatcher Gradle v1 plugins: https://github.com/DexPatcher/dexpatcher-gradle-tools
Workflow automation scripts (Linux-only): https://github.com/DexPatcher/dexpatcher-tool-scripts
License
GPL v3 (or later)
THANK YOU ! - The DexPatcher tool uses JesusFreke's dexlib2 (part of smali) to read and write dex files. Many thanks to him for repeatedly helping me in #smali on freenode. When creating apk libraries, the DexPatcher Gradle plugin uses iBotPeaches' Apktool to decode compiled resources and pxb1988's dex2jar to translate Dalvik bytecode. DexPatcher could not exist without the invaluable work of these guys.
Documentation
PATCHING JAVA CODE IN JAVA
The DexPatcher tool uses declarative semantics based on Java annotations to patch the bytecode of the source application. There is no formal definition but hopefully you will find everything you need in this sample:
The sample code being patched.
The patch itself with explanatory comments.
The output of DexPatcher and test runs of the original and patched code.
START HERE !
With the new DexPatcher Gradle v2 plugins
Get the sample code working, here is how:
Clone the samples.
Start with the 'patched-app' sample: open the project with Android Studio, disable instant run, and run or debug your patched app!
Please review the release notes of recent versions of the Gradle plugins for more information on tool compatibility and environment setup.
In the 'patched-app' sample, browse the two 'build.gradle' files (main and app) to get an idea of what is happening. The plugins used are briefly described here. Next get inside the 'app' subproject and take a look at its manifest and resource files. These files are merged with the ones coming from the source app, which is located in the 'apk' directory. Finally look into the 'MainActivity.java' file to see how the compiled code of the app is patched using Java. This is handled by the DexPatcher tool, a key piece of the DexPatcher toolchain. See the section 'Patching Java code in Java' above for more details on this tool, and please review its recent release notes.
The DexPatcher Gradle plugins use Apktool to decode applications and optionally create APK libraries. They optionally use dex2jar to display decompiled application code and to import application code symbols into patch projects. They use the DexPatcher tool to patch the Dalvik bytecode of applications. And finally they use the Andoird build system to merge manifests, code, resources, assets, and extra files, and to repackage applications.
With the old DexPatcher Gradle v1 plugins
To get the old sample code working:
Install the support tools by cloning the repo anywhere you like.
Clone the 'v1' branch of the samples.
Set the 'dexpatcher.dir=<support-tool-dir>' property in identical files named 'local.properties' in the root directory of each sample so that it points to your local clone of the support tools. Create the files if necessary, or have Android Studio create them for you by opening the samples.
Start with the 'patched-app' sample: open the project with Android Studio, disable instant run, and run or debug your patched app!
Please review the old release notes of the Gradle v1 plugins for more information on tool compatibility and environment setup.
OLD NEWS: DexPatcher Featured On XDA Portal !
GermainZ wrote an excellent introductory article for XDA that walks you though the complete process of modding an app using the old deprecated Linux-only workflow automation scripts. This only covers the DexPatcher tool itself, ie: only patching of code, not resources. The workflow is deprecated, but the Java patch code and accompanying explanations are very valuable and continue to be current. I am grateful to him for having taken the time to do this. Please make sure you give it a read:
DexPatcher: Patch Android APKs Using Java.
Also available: [WARNING: Deprecated, Linux-only]
A how-to that will help you get started with the workflow automation scripts.
LICENSING UPDATE:
tl;dr: DexPatcher patches are no longer forcefully covered by the GPL.
Recent versions of DexPatcher no longer require that users bundle the DexPatcher annotations with every patch (although continuing to do so has no ill effects). The DexPatcher licensing terms no longer impose licensing restrictions on patches, as long as users refrain from bundling the DexPatcher annotations with them. In particular, DexPatcher patches are no longer considered to be derivative works of DexPatcher and thus are no longer automatically covered by the GPL. Legals aside, the DexPatcher project urges you not to use copyright laws to introduce artificial scarcity in the world. Please give back to the community: share your work.
XDA:DevDB Information
DexPatcher, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Source Code: https://github.com/DexPatcher
Version Information
Status: Stable
Created 2015-03-21
Last Updated 2019-11-09
DEPRECATED: Workflow Automation Scripts HOW-TO
DEPRECATED: Workflow Automation Scripts HOW-TO
These scripts bundle several tools (including DexPatcher) and automate boilerplate actions that are part of a typical workflow. They are available only for Linux. Take the leap today, get yourself free, get Linux Mint Cinnamon 64-bit.
Installation
Code:
# cd to a suitable install dir such as '~/opt' or '~/android/tools'.
git clone [url]https://github.com/Lanchon/DexPatcher-scripts.git[/url] dexpatcher
cd dexpatcher
chmod +x dxp-*
# edit 'dxp.config':
# -set the path to android sdk (defaults to '~/android/sdk').
# -disable bundled tools to use the ones in $PATH if desired.
# add 'dxp-*' scripts to $PATH:
# -symlink the 'dxp-*' scripts in a suitable dir in the $PATH such as '~/bin'.
# -or add the 'dexpatcher' dir to $PATH.
Sample Workflow
Code:
# cd to a suitable workspace dir.
dxp-setup-for-apk path/to/TheApk.apk
cd TheApk
dxp-create-keystore
# in 'src-cfr' you will find decompilation of the app to Java (with errors).
# you can use these files to plan your changes.
# in 'src-cfr-nocode' you will find decompilation of empty method stubs.
# you can use selected files as a basis for your patch.
# create your patch as Java files in 'src'.
# the symbols of the original app will be accessible to your patch code.
dxp-make
adb install -r patched.apk
The Big TO-DO List
The Big TO-DO List
...of things I would like done in this project, but that I will probably not have the time to implement myself.
DexPatcher-tool
Moved here: https://github.com/Lanchon/DexPatcher-tool/issues
DexPatcher-gadle
Moved here: https://github.com/Lanchon/DexPatcher-gradle/issues
DexPatcher and javac
Modify javac so that all source symbols -even those defined inside edited classes- are available during compilation. This could produce a patched javac executable, or the standard javac could be patched in-memory using java agents, or its in-memory data structures hacked from an annotation processor (a la Project Lombok).
Decide if dex2jar and jar2dex/dx are transparent and mature enough to move DexPatcher 2.0 to the java bytecode realm, and stop operating at the dalvik bytecode level. [UPDATE: It is not.] Or a VM abstraction could be implemented as a backend to DexPatcher so that the same font end could be used for both dex and class files.
If the project is moved to the java bytecode realm, decide if the new DexPatcher should be a standalone tool like it is today, or a java agent/annotation processor that modifies javac to do the patching during compile time. This would make the tool very easy to integrate into most build systems.
just added the documentation section
I checked docs and wow, massive Maybe you can make some easier examples how to use it (some small patches).
there is a lot of docs missing, especially regarding the workflow, how to extract and use symbols from the source apk, etc. for now im working on 0.2
UPDATE: version 0.2.0 released!
UPDATE: version 0.3.0 released!
Looks good
I will look at it more deeply when I found time.
I'm surprised there isn't so much feedback… May be could you add some examples / details in the OP?
PerfectSlayer said:
Looks good
I will look at it more deeply when I found time.
I'm surprised there isn't so much feedback… May be could you add some examples / details in the OP?
Click to expand...
Click to collapse
i still need to evolve the tool a little with respect to handling of fields, and then it's mostly done. but i need to document a full workflow, including obtaining symbols against which to build the patch (you want your patch code to be able to use all of the source app's code).
Very interested in seeing how this tool progresses. :good:
I still have no idea how to use this tool
UPDATE: version 0.4.0 released!
laura almeida said:
I still have no idea how to use this tool
Click to expand...
Click to collapse
take a look a the test run and samples. docs are very incomplete, but i guess you should understand them if you have experience patching apks in smali.
Lanchon said:
UPDATE: version 0.4.0 released!
Click to expand...
Click to collapse
Sorry for the small change; this beaks patches and so I wanted to push it out ASAP.
Click to expand...
Click to collapse
Don't worry for breaking patches.. Focus on making the better API / usage you can while you are in development. We will thanks you later
UPDATE: version 1.0.0-beta1 released!
An explanation of the workflow and some helper scripts should follow soon.
UPDATE: added Workflow Automation Scripts and HOW-TO
Lanchon said:
UPDATE: added Workflow Automation Scripts and HOW-TO
Click to expand...
Click to collapse
Tips: you could use the 2nd argument of git clone instead of running mv command
Lanchon said:
UPDATE: added Workflow Automation Scripts and HOW-TO
Click to expand...
Click to collapse
The speed of development is atonishing...
Keep up the good work!
UPDATE: DexPatcher featured on XDA portal !
includes full sample, please see the OP for details.
I assume you already have all your build packages installed. This guide is merely showing how to obtain a mirror copy of the android source for local purposes.
I will be using OmniRom for the duration of this guide, but for those who use CM or other projects, the concept should remain the same.
I do not expect this guide to be useful for everyone but there will be many who are going to be thankful that did not initially know this could be done.
Due to the rapid development, I ran into a huge issue pretty quickly when having to nuke/resync the various repos for building. The total space required for a full omni source is roughly 508,334 items, totaling 14.4 GB based on today from branch android-5.1 and requires pulling from a massive number of git repos online. So if bandwidth is an issue then constantly syncing after nuking the source could become an issue for you real quick. Not to mention the time it takes just to pull all of this data from the internet onto your computer.
However, by creating a Mirror of the source and its numerous git repos, the source is roughly 19,696 items, totalling 16.5 GB based on today from branch android-5.1.
Now, for those asking, why do a mirror? It is relatively simple. When using several sources, especially in situations where bandwidth is scarce, it is better to create a local mirror of the entire content, and to sync from that mirror (which requires no network access). The download for a full mirror is smaller than the download of two sources, while containing more information.
These instructions assume that the mirror is created in /path/to/home/android/mirror. The first step is to create and sync the mirror itself.
Code:
mkdir -p ~/android/mirror
Code:
cd ~/android/mirror
Code:
repo init -u https://github.com/omnirom/android.git -b android-5.1 [COLOR="Red"]--mirror[/COLOR]
Code:
repo sync -j# -f --no-clone-bundle
Basically this allows you to initialize a local mirror of an android repo (--mirror) and then later allow you to point subsequent repo pulls to that local copy which will be explained further into this guide. The mirror looks nothing like the actual source used to make builds.
Once the mirror repo has synced, then we are ready to establish the actual source in another directory that will pull directly from the mirror locally.
Code:
mkdir -p ~/android/omni
Code:
cd ~/android/omni
Code:
repo init -u git://github.com/omnirom/android.git -b android-5.1 [COLOR="Red"]--reference=/path/to/home/android/mirror/[/COLOR]
Code:
repo sync -j# -f --no-clone-bundle
Note the use of the ‘–-reference’ parameter. This uses my local mirror of the android sources instead of pulling across the network again.
Now I can pull one of the various repos, using that same ‘--reference’ parameter (pointed at my local omni mirror) and profit!
From here on out, should I want to update the omni source with the latest changes I just go to the mirror directory and run:
Code:
repo sync
Then, I switch over to the omni directory and run the same command to pull those changes from the local directory.
Even further, should I nuke something in the omni directory, I can simply delete it and run repo sync to pull from the local mirror to fix the problem and never have to worry about pulling data from the network itself.
Here is an example for a clearer picture:
I make changes in /android/omni/bootable/recovery
I do not like the changes I have made
I delete /android/omni/bootable recursively
I run repo sync to restore /android/omni/bootable
The sync pulls from the local mirror instead of downloading the repo from the internet.
Time for syncing is cut in half if not more
Everything is still intact
Thanks for that bro us Linux noobs will find it very useful
IntroductionSo, I will start off by telling a little bit about myself. I got interested in Android building in November 2017. I found most of the guides "inadequate" for pure newbies like me.
This is my second guide and the first one for No-Knowledge newbies so please do correct me . I will also add some humor so you don't get bored
The guide will be divided into a few parts-
Using linux and enjoying it(No offense to GNU/Linux enthusiasts. please don't start a debate, its just my personal opinion)
Basic git for complete newbies
Compiling your first ROM(Lineage)
Compiling your first non-Lineage ROM
Choosing a Programming lanugage
Basics to resolving conflicts
Compiling AOSP-based roms for CAF devices(For which I couldn't find a guide)
It will probably take a while for you to read this but its must to read everything carefully. Lets start off right away
Using Linux and Enjoying it!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
There are more than adequate guides for using Linux. I will just help you choose the distro and recommend some guides
Personally, I used Linux wayyyy before I started building android(~2013) I didn't do much at first so I got most of my Linux experience in 2016-2018
Some distros I recommend-
Ubuntu 16.04 or 18.04 (Probably the best for newbies imo) - https://www.ubuntu.com/download/desktop
Arch Linux(Could be problematic to install for newbies so I recommend you install Antergos first - https://Antergos.com/try-it/ )
Linux Mint - https://linuxmint.com/download.php (Newbie friendly)
Debian GNU/Linux (Easier than Arch imo, slightly(very slightly) harder than Ubuntu) - https://www.debian.org/
You absolutely MUST live boot them and feel them. I highly recommend you to install them on a small partition(~40GB) to get the best experience. Please don't use linux on a server at first!
I personally started with Ubuntu 12.04 for a month or so, 14.04 as well for a few months. I became a daily user when 16.04 came out.
Currently, I am using Antergos. However, for building I liked Arch as it had everything "bleeding edge"(Search it if you don't know what this means xD)
Here are some absolutely noob friendly guides-
https://www.youtube.com/watch?v=opBKvGi77cU
For Ubuntu (Long guide but indepth!)
https://www.youtube.com/watch?v=G0AFuhVSvEk
For Linux Mint (Again, Long but indepth!)
Use them for atleast a week or two before you even jump into android building! A month of daily usage is recommended so you know how to tackle basic problems. Youtube will always be your friend and so will be google. You can't hate Linux once you know how to use it! The only reason why I use Windows is because of gaming and applications such as Photoshop and Illustrator(I know there are alternatives, again just my personal opinion!)
See you after a week! No? Seriously use linux for atleast a week!
Using Linux will also hone your google skills(Not even kidding)
Basic git for complete newbies
Personally, I myself don't do advanced stuff with git myself and here are the subcommands you will be using the most with git -
clone
cherry-pick
revert
merge
commit
push
I will give a brief explanation of each and link some guides! Why brief? Because I expect you to have a thinking like a linux user now . Also, you can switch to a server now!
Here is a playlist by github -
https://www.youtube.com/watch?v=noZnOSpcjYY&list=PLg7s6cbtAD15G8lNyoaYDuKZSKyJrgwB-
If you are not satisfied(I wasn't) you can search youtube for a specifc command as well! (i.e cherry-pick)
clone -
Simply clones the repository including its commit history!
Usage-
Code:
git clone <repo> -b <branch> <directory>
If you don't specify a branch, it will clone from the default branch.
If you don't specify a directory, it will make a folder with the name of the repo
Example -
Code:
git clone https://github.com/ChimeraKernelProject/chimera_land-current -b lineage-16.0 chimera
(Shameless self advertising xD)
cherry-pick-
Generates a diff from a commit and applies it to the local repo
Usage-
Code:
git cherry-pick sha
You do need to fetch the repository from which you are picking a commit
Using-
Code:
git fetch <repo> <branch>
If the branch isn't specified, it fetches the default branch instead
Cherry-picking multiple commits-
Code:
git cherry-pick sha1^..sha2
This picks all the commits from sha1 to sha2(i.e the commits between sha1 and sha2, including sha1 and sha2)
You may or may not get a conflict for which I will have a seperate section.
Example-
Code:
git fetch https://github.com/ChimeraKernelProject/chimera_land-current lineage-16.0
git cherry-pick 9e8a821ba64f5b498843b025d1804e3818dda480^..8e80e52915492328e80378f7ecff0cb44fdc1344
(Try figuring out what I did )
What is SHA you ask? You don't have to know what it actually is so just consider it to be an identifier for a commit.
revert
Generates a diff of the commit and reverses it(pretty much the opposite of cherry-pick)
The usage is same as cherry-pick.
merge
Kind of like cherry-picking multiple commits but it compares the history of the local and the remote and then generates a common diff for the commits that are not in local
Also, you do need to fetch before merging.
Usage-
Code:
git merge <remote>
Example-
Code:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git v3.18.125
git merge FETCH_HEAD
(The example here is of upstreaming the kernel )
commit and push
Generates a commit for staged files
Usage-
Code:
git commit -m "some message" -m "sub-message"
some optional parameters-
--signoff
--author="name <author email>
If you forgot to add a file to the commit, you can -
Code:
git commit --ammend
Again, you can use the optional parameter.
how to stage files you ask?
you simply use-
Code:
git add <filepath>
If you did your linux lessons correctly, you might know that, you can use "." and ".." in filepath(redo them if you don't know xD)
finally, to "push" your changes to a remote repo-
Code:
git push -u <repolink>
It will ask for authentication. You use your github(or whatever you prefer) account for that.
After using -u once, you won't have to pass the parameter again.
Lets end this with an example-
Code:
git add .
git commit -m "add 69 hour battery life" -m "best" --signoff --author="someone <[email protected]>"
git push -u https://github.com/ChimeraKernelProject/chimera_land-current
(Also please don't use a stupid commit message like the one I showed xD. This one was just for the lulz)
This one was big. oof. Took me a while to write and probably will take a while for you to read too .
You might ask why did I tell you to search xyz in this one so much! Simple reason- I want you to get used to searching your problems!
Mastering git takes alot of time! I am not any good myself and I search alot of stuff on google myself! (Sometimes even problems related to merging and checking out!)
Compiling your first ROM(LineageOS)
I bet you have been getting restless by now! The previous guides were to build the excitement to build your first ROM!
Why Lineage? Simple. Its one of the easiest ROM to build. Pretty well documented and most importantly, alot of video guides to check if you are confused at any point!
It is highly recommended to use a server at this point as you will be pulling alot of data and you will require alot of processing power.
You can build locally if you have good internet.
Here are the minimum requirements(imo)-
i3 6100 or equivalent
8 GB RAM
300GB HDD(500 GB+ is highly recommended)
Lets start off by the dependencies. I am assuming you are on Ubuntu or Linux Mint. These are the dependencies you need to install -
Code:
openjdk-8-jdk
git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev libxml2-utils xsltproc unzip
You know how to install them don't you now
Lets install Repo now-
Code:
mkdir ~/bin
edit your .bashrc in the home directory with your preffered file editor(I use nano) and add this line to the bottom (Hint - hold pgdwn to jump to the bottom quickly)-
Code:
PATH=~/bin:$PATH
Then execute these commands-
Code:
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
Code:
chmod a+x ~/bin/repo
Lets sync Lineage now shall we
First add your github account to the git config using-
Code:
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
Here, you should use your github email! (See https://help.github.com/articles/about-commit-email-addresses/ if you don't want to use personal email)
Make a dir in which you will do the rom stuff and cd to it
Before we initialize and sync LineageOS, you have to decide which branch you are choosing as well
You can check your device forum and see what Android versions does the device have. PS- You might wanna check the LineageOS thread. The developer must have provided a link to their kernel source(If they didn't, report the thread to mods kek). Click and navigate through their github. you will find a repo named- android_device_(vendor)_(devicecodename) . you probably know the vendor and the codename from the forum don't you?For example its- android_device_xiaomi_land for my device(Yea right I have an old as hecc device pls no laugh ). Check the branch of the ROM. It will probably something like lineage-16.0 or 15.1 etc. Also if you have an official device, you can check its branch at- https://github.com/LineageOS .
Welp now you know the branch, lets start!
Code:
repo init -u git://github.com/LineageOS/android.git -b <branch>
repo sync
To sync a little bit faster, here's a better command I got from StatiXOS git -
Code:
repo sync -c -f --force-sync --no-tag --no-clone-bundle -j$(nproc --all) --optimized-fetch --prune
Also, if your sync stopped midway because of your ISP(BSNL :'( ), you can just start the sync again.
If you are on another distro such as arch, you might have to do some extra steps- https://wiki.archlinux.org/index.php/android#Building
Now that you have synced, You may choose one of the 2 paths-
If you have official LineageOS, choose me!
Setup the environmental Variables with-
Code:
source bu*/e*
Clone your vendor blobs from TheMuppets repo - http://github.com/TheMuppets
or, from your preferred developer.
The usual repo name is proprietary_vendor_(vendorname). For example, in my case its proprietary_vendor_xiaomi . It should have a folder with your device codename
If not, try changing the branch!
You should be cloning them to vendor/(vendorname)
start bulding right away with-
Code:
brunch lineage_<codename>-<buildtype>
here, codename is your device codename and buildtype is one of these-
user, userdebug, eng .
I recommend userdebug at first. user builds are pretty much as limited as your stock rom. eng builds are actually the one you should use for debugging the rom. These are not secure for daily usage.
This will start the build and you probably won't get an error as its official. If you do, you can just search it up on google. Once the build is done, you will get filepath in the command output. Generally, the build is in
<workingdir>/out/target/product/<codename>/xyz-UNOFFICIAL.zip .
If you have unofficial Lineage, choose me!
I am assuming you are in the working directory
Welp, lets start off by searching for the required trees.
Here's what you need-
Device Tree
Kernel Source
Vendor Blobs
Usually I find them by checking the post of the unofficial Lineage thread and click the kernel source link(Again, if they didn't post it, you should report the thread ). Go to the dev's profile and check his repositories. Here are the usual naming schemes for each one of them-
Device tree - android_device_(vendorname)_(devicecodename)
Kernel Source - android_kernel_(vendorname)_(devicecodename) or! android_kernel_(vendorname)_(soccodename)
Vendor Blobs - proprietary_vendor_(vendorname) or, proprietary_vendor_(vendorname)_(devicecodename)
Device tree should be obvious. It should be cloned to - device/(vendorname)/(devicecodename)
As for kernel tree, soccodename menas the codename of the SoC you have in the device. The thread should have it already as the kernel is licensed in GPL v2(GNU Public License V2, for more info check - https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html ). To know where you need to clone the kernel tree, check the "BoardConfig.mk" of your Device tree and check the "TARGET_KERNEL_SOURCE" line. It tells where you need to clone the kernel
vendor name should be obvious as well now. If your vendor name doesn't have the codename, it should be cloned to vendor/<vendorname>
if it has the devicecodename, it may or may not be the device tree and still be like this-
If it doesn't look like this, it should be cloned to vendor/<vendorname>/<devicecodename>
Here's the repo list of an ideal dev-
Setup environmental variables-
Code:
source bu*/e*
Start the build! -
Code:
brunch lineage_<codename>-<buildtype>
here, codename is your device codename and buildtype is one of these-
user, userdebug, eng .
I recommend userdebug at first. user builds are pretty much as limited as your stock rom. eng builds are actually the one you should use for debugging the rom. These are not secure for daily usage.
Now since you are using an unofficial tree, it is likely that you might hit an error. One of the most common error is when brunch is unable to find your target device. a simple fix for that is to navigate to your device tree and make a file called "vendorsetup.sh"
It should have this line in it-
Code:
add_lunch_combo lineage_<codename>-userdebug
where(you guessed it), codename is your device codename. Run the environmental variable setup again and you should be ready to build.
You might hit errors. Google is always your friend. If you are absolutely sure that you can't find it on google, check the help group section in the thread!
Once the ROM is ready, you will find the filepath in the command ouput. Generally its in out/target/product/<codename>/xyz-UNOFFICIAL.zip
Uploading files to google drive
There's a really nice guide availabe here- http://olivermarshall.net/how-to-upload-a-file-to-google-drive-from-the-command-line
Congratulations! You just made your first rom. If you find this hard, this is just the beginning! There's a very rough road ahead.
Compiling your first Non-Lineage ROM
PS. - The ROM has to be "Lineage-based".
thee aren't eft f'r aosp bas'd roms!
I will be using XenonHD as an example as it is pretty easy to build and it was pretty much one of the first roms i ever built.
Building a Lineage-based rom is as easy as building Lineage!
You go to the rom's git(I usually google search or check it in one of the rom's thread for any device) and check the repo manifest. The usual naming scheme for a repo is-
android_manifest
platform_manifest
manifest
android
etc.
In xenonHD's case, its platform_manifest(and all other repo names will start with platform prefix)
A proper ROM source should have the syncing instructions and building instructions. Lets check the XenonHD's example
make a working dir for the rom in which you will do your rom stuff.
Initialize and sync it. The initializing and syncing part is always the same across the ROMs. (You know which branch to use now. Don't you?)
Again, clone all the required trees!
Now now now, don't get excited yet! Before you start brunching, there is some stuff you need to change.
Usually you can refer to one of the official trees in the ROM organization. For example, https://github.com/TeamHorizon/android_device_xiaomi_kenzo has proper commits. You should be looking at the "Initial XenonHD" commit. You can obviously ignore commits like https://github.com/TeamHorizon/andr...mmit/c076f8c7199d0cddbe6a1e0d05bf3ffc63080d1d as they are device specific. The basics are always the same-
Rename lineage.mk to (romname).mk . refer to the device tree if you are unsure about the romname
edit the (romname).mk and change all the lineage instances to (romname). refer to the commit if unsure.
rename lineage.dependencies to (romname).dependencies .
Renaming the kernel defconfig isn't really necessary so you can ignore that.
Setup the environmental variables(Same across all the roms)-
Code:
source bu*/e*
start the build using the supported command given by the ROM devs.
Code:
brunch codename-<buildtype>
in XenonHD's case. However its different across most of the roms so never forget to read manifests!
You are more likely to hit errors with these spinoffs. Google is your friend(I can't remember how many times I have repeated this) and so is LineageOS repo! You have alot of references if the error is not device specific. Learn to fix derps! Check the help groups sections and ask if its absolutely necessary! Again, the command output will have the filepath of the final ROM zip!
You aren't ready yet. You need to gain alot more experience in compiling ROMs and here are some ROMs that you should be able to build at this point- Resurrection Remix, DotOS etc. Most of the lineage based roms support brunch. (Be careful tho, as a few AOSP based roms support it too. You might have a hard time compiling those!)
Choosing a programming language
At this point, it is highly suggested to learn a programming language if you want to escape the Buildbot stage. I am not forcing you, but you will have alot of trouble in doing advanced stuff.
There are several beginner friendly languages-
bash (the easiest)
Python (Recommended)
Kotlin (Android App development, quite easy)
Harder, recomended to learn after the easy langages-
Java (Gotta learn java if you want to make your own custom ROM at some point :3 )
C/C++ (Other than System UI, most of the other stuff for Android is written in C or C++)
Anything else you like! Once you get the basics, its not hard to learn another language .
The reason why I recommend Python is because it was the first language I learnt! Its pretty easy(Though, the OOP, Object Oriented Programming part is slightly advanced). It has wide applications and THE preferred language for Machine Learning and AI stuff, Period(OMG BUZZWORDS).
Kotlin is also fairely easy. I haven't programmed much in kotlin though I know basic syntaxes. If you learn it first, you won't have much trouble with learning Java. Probably. You can learn Java at first as well but you might have trouble! C is a must learn if you want to modify the Kernel and C++ is a must if you want to modify other code like HALs!
Python takes a day or two to learn! Not even kidding. I recommend this nice playlist by CSDojo - https://www.youtube.com/watch?v=Z1Yd7upQsXY&list=PLBZBJbE_rGRWeh5mIBhD-hhDwSEDxogDg
If you are interested in programming Machine learning, I recommend this playlist- https://www.youtube.com/playlist?list=PLOU2XLYxmsIIuiBfYad6rFYQU_jL2ryal
I learnt Kotlin basics from this Video - https://www.youtube.com/watch?v=H_oGi8uuDpA but there are more advanced videos as well.
I can't link Java tutorials as I haven't learnt it and nor do I plan to anytime soon. You can of course check youtube .
I learnt C from books and The C programming language by Dennis Ritchie and Brian W Keringhan is a must read! I quite liked "Programming in ANSI C" by E. Balagurusamy as well. You can of course, learn it on youtube.
Getting into programming takes a while and you might not like it at first but if you do, you will always enjoy it!
Basics To Conflict Resolution
It is assumed that you have a mind of a programmer and thus the guide will have alot less spoon feeding!
Lets get back to git and discuss about Conflict resolution. From time to time, you might want to cherry-pick something or perform a merge and you might get a "conflict".
Here's a basic idea!
The code between <<< HEAD and ===== is your previous code and the code between ====== and >>>> (commit SHA) is the new code from the commit. You get this if a part of the file in the commit is not the same as your local file.
There are 3 possibilities -
The code between <<<< HEAD and ===== is not required, thus you can delete that (Mostly)
The code between ===== and >>>>> is not required, thus the new change is not required (Rarely)
Both the old code and the new code is required (Pretty common!)
How do you decide between the three? You actually check the commit you are picking. In case of a merge, you can just view the history of a file and check the changes on github. Mostly, that should be enough for a decision. In case of a conflict while upstreaming my kernel, I usually refer to android-linux-stable project - http://github.com/android-linux-stable . Other times, I actually use my brain and figure out the option myself!
Compiling AOSP-based roms for CAF devices
Welp, I took alot of your time! You surely learnt plenty. Its the final part of this guide Took me a while to write all this ;_; .
I am assuming that you are fairly experienced now and you have atleast basic programming knowledge and plenty experience with git.
For starters, I recommend you to try AOSIP! It is highly compatible with Lineage trees and it shouldn't be much trouble to modify your device tree for it.
No spoon feeding at this point . Lets revise the basic idea! -
Find the rom source
Find the appropriate branch
Check the manifest for syncing and building instructions
Refer to another device tree(Possibly a tree of a similar device) and modify your device tree! (The hard part as its different from lineage based roms)
Environment setup
Start the build
Most of the AOSP-based roms use these commands-
Code:
lunch <codename>-<buildtype>
Code:
mka bacon
The lunch part is always there in Maximum AOSP based ROMs and the building command maybe different(i.e
Code:
time mka kronic
in AOSIP)
Another part I want to mention is about "HALs" . Usually most of the ROMs (even AOSP-based) ship with CAF HALs and support project pathmaps. However, some ROMs don't. Probably because they are not intended for CAF devices or the sources aren't properly complete yet! To build these ROM succesfully, I clone the CAF HALs from the lineage repo. These are- display-caf, media-caf, audio-caf, bt-caf and wlan-caf.
The first 3 HALs are usually platform specific so do check the branch on LineageOS! (for example, its lineage-16.0-caf-8996 branch for 821 series family SoCs for pie). The next step is to remove project pathmpas from both the device tree and the HALs. You can refer to the changes done by PedroKalil -
https://github.com/KAOSP/platform_hardware_qcom_display-caf/commits/aosp-8.1-8996
https://github.com/KAOSP/platform_hardware_qcom_media-caf/commits/aosp-8.1-8996
https://github.com/KAOSP/platform_hardware_qcom_audio-caf/commits/aosp-8.1-8937
Don't be lazy. Don't clone these HALs as these are outdated! Refer to them and do the appropriate changes on the latest Lineage HALs. the libbfqio changes may not be required as alot of AOSP-based roms have started to ship with it.
As for the Changes required in Device tree, you can refer to -
https://github.com/rupansh/pie_device_xiaomi_land/commit/c118701ba20a70fd59e32833417adeb7b08ab1d0 (The custom Audio policy is probably already enabled so no need to do that)
and https://github.com/rupansh/pie_device_xiaomi_land/commit/23215a2d8d5f1976657190f2a8f19f3fd111c250 (Depends on the path you cloned your HAL to)
You should now be able to compile any AOSP-based ROM! Experience is the key. Some other AOSP-based roms I recommend - NitrogenOS, AEX, AOSCP, Pixel Experience(Fairly easy), Pixel Dust(One of the hard), AOSPA( teach me when you fix the cneserver error lulz) .
Thats all you need to know to build AOSP-based ROMs for CAF devices .
If you wish to get into Android and Linux Kernel Development, Learning C is a must! I recommend this guide by nathanchance if you are ready! - https://forum.xda-developers.com/an...erence-how-to-compile-android-kernel-t3627297
Groups for help
https://t.me/AndroidBuildersHelp
https://t.me/LinuxKernelNewbies (Linux Kernel only)
Your device groups
Let me know if you want your group here
Credits
@tanish2k09 and @Swapnil Soni ( For guiding me even though I had 0 knowledge, co-operating with my idiotic requests)
ABH (Helping me realise that you can fix most of the errors by just searching properly)
@nathanchance (for his awesome kernel guides)
@KalilDev (For helping me with building AOSP based roms)
@ZeroInfinity (For machine learning tutorials kek)
@riteshsaxena (Bess sources for reference xD, Helping me with pie bringup which caused rapid progress for me)
You, the reader
I hope you learnt plenty of stuff from the guide. It took me a while to type this you see :3 .
awesome sir
rupanshji said:
@KalilDev (For helping me with building AOSP based roms)
Click to expand...
Click to collapse
This is one of the best or the most helpful guide I've ever read! I'll Recommend this for anyone who wants to join the ROM building club.
10/10 tutorial, thanx dev.
Thank you for this, OP
any guide like this for mtk devices?