yashsingh1/xdaforums huggingface dataset:
[Nexus 7 Android Development] Nark.GA60:
You can also just add to the PATH from the command line.

export PATH=$PATH;/path/to/adb

Also check that you've done the udev rules, otherwise only root can adb.
[Nexus 7 Android Development] p0isonra1n:
I did both adding it to bashrc and the command you said and it still doesn't work. I even added the full path to adb and some error.

---------- Post added at 10:54 AM ---------- Previous post was at 10:48 AM ----------

I fixed it. i found that in the extract-files.sh it sends the command adb pull it needs to be ./adb
[Nexus 7 Android Development] totalentropy:
How would I go about adding my own APKs to the build process?

Along those same lines, how would I add gapps to the build process? (Of course, not for distribution)
[Nexus 7 Android Development] kumite2010:
Got it to work as well with changing "git" to "https"

After several nights of frustration I knew someone in this thread would have the answer
[Nexus 7 Android Development] sparksco:
We already covered that in yesterdays discussion, or did you forget?

---------- Post added at 01:08 AM ---------- Previous post was at 01:03 AM ----------

Oh and BTW Cyanogen was the one who fix the prebuilts issues

https://github.com/CyanogenMod/android/commit/60f3908aecd8ed49480fe196bd9f780f8ca9ac8f
[Nexus 7 Android Development] kumite2010:
Not at all but after going through several "fixes" for the _prebuilt issue I just wanted to clarify that this solution worked for "me."

But I'm curious now, did changing git to https actually make the difference or by then did Cyanogen's changes already go through which corrected the prebuilt error?
[Nexus 7 Android Development] sparksco:
For general syncing errors the https fix is good. Not everyone has them but I personally know quite a few that have. I didn't encounter the prebuilt error issue yesterday until after our discission on it so I guess it affected some people faster than others.
[Nexus 7 Android Development] dsuycott:
after some problems i went back and started over...everything was going great i ran the ~/bin/repo sync -j16, a Sh** storm of fun was happening so i left it overnight, when i woke up today it wasn't a xmas tree full of gifts that santa had left it was this! drats!!! terminal was just flashing a white box under the last line...i've searched a bit this a/m but haven't found anything of much help, although admitidly i'm getting kids ready for school and haven't had a ton of time...anyone? should i just kill terminal and re-run the repo sync -j16?

Thanks in advance.

From https://android.googlesource.com/platform/prebuilt

* [new branch] ics-plus-aosp -> aosp/ics-plus-aosp

f37f794..e7aee28 jb-dev -> aosp/jb-dev

* [new tag] android-4.1.1_r1 -> android-4.1.1_r1

* [new tag] android-4.1.1_r1.1 -> android-4.1.1_r1.1

* [new tag] android-4.1.1_r2 -> android-4.1.1_r2

* [new tag] android-4.1.1_r3 -> android-4.1.1_r3

* [new tag] android-4.1.1_r4 -> android-4.1.1_r4

* [new tag] android-cts-4.1_r1 -> android-cts-4.1_r1
[Nexus 7 Android Development] sparksco:
What's wrong with new branches?
[Nexus 7 Android Development] dsuycott:
thanks for the reply!

usually it goes back to prompt like

****@****:~$

now it's just sitting on a flashing white block...is that ok?
[Nexus 7 Android Development] sparksco:
It sounds like it might be stuck, might have to start over. A lower sync might help like -j2 or -j1
[Nexus 7 Android Development] dsuycott:
thanks! had that feeling.
[Nexus 7 Android Development] SirDzstic:
I'm running Gentoo stable and the source builds fine, but when I try to run the emulator, I only get a black screen.

This is the same for CM and the Google sources when I select grouper in lunch. With a generic build of the Google

sources, the emulator works.

Is this behaviour normal? I'm not comfortable with flashing my device with a ROM that doesn't even run in the emulator.
[Nexus 7 Android Development] hopscotchjunkie:
Yes. The generic build is compiled to run on the emulator. The grouper build is compiled to run on the hardware in the tablet. You couldn't flash a build compiled for the emulator to your n7 and expect it to work, and vice versa.
[Nexus 7 Android Development] skeeterslint:
Anyone else besides me having issues opening up the google doc>I am only getting the first page then it errors saying to reload the page or download the doc.I would download it but can't find a page to do it from.
[Nexus 7 Android Development] p0isonra1n:
Editing Source

