Building your own ROM

[thekraven]

Only minor thing about the offline charging. What needs to be done so that we get a full reboot when plugged in? A reboot from CM7 power menu goes straight to the charging menu when plugged into a/c or usb. Also from recovery.

Just seeing what the behavior is with the rest of your builds. Unless I missed a step somewhere.

 

[mrg666]

Only minor thing about the offline charging. What needs to be done so that we get a full reboot when plugged in? A reboot from CM7 power menu goes straight to the charging menu when plugged into a/c or usb. Also from recovery.

Just seeing what the behavior is with the rest of your builds. Unless I missed a step somewhere.

Same happened to me when I tried to reboot from offline charging. You need to keep pressing the power button until you see the silver LG logo. Then, the phone boots into IHO.

 

[JerryScript]

Following along tdm's great work at getting the chargerlogo and first boot animation working again, I'm trying to do the same with the bootsound. I haven't been successful yet, here's what I've tried so far:

device/lge/thunderc/files:
-- Add the PowerOn.mp3
-- Modify init.thunderc.rc to include the following from the stock OV's init.rc (positioning is probably the issue here, I have it at the top, perhaps it needs to be after the bootlogo has begun):

# This plays the /system/sounds/poweron/PowerOn.mp3 at boot.
service bootsound /system/bin/playmp3
    user root
    group root
    oneshot

