01-16-2013 11:07 PM
1,060 ... 1819202122 ...
tools
  1. tdm's Avatar
    tdm, thank you so much for joining the development team and fixing long-standing charging issue. I have merged your commit along with Virgin boot splash and I can confirm that it works. I am not even sure if this is an issue but booting from off state requires disconnecting the charger.

    Did I say thank you? Excellent work!
    My pleasure. I am glad to be able to have something to contribute after joining so late.
    01-10-2012 12:02 PM
  2. Whyzor's Avatar
    Man I wish some of you talented devs would join the Motorola Triumph group (the price is coming down to $240 on Amazon now . Well hopefully we'll re-unite on a future VM phone! (Optimus Black or better!)
    01-10-2012 12:40 PM
  3. anthonycr's Avatar
    Question to devs: I have some basic Java and c++ knowledge that I've learned over the last few months in school. Thats all... so does anyone think it would be too hard to learn how to build my own rom? So far all I've done with android is changing all the pngs in some of my framework, simple stuff. I read the first few pages of this thread and it looks complicated, but I'm willing to learn.
    01-10-2012 02:22 PM
  4. tdm's Avatar
    Question to devs: I have some basic Java and c++ knowledge that I've learned over the last few months in school. Thats all... so does anyone think it would be too hard to learn how to build my own rom? So far all I've done with android is changing all the pngs in some of my framework, simple stuff. I read the first few pages of this thread and it looks complicated, but I'm willing to learn.
    In my experience, the ability to be persistent and roll with the flow as several projects all move independently is much more important than any ability to code. Between network issues, multiple projects updating at different times, and simple build breakages, it can easily take half a dozen tries to get a ROM built. My experience was especially bad because I tried to init my repo and build my first ROM during the long kernel.org outage. Thankfully you won't need to go through that.

    Once you do get a successful build, the next most important ability is simply hacking skill. It doesn't take much raw developer skill to implement most of the changes that most folks like to do. It just takes an eye for following examples and learning how to figure out what went wrong when you break your build (and you will).

    That said, it's a very rewarding experience to see your first successful custom ROM boot up on your phone. It far outweighs the initial frustration you may find when your initial tries don't work out for whatever reason.

    Good luck and welcome in advance to the ROM building community!
    anthonycr and JerryScript like this.
    01-10-2012 02:49 PM
  5. JerryScript's Avatar
    I agree with what tdm stated. If you just want to build, it's not too difficult to get started. Pulling in changes and applying commits will seem challenging at first, but only because git and gerrit were written by/for those who use them, not for those who want to learn to use them. That being said, the documentation and functionality of the github web interface has come a long way.

    Since you do know a thing or two about programming, you'll be interested in the tools. Be sure you understand logcat and dmesg, and how to interpret the output of each. They will give you clues to finding whatever bugs you may come across. And if you take the time (and have a system capable of it), I would recommend Eclipse or Netbeans as an ide. They both offer in panel debugging, and will help you fix things before they are broken.
    01-10-2012 11:28 PM
  6. thekraven's Avatar
    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.
    01-12-2012 08:54 PM
  7. mrg666's Avatar
    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.
    01-12-2012 09:12 PM
  8. JerryScript's Avatar
    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):
    Code:
    # 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):
    Code:
        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.
    01-12-2012 11:59 PM
  9. tdm's Avatar
    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".
    JerryScript and mrg666 like this.
    01-13-2012 12:44 AM
  10. mustafu's Avatar
    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
    01-13-2012 09:17 AM
  11. tdm's Avatar
    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).
    mustafu likes this.
    01-13-2012 09:52 AM
  12. thekraven's Avatar
    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/inferiorhumanorga...oidProducts.mk

    To IHO's new names?
    01-13-2012 09:56 PM
  13. tdm's Avatar
    more detail please... Build error or boot error? What are you seeing?
    01-13-2012 10:42 PM
  14. asadullah's Avatar
    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
    01-14-2012 01:17 AM
  15. JerryScript's Avatar
    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
    01-14-2012 05:46 AM
  16. tdm's Avatar
    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?
    01-14-2012 11:41 AM
  17. thekraven's Avatar
    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
    Code:
    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
    01-14-2012 11:44 AM
  18. asadullah's Avatar
    Try changing the permissions of jdk-tools-jar.sh make sure it's executable and your the owner.
    thekraven likes this.
    01-14-2012 04:29 PM
  19. thekraven's Avatar
    Thank you, that fixed it.
    01-14-2012 09:25 PM
  20. JerryScript's Avatar
    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.
    tdm likes this.
    01-14-2012 09:56 PM
  21. Whyzor's Avatar
    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.
    01-15-2012 05:48 PM
  22. JerryScript's Avatar
    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:
    Code:
        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:
    Code:
        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 )
    01-17-2012 01:10 PM
  23. anthonycr's Avatar
    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?
    01-17-2012 04:23 PM
  24. JerryScript's Avatar
    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.
    01-17-2012 09:40 PM
  25. anthonycr's Avatar
    Oh oh I see, I was misinterpretating what the variables meant. My bad

    EDIT: Maybe add another if statement in there

    or maybe...
    Code:
    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?
    01-18-2012 06:54 AM
1,060 ... 1819202122 ...
LINK TO POST COPIED TO CLIPBOARD