I have followed all the steps and have successfully compiled the rom. I now want to modify it like adding more default application and changing the default settings in settings and other modifying stuff.

Thanks for any help.
[Nexus 7 Android Development] mateorod:
So i was hoping someone could help me out with something. I have been trying to find this out for awhile.

I have source for a bunch of roms on the computer i do my projects on. But i have several other computers i have fixed up and now use for various purposes in the house (server, wife, kid .etc).

For one of my projects, i would ideally be building roms pretty much constantly. I regularly need to build aosp,cm,aokp and pa and the downtime or loss of resources on my main machine is hard to schedule. I would like to use my other machines to build over my local network. I have even seem Google say that keeping your sources on a separate drive has been found to be better.

I don't really want to download and keep different sources on each hard drive. I have tried symlinking the source and .repo folders, but haven't had any success. I have the correct permissions so i am not sure what i am missing.

Has anyone here successfully done this and have some tips?
[Nexus 7 Android Development] SirDzstic:
Have you tried distcc er is it something else you want?

I'm not sure if I understand you correctly.

Gesendet von meinem Nexus 7 mit Tapatalk 2
[Nexus 7 Android Development] Beekersguy:
I am also wondering this. I'm really new to Dev and Linux, and I have tried a lot of different ways to implement apks into the build (or any build) ending with an error and no build. I feel like I'm missing a step somewhere.

Edit: I have completed a straight build from source, and successfully flashed it. Thanks a ton!

Now I would like to start with source and change some stuff like launcher, su app, etc.

[signature]
[Nexus 7 Android Development] Nark.GA60:
So the source code is on your main PC but you want to build on the other machines? You can mount the directory on the other machines using NFS. Building from a network-mounted drive might be slow, though.