-- Mofified device_thunderc.mk to include the following (I've tried both sbin and bin for the playmp3 binary):

    device/lge/thunderc/files/playmp3:system/bin/playmp3 \
    device/lge/thunderc/files/PowerOn.mp3:system/sounds/poweron/PowerOn.mp3 \

Note- there is also a handset-keypress binary in the stock OV, wondering if that could help us with the headset buttons and mic issues. I've added it to my build, but haven't gotten around to attempting to test yet, waiting on bootsound builds. Anyone know a shortcut to just building the boot.img? I hate doing a clean make, takes too long.

 

[tdm]

Anyone know a shortcut to just building the boot.img? I hate doing a clean make, takes too long.

Try "make out/target/product/thunderc/boot.img".

 

[mustafu]

I have a Pentium4 HT 3.0ghz and 2GB ram. Would it be a decent rig to build on? Is having the 2 virtual cores helpful in building?

Sent from my LG-VM670 using Tapatalk

 

[tdm]

I have a Pentium4 HT 3.0ghz and 2GB ram. Would it be a decent rig to build on? Is having the 2 virtual cores helpful in building?

Sent from my LG-VM670 using Tapatalk

It will certainly be capable of building. Decent is a relative term though. It's similar to my box, and I'm seriously investigating upgrading.

Here are some suggestions to get the most out of your box without upgrading:

* Run Linux with no GUI if it's a server or a minimal GUI if it's a desktop (say, fluxbox and rxvt).
* Install and use ccache (apt-get install ccache, export USE_CCACHE=1).
* Do not use the bacon target, use otapackage. bacon does a bunch of heavy operations to squeeze the absolute most out of the image and it takes a long time.
* Use "mm" (make module) when you just want to build a single module (say, after changes).

 

[thekraven]

I resynced and not getting a bootable build now.

I noticed the rearranging and renaming

Do we need to make changes here too?
https://github.com/inferiorhumanorg.../blob/gingerbread/products/AndroidProducts.mk

To IHO's new names?

 

[tdm]

more detail please... Build error or boot error? What are you seeing?

 

[asadullah]

more detail please... Build error or boot error? What are you seeing?

he's probably missing png files for the holo method in phone.apk they should be in framework-res but they aren't there at all

 

[JerryScript]

he's probably missing png files for the holo method in phone.apk they should be in framework-res but they aren't there at all

You must have had a problem pulling them in. I got them when I synced with CM, and so did IHO. The names are:

frameworks/base/core/res/res/drawable-mdpi/
jog_ring_holo_ring_normal.png
jog_ring_holo_ring_pressed.png
jog_ring_holo_ring_secback_normal.png

 

[tdm]

I got them when I synced with CM, and so did IHO.

I'm wondering what works best for syncing across multiple repos and forks when building the android system.

I realize that having a gazillion repos has its advantages, but it breaks code change atomicity which is one of the main reasons for using source control. In turn, this creates sync issues for folks that have project forks (and sub-forks). The holo lockscreen change is a perfect illustration: it was split across multiple repos and I had forked one of them. So, when I did a top level sync, my build broke. I realized pretty quickly that I needed to pull and merge all my forked repos manually. With the number of repos involved, this could get really cumbersome. Are there tools/scripts to do this automagically?

 

[thekraven]

A couple things happened after I resynced. The first would get me a full build, but not a bootable one. Only the boot.img was not getting past the white lg screen. This was with the rearrangement with iho device thunderc. It worked before with tdm's commits.


It might be sprint specific, as I saw blarf mention he used different bootlogo file.

The thunder_keypad.kl is device specific and not a common.
Now another resync and I'm getting a lunch menu error. Permission errors

You're building on Linux

Lunch menu... pick a combo:
     1. full-eng
     2. full_x86-eng
     3. simulator
     4. cyanogen_thunderc_VM670-eng
     5. cyanogen_thunderc_LS670-eng
     6. cyanogen_thunderc_MS690-eng
     7. cyanogen_thunderc_US670-eng
     8. cyanogen_thunderc_VS660-eng

Which would you like? [full-eng] 5
/bin/bash: build/core/find-jdk-tools-jar.sh: Permission denied

/bin/bash: build/core/find-jdk-tools-jar.sh: Permission denied
/bin/bash: build/core/find-jdk-tools-jar.sh: Permission denied
/bin/bash: build/core/find-jdk-tools-jar.sh: Permission denied
/bin/bash: build/core/find-jdk-tools-jar.sh: Permission denied
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=2.3.7
TARGET_PRODUCT=cyanogen_thunderc_LS670
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv6-vfp
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=GINGERBREAD
============================================
/bin/bash: build/core/find-jdk-tools-jar.sh: Permission denied

 

[asadullah]

Try changing the permissions of jdk-tools-jar.sh make sure it's executable and your the owner.

 

[thekraven]

Thank you, that fixed it.

 

[JerryScript]

I stopped using repo sync for most things about a month ago. It's great if you are using a single repository, but if you are pulling in changes from multiple repos, I find it much easier to fetch/merge/pull each one. There are only 5 projects that you have to worry about most of the time:
1- frameworks/base
2- CMParts
3- Settings
4- build
5- device/lge/thunderc
Of course you do have to pull from other project repos on occasion, but it's really not that much of a pita. Most important thing is to look through the project repo's history first. If it looks sketchy, use fetch/merge. If it seems clean, use pull. Either way, topic branches can save you a lot of headaches!

While most people should still do an initial repo sync to setup the initial build environment, you can git clone most projects as needed.

 

[Whyzor]

To add to what Jerry said. If the person who maintains the repo (blarf) does merges regularly, a simple repo sync would work. I was in the same situation building CM7 for the MT and the guy who maintains my initial sync has been on break. Big CM changes create dependencies across repos. So I had to manually pull and merge from CM directly.

Another way is to edit the .repo/manifest.xml file to point to CyanogenMod for future syncs, bypassing blarfs from now on since changes are more likely to come from CM than blarf's for CM7 on the OV.

 

[JerryScript]

I'm attempting to get hands-free support working so that people can use the mic and a hands-free adaptor instead of relying on the speaker phone. I'm having trouble nailing down where the check is for HEADSETS_WITH_MIC, but I'm pretty sure that is where the heart of the issue is. I made the following change last night as a test case, which leads me to this being the issue, but it was late, and I was tired. Got to go to work now, will be back on this tonite.

/frameworks/base/services/java/com/android/server/HeadsetObserver.java
Changed:

    private final void sendIntent(int headset, int headsetState, int prevHeadsetState, String headsetName) {
        if (headsetState != I2C_ROUTED && headsetState != I2C_CONNECTED) {
            if ((headsetState & headset) != (prevHeadsetState & headset)) {
                //  Pack up the values and broadcast them to everyone
                Intent intent = new Intent(Intent.ACTION_HEADSET_PLUG);
                intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
                int state = 0;
                int microphone = 0;

                if ((headset & HEADSETS_WITH_MIC) != 0) {
                    microphone = 1;
                }
                if ((headsetState & headset) != 0) {
                    state = 1;
                }
                intent.putExtra("state", state);
                intent.putExtra("name", headsetName);
                intent.putExtra("microphone", microphone);

                if (LOG) Slog.v(TAG, "Intent.ACTION_HEADSET_PLUG: state: "+state+" name: "+headsetName+" mic: "+microphone);
                // TODO: Should we require a permission?
                ActivityManagerNative.broadcastStickyIntent(intent, null);
            }
        } else {
            Intent intent = new Intent("com.teamwin");
            intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
            int state = 0;
            
            if (headsetState == I2C_ROUTED) {
                state = 1;
            }

            intent.putExtra("state", state);
            ActivityManagerNative.broadcastStickyIntent(intent, null);
        }
    }

To:

    private final void sendIntent(int headset, int headsetState, int prevHeadsetState, String headsetName) {
        if (headsetState != I2C_ROUTED && headsetState != I2C_CONNECTED) {
            if ((headsetState & headset) != (prevHeadsetState & headset)) {
                //  Pack up the values and broadcast them to everyone
                Intent intent = new Intent(Intent.ACTION_HEADSET_PLUG);
                intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
                int state = 0;
                int microphone = 1;

                if ((headset & HEADSETS_WITH_MIC) == 0) {
                    microphone = 0;
                }
                if ((headsetState & headset) != 0) {
                    state = 1;
                }
                intent.putExtra("state", state);
                intent.putExtra("name", headsetName);
                intent.putExtra("microphone", microphone);

                if (LOG) Slog.v(TAG, "Intent.ACTION_HEADSET_PLUG: state: "+state+" name: "+headsetName+" mic: "+microphone);
                // TODO: Should we require a permission?
                ActivityManagerNative.broadcastStickyIntent(intent, null);
            }
        } else {
            Intent intent = new Intent("com.teamwin");
            intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
            int state = 0;
            
            if (headsetState == I2C_ROUTED) {
                state = 1;
            }

            intent.putExtra("state", state);
            ActivityManagerNative.broadcastStickyIntent(intent, null);
        }
    }

This is the changed part:

int microphone = 0; // change to 1

if ((headset & HEADSETS_WITH_MIC) != 0) { // change to equals
microphone = 1; // change to 0

Testing with both mic and non-mic headsets still gave the same behavior and output in logcat as before the change. This leads me to believe the issue is furthur up in the test for whether the headset has a mic, since if a mic was detected, there should be different behavior with the reversal in logic. It was late, and I was too tired to search for it, and I'm not sure at this point if my thinking was even right (shouldn't work on this stuff so late )

 

[anthonycr]

I'm no expert, but with what Java I do know...

Shouldn't it be:

If ((headset & headset_with_Mic) == 0)
{Microphone=1}

Seems like to me that this would enable the mic even when a headset is plugged in... right? Or wrong?

 

[JerryScript]

I'm no expert, but with what Java I do know...

Shouldn't it be:

If ((headset & headset_with_Mic) == 0)
{Microphone=1}

Seems like to me that this would enable the mic even when a headset is plugged in... right? Or wrong?

But we are trying to get full functionality, so the difference between a mic+headset and a non-mic headset has to be accounted for.

 

[anthonycr]

Oh oh I see, I was misinterpretating what the variables meant. My bad

EDIT: Maybe add another if statement in there

or maybe...

if ((headset & HEADSET_WITH_MIC)!=0)
{microphone=0;}

Wouldn't that tell the phone that there is no microphone available if any headset is plugged in, and it would have to use the phone mic?