You can also schedule builds every day (say at night when you're asleep) by setting up a cron job.
[Nexus 7 Android Development] SirDzstic:
In that case, distcc really is the more reasonable

way to go.

Gesendet von meinem Nexus 7 mit Tapatalk 2
[Nexus 7 Android Development] marty331:
You can add them as system apps.

/system/apps
[Nexus 7 Android Development] Beekersguy:
Do I add this directroy to source, or add the apks after it compiles?

Edit: Found the info I was looking for. Sorry for the clutter!
[Nexus 7 Android Development] mateorod:
Thanks guys. I had them mounted as NFS already, and had set permissions, but was still having weird troubles. Turns out that I needed to set permissions for parts of the .repo folder with sudo.

I will look into distcc for sure. These are all old machines that I repaired by hand. They had broken screens or other signs of misuse and had been sitting in a drawer for a couple years until I caught the Android bug. Linking them all together would hopefully mitigate some of the resource limitations. I have some shell scripts set up for the builds to run through cron already, so i think everything else is just logistics.

Thanks for the responses and suggestions. I just couldn't run four or five builds a day through my main computer anymore.

Edit: Doesn't look like java is supported, and probably some other dependencies would be unresolved.. But it was a good point that I should look into some sort of compile farm, and I am sure there is something similar I can use. Thanks for the inspiration.
[Nexus 7 Android Development] Nark.GA60:
Let us know how you go. I'm curious.
[Nexus 7 Android Development] SirDzstic:
I tried to build CM in VirtualBox on Windows. I installed Ubuntu 12.04.1 LTS and everything is fine

until after syncing the repository. I can't connect the Nexus to the virtual machine. It doesn't show

up in the USB device menu and adding a manual filter doesn't work either. I used the following

settings:

Vendor ID 18d1

Product ID 4e42

Revision 9999

Remote: any

Any tips on this?
[Nexus 7 Android Development] AndDiSa:
@fattire

Thank you very much for starting this useful thread. I've got my N7 last week and I am quite happy with it. Now I wanted to start to compile JB/CM10 by myself. Unfortunately my development environment is completely 32-bit (it's an old Dell Pentium 4 system) :(

All tutorials I found up to now are saying you need to have a 64-bit environment.Do you see any chance to set up a 32-bit environment for JB compilation?
[Nexus 7 Android Development] nightmw:
Since Gingerbread it is required to have a 64bit environment. Try to update your system instead :(

Sent from my Nexus 7
[Nexus 7 Android Development] Phil3759:
I tried it too and it fails.

No other way then 64 bit environement
[Nexus 7 Android Development] AndDiSa:
Well gingerbread builds on 32-bit without any problems, so I was hoping someone got JB to build on 32-bit, too.

---------- Post added at 07:31 PM ---------- Previous post was at 07:29 PM ----------

... so I need to buy a new machine :(
[Nexus 7 Android Development] Nark.GA60:
Slightly OT question.

Nightlies have started appearing for the One X so I thought I'd build for that as well but when I do a lunch, I don't see endeavouru in the list. Do I need to do a new repo init? Or am I doing something wrong?

/noob
[Nexus 7 Android Development] SirDzstic:
Did you try an x86_64 cross compiler or is it known that doesn't work either?
[Nexus 7 Android Development] AndDiSa:
For those of you, who are interested in building CM10 on a Linux 32-bit environment: it's possible!

You need to sync the cm10 repo and afterwards you have to follow the instructions from https://github.com/yath/android_prebuilts_gcc_linux-x86-32_arm_arm-linux-androideabi-4.6.

My new machine has to wait another few months now ;)
[Nexus 7 Android Development] M3drvr:
Step 4 won't work for me. After I type in "lunch" it tells me to pick a combo. So i pick the "22. cm_grouper-userdebug" one and then i get an error.

/bin/bash: bison: command not found

Looking for dependencies

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

/bin/bash: bison: command not found

============================================

PLATFORM_VERSION_CODENAME=REL

PLATFORM_VERSION=4.1.1

TARGET_PRODUCT=cm_grouper

TARGET_BUILD_VARIANT=userdebug

TARGET_BUILD_TYPE=release

TARGET_BUILD_APPS=

TARGET_ARCH=arm

TARGET_ARCH_VARIANT=armv7-a-neon

HOST_ARCH=x86

HOST_OS=linux

HOST_OS_EXTRA=Linux-3.2.0-25-generic-x86_64-with-Ubuntu-12.04-precise

HOST_BUILD_TYPE=release

BUILD_ID=JRO03R

OUT_DIR=out

============================================

What to do with this now?
[Nexus 7 Android Development] AndDiSa:
You need to install the bison package on your PC.
[Nexus 7 Android Development] fattire:
new binaries

that's right (re: bison).

Also, a heads up-- new binaries have dropped for N7. These are the prop files that you previously extracted from your device, and I think these new ones would go right on top (ending up in the /vendor/* directory).

I haven't tried them, but I'm due for a new build so I'm going to do so now.
[Nexus 7 Android Development] sparksco:
Might want to take note that you need to be on Stock ROM to pull binaries as some ROMs might not have them already included.
[Nexus 7 Android Development] fattire:
No, you don't need to be on stock rom--

these binaries are replacements for the roms on stock N7s, meaning they should be better than what comes on stock.

There are some new binaries now provided by google on the site, meaning that after these files are extracted over /vendor that some changes need to be made, namely:

Edit /vendor/asus/grouper/proprietary/Android.mk

remove this:

include $(CLEAR_VARS)
LOCAL_MODULE := glgps
LOCAL_MODULE_OWNER := broadcom
LOCAL_SRC_FILES := glgps
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := EXECUTABLES
LOCAL_MODULE_PATH := $(TARGET_OUT)/bin
include $(BUILD_PREBUILT)

and this:

include $(CLEAR_VARS)
LOCAL_MODULE := gpsconfig
LOCAL_MODULE_OWNER := nvidia
LOCAL_SRC_FILES := gpsconfig.xml
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_SUFFIX := .xml
LOCAL_MODULE_CLASS := ETC
LOCAL_MODULE_PATH := $(TARGET_OUT)/etc/gps
include $(BUILD_PREBUILT)

and this:

include $(CLEAR_VARS)
LOCAL_MODULE := gps.tegra3
LOCAL_MODULE_OWNER := nvidia
LOCAL_SRC_FILES := gps.tegra3.so
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_PATH := $(TARGET_OUT)/lib/hw
include $(BUILD_PREBUILT)

and this:

include $(CLEAR_VARS)
LOCAL_MODULE := touch_fw
LOCAL_MODULE_OWNER := asus
LOCAL_SRC_FILES := touch_fw.ekt
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_SUFFIX := .ekt
LOCAL_MODULE_CLASS := ETC
LOCAL_MODULE_PATH := $(TARGET_OUT)/etc/firmware
include $(BUILD_PREBUILT)

The extract script is going to have to have some changes to reflect this, but I'm putting it here now for an FYI.
[Nexus 7 Android Development] sparksco:
I hate to say but I believe your mistaken fattire. I already downloaded and used the extraction scripts earlier. I get this for Broadcom

http://pastebin.com/jJyaw6rx

and this for elan

http://pastebin.com/TPPxUBSB

and this for invensense

http://pastebin.com/dBEPNGsk

and this for nvidia

http://pastebin.com/yVtZ1RV4

and this for widevine

http://pastebin.com/9YXjp7bM

These are all prebuilt binaries not source binaries that are originally from the Stock factory ROM
[Nexus 7 Android Development] fattire:
Do an MD5 comparison...

Yes, they are indeed all prebuilt binaries aka "props" aka "blobs". But at least one vendor archive (broadcom, which now includes the GPS components, which it did not previously) has been changed, and one vendor archive (elan, which has the touchscreen firmware) has been added.

As I mention, previous to today's stuff, the touchscreen and gps binaries were not included on the web site, and since google had not provided a model for where they should go, and so the extract-script just stuck them in the asus/grouper/proprietary directory and the Android.mk made sure they got installed. Now that the google files put them in a new place (vendor/elan and vendor/broadcom/grouper with the other broadcom stuff), the script needs to be modified to also use those locations.

I did an md5 of the gps and touch_fw and they seem to be the same to stock. Dunno about whether anything else had been updated, but it's possible that the files are the same even though the location for gps/ts_fw changed. They are a whole new set though. (You can see the new vs. old list right here). Note the different checksums for the files.. something is different.

Someone downloading both JRO03C and JRO03R, then doing an md5 comparison will settle if the files are indeed updated. The location change though means anyone running the google script after running extract-files is going to need to make the Android.mk changes as I suggested, until the extract-files script is updated. Any volunteers? :)

PS-- I just did a build and it works.
[Nexus 7 Android Development] sparksco:
Nice and thanks for the info.

Edit: Just did a md5sum check on the files and they are all the same as before. Don't think changing the location of where they go in the script will really make much difference as to where they get installed on the device. The script can be modified but don't think it'll make a difference with the overall product builds of the ROMs.
[Nexus 7 Android Development] marty331:
Edit - I just learned to read! Sorry for wasting space.
[Nexus 7 Android Development] z1gackly:
I find your conversation a bit confusing, so I hope you'll excuse some noob questions.

Do I simply flash the latest nightly, run extract-files.sh and then make the changes fattire suggests, in order to get the JRO03R binaries into my build?

If so, what happens next time I repo sync? Do I need to make those changes again?

Would it be better to wait until the extract-files.sh script is updated and then repo sync and run it?

Thanks.
[Nexus 7 Android Development] sparksco:
You don't need to make changes after repo syncing. Try this patch out and let us know if it works or not:

http://r.cyanogenmod.com/#/c/23966/

cd device/asus/grouper && git fetch http://r.cyanogenmod.com/CyanogenMod/android_device_asus_grouper refs/changes/66/23966/1 && git cherry-pick FETCH_HEAD && cd .. && cd .. && cd ..;

You might also want to clear out the old vendor blobs first but I'm sure fattire would know since he tested it already. I haven't tested it yet.
[Nexus 7 Android Development] z1gackly:
Thanks, I'm going to have a go at this tonight, so I will let you know how it goes.
[Nexus 7 Android Development] marty331:
Anxiously awaiting update
[Nexus 7 Android Development] z1gackly:
Deleted all the "grouper" sub-directories under "android/system/vendor", cherry picked the update suggested by sparksco, ran extract-files.sh on a JRO03R CM10 nightly, and built. It included all the new binaries in the build, and everything appears to be working.

GPS fix seemed faster. No observable difference in touchscreen performance yet, but I have only just flashed it.

Unfortunately it has brought back a slight flicker when there is a white background. Asus had "fixed" this in my replacement by not allowing me to change brightness. Now the flicker is back and I still can't change brightness!

Debating whether to try reverting the nvidia driver. I'm also debating whether to ask for my money back on this thing instead of asking for a third replacement, but that's another story.
[Nexus 7 Android Development] z1gackly:
Another question relating to this. I made similar changes to yours above, but often when I make a change and rebuild, even though the changes I have made are built in, the date and time from this makefile do not advance, so for instance today my builds have been coming out reflecting 3:30 am on the 27th which is when my last build after a make clean completed. What do I have to do to get this to change each time I build?
[Nexus 7 Android Development] AndDiSa:
Out of my head: you need to remove

out/target/product/grouper/system/build.prop
[Nexus 7 Android Development] fattire:
setup-makefiles.sh has been updated...

BTW, I +2ed changes from Robert Burns modifying the setup-makefiles.sh file to extract the binaries to their new locations. It in effect, pulls the files to the right vendor/* directories as if they had been installed directly from google's scripts.

If you use it to back up blob files to vendor, and have used setup-makefiles.sh previously, just delete the vendor stuff first and do a fresh extract (provided you have the new binaries, though it should work even with the old ones but don't quote me on that.)...

Cheers!
[Nexus 7 Android Development] marty331:
Noob alert:

Where do you do the extract from, I'm unclear on this. I'm on CM10 that I compiled, so do I do the extract from my Nexus 7 or something else?
[Nexus 7 Android Development] fattire:
So you have an option--

if you've got a version of CM10 (or another firmware) on your nexus that already has the new binary (or eventually when Google releases new stock versions, if you're running that), you can plug your nexus in, and then run the extract-files.sh script and the binary blobs will be pulled and backed up to your vendor/tree. This more or less accomplishes the same thing as if you downloaded the binary files manually from Google, and ran the extraction scripts yourself to put them in the vendor directory.

If your vendor directory already has old binaries, you should probably delete those and download/install from google (to get the new binaries) or if you're using a pre-compiled firmware on your device

that already includes the new binaries

, you can use extract-files.sh to pull/backup to the vendor directory.

Make sense?
[Nexus 7 Android Development] marty331:
Yes it does! Thank you for the answer. I am pulling the updates now.
[Nexus 7 Android Development] joedoe:
Could you please reload the Google doc file or attach it to this thread as it's broken at the link you're providing.

---------- Post added at 02:16 PM ---------- Previous post was at 01:27 PM ----------

Well, it turned out that only Firefox doesn't want to read this file. Everything is cool now.
[Nexus 7 Android Development] z1gackly:
Trying to get my head around using git and github. I've been working locally up to now, doing repo syncs in master and working in development branches, but I wanted to share my source so I thought I would make a github account.

To get my changes onto github, I made a working branch from master, added some local branches in frameworks/base and vendor/cm, forked the two repositories on github, cherry-picked my changes to frameworks/base and vendor/cm into the working branch, committed them in the new local branches and then pushed those commits into my forked repositories. So far so good.

Then I went back into my main master branch and my local master branches and did a repo sync to see if there are any new changes in the CyanogenMod source tree and got the following errors:

zigackly@zigackly-ubuntu:~/android/system$ repo sync
Fetching projects: 100% (318/318), done.

frameworks/base/: leaving master; does not track upstream
vendor/cm/: leaving master; does not track upstream

What have I done wrong and how do I fix it? I am finding the intricacies of using repo, git and github on the same source tree to be a royal pain in the backside to be honest, and the documentation is unhelpful. That's before I even start on using gerrit to commit changes to CM, which seems to require yet another method of working on top of that mess.

Fattire's guide is brilliant for getting to the first stage of building ROMs from a CM base, but after that point there doesn't seem to be a lot of help out there for how to work on customising things and sharing with the community.

I find it a bit mad that someone like me who has been developing software professionally in a commercial environment for twenty years is finding this difficult to work out. Maybe I'm too used to having nice enterprise scale change control tools with easy to use GUIs ;)
[Nexus 7 Android Development] Nark.GA60:
I was going to post a very similar thing... :D
[Nexus 7 Android Development] z1gackly:
Never mind, I think I'm getting the hang of this now. I should hopefully be writing the answer to my own question in this thread later today, if all goes well.
[Nexus 7 Android Development] z1gackly:
Ok, so here is how I am now controlling repo and git along with my github account.

First, I completely restarted my repo and re-synced.

Then to make a project in frameworks/base:

repo start jellybean frameworks/base
cd frameworks/base
git remote add upstream [url]https://github.com/zigackly/android_frameworks_base.git[/url]

Then I did some work and made some commits, and pushed them to my github like so:

git push upstream jellybean

Today I decided I wanted to merge whatever is new in the cyanogenmod repositories with my stuff, so I did this:

cd frameworks/base
git remote add cyanogenmod [url]https://github.com/CyanogenMod/android_frameworks_base.git[/url]
git fetch cyanogenmod -v
git fetch upstream -v
git merge upstream/cyanogenmod

Then I pushed it back to my github:

git push upstream jellybean

This all seems to be working as I would expect. However, if anyone more experienced thinks I am doing it wrong, please let me know :)