[DEV] AOSP Dev for Zte Blade

[Guest lsde]

software renderer works though, using egl.cfg with only this line (it means 'use default renderer as hardware renderer for display 0):

0 1 android

sorry if i'm cpt. obvious :)

[Guest t0mm13b]

hmmm... blackscreen-ers....

A thought....

Wonder is it the blade's own libgralloc that is clashing...? From what I remember when compiling, it was lacking dependencies on the overlay..which was 'missing' from the ICS's source.

What if, that was eliminated from the build and use the ICS's own libgralloc?

Saw it somewhere on the xda thread about having the device's own libgralloc (htc n1 device iirc) being removed completely..?

Ideas/suggestions?

Edited November 24, 2011 by t0mm13b

[Guest t0mm13b]

software renderer works though, using egl.cfg with only this line (it means 'use default renderer as hardware renderer for display 0):

0 1 android

sorry if i'm cpt. obvious :)

no worries :) Am quite open to suggestions to get the screen working but what did you mean by 'software renderer works' if the screen is black? :confused:

[Guest sm4tik]

My PC is a super duper workhorse... NOT!!!! <_<

I built this on a Atom N270 1.6Ghz with 2Gb RAM, running Arch Linux 32bit. It took a long while, about 31 hours to be exact. I timed this for the benefit of others to judge if they can get the build to work on a superior specc'd machine. But hey, it does compile in 32bit environment... :D

You give me hope with my 3GHz 32bit Arch box.. though more RAM has been on my shopping list for the past year or so now :) Would love to continue with self builds on CM9. Btw, did you check the peak of RAM usage during the build? Good work, And you also KonstaT!

[Guest lsde]

no worries :) Am quite open to suggestions to get the screen working but what did you mean by 'software renderer works' if the screen is black? :confused:

with software renderer, screen works (not using ardeno200 gpu)

imho the priority is to get touchscreen working atm

[Guest tilal6991]

hmmm... blackscreen-ers....

A thought....

Wonder is it the blade's own libgralloc that is clashing...? From what I remember when compiling, it was lacking dependencies on the overlay..which was 'missing' from the ICS's source.

What if, that was eliminated from the build and use the ICS's own libgralloc?

Saw it somewhere on the xda thread about having the device's own libgralloc (htc n1 device iirc) being removed completely..?

Ideas/suggestions?

You need to delete all the adreno files in /system/lib/egl

[Guest lsde]

In fact, the touchscreen driver works but the data is not interpreted by android framework correctly

try to 'cat /dev/input/event0' and touch the screen, you'll see touchscreen driver data on the console.

[Guest t0mm13b]

with software renderer, screen works (not using ardeno200 gpu)

imho the priority is to get touchscreen working atm

Yes! I can confirm the screen is there! THANK YOU! xD :) +1 from me! :)

(OOOOhhhh its lookin a beauty on the Blade....)

(Yes the error the process com.android.phone has stopped - think I can fix that one up!)

Now the kernel bit to tackle - not 31hours thank f..k!!! :D :lol:

[Guest t0mm13b]

In fact, the touchscreen driver works but the data is not interpreted by android framework correctly

try to 'cat /dev/input/event0' and touch the screen, you'll see touchscreen driver data on the console.

I'll admit it does sound a bit convoluted in the sense that the ICS framework requires a much tighter coupling with the kernel subsystem in relation to touch events, ie HACKING the driver (which sounds plain daft workaround). Why did Google change it (It worked in Gingerbread regardless of input driver used).. Examining where the input events gets dispatched - found here in frameworks/base/services/input/InputManager.cpp and other auxiliary supporting files...

Yes, I am familiar with the the /dev/input/event0 as that was used in the ClockWorkMod GUI in which Phoenix_Silver and myself worked on a while back :)

Might it not be easier to modify the framework and fix that up to make it look like what was in Gingerbread, in relation to responding to touch events?

Edit:

It seems by komparing with ICS's frameworks/base/services/ui/ and GB's frameworks/base/libs/ui might do the trick....

Edited November 24, 2011 by t0mm13b

[Guest t0mm13b]

Okie, this is what I would think be a better approach somewhat, modify the framework's input event dispatcher, unless, it is insisted that modding the input driver at the kernel level is a workaround solution...

Two places to check,

1. GB's own frameworks/base/libs/ui/Input* with ICS's frameworks/base/libs/ui/Input*
   
2. GB's own frameworks/base/libs/ui/Key* with ICS's frameworks/base/libs/ui/Key*
   

The main input manager for dispatching events from the touchscreen is found in frameworks/base/services/input, that's under ICS.

As for GB, that is found here, in frameworks/base/libs/ui. It looks all that has been moved into a separate directory aptly named input in ICS.... just documenting this here...

Another angle of this I can think as well:

This was taken from frameworks/base/libs/ui/Input.cpp

namespace android {


static const char* CONFIGURATION_FILE_DIR[] = {

        "idc/",

        "keylayout/",

        "keychars/",

};


static const char* CONFIGURATION_FILE_EXTENSION[] = {

        ".idc",

        ".kl",

        ".kcm",

};

Can these be easily modded to reflect the hardware keys to match up? Am yakking here... and throwing ideas out there - principally, need minimum modification without having to change the kernel's input subsystem whatsoever... in fact, IMHO, that should be left untouched and pure...xD

Edited November 24, 2011 by t0mm13b

[Guest furrabbit.nh]

Theres a few threads over @ xda about getting the touch working on various phones.

Here and Here

Dont know if it will be of any help.

@t0mm13b i have to agree even without touch ics looks sweet on blade. XD

Edited November 24, 2011 by furrabbit.nh

[Guest tilal6991]

The way to get touch working is quite easy - just get rid of all the

input_mt_sync(ts->input_dev);

In the kernel driver file.

And add this to /system/usr/idc/"TOUCHSCREEN NAME HERE".idc

# Basic Parameters

touch.deviceType = touchScreen

touch.orientationAware = 1

# Touch Size

touch.touchSize.calibration = pressure

# Tool Size

# Driver reports tool size as an area measurement.

#

# Based on empirical measurements, we estimate the size of the tool

# using size = sqrt(22 * rawToolArea + 0) * 9.2 + 0.

touch.toolSize.calibration = area

touch.toolSize.areaScale = 22

touch.toolSize.areaBias = 0

touch.toolSize.linearScale = 9.2

touch.toolSize.linearBias = 0

touch.toolSize.isSummed = 0

# Pressure

# Driver reports signal strength as pressure.

#

# A normal thumb touch typically registers about 100 signal strength

# units although we don't expect these values to be accurate.

touch.pressure.calibration = amplitude

touch.pressure.source = default

touch.pressure.scale = 0.01

# Size

touch.size.calibration = normalized

# Orientation

touch.orientation.calibration = none

The touch screen name can be found using your evertest progam tomm13b

[Guest lsde]

Okie, this is what I would think be a better approach somewhat, modify the framework's input event dispatcher, unless, it is insisted that modding the input driver at the kernel level is a workaround solution...

Two places to check,

1. GB's own frameworks/base/libs/ui/Input* with ICS's frameworks/base/libs/ui/Input*
2. GB's own frameworks/base/libs/ui/Key* with ICS's frameworks/base/libs/ui/Key*

The main input manager for dispatching events from the touchscreen is found in frameworks/base/services/input, that's under ICS.

As for GB, that is found here, in frameworks/base/libs/ui. It looks all that has been moved into a separate directory aptly named input in ICS.... just documenting this here...

Another angle of this I can think as well:

This was taken from frameworks/base/libs/ui/Input.cpp

namespace android {


static const char* CONFIGURATION_FILE_DIR[] = {

        "idc/",

        "keylayout/",

        "keychars/",

};


static const char* CONFIGURATION_FILE_EXTENSION[] = {

        ".idc",

        ".kl",

        ".kcm",

};

Can these be easily modded to reflect the hardware keys to match up? Am yakking here... and throwing ideas out there - principally, need minimum modification without having to change the kernel's input subsystem whatsoever... in fact, IMHO, that should be left untouched and pure...xD

hey, looks like a good start.

how about setting a public github repo with all blade modifications in one place to make development effort easier? i'd certainly help out, but not feeling like starting just another build version:)

[Guest tilal6991]

Just wondering how you guys managed to fix the phone force close error?

[Guest t0mm13b]

Just wondering how you guys managed to fix the phone force close error?

Could be the telephony layer within the framework and the ril... have you tried replacing the libril from GB?

[Guest tilal6991]

Could be the telephony layer within the framework and the ril... have you tried replacing the libril from GB?

Nope. Will try. That worked for you?

[Guest t0mm13b]

Nope. Will try. That worked for you?

No, that did not work... xD

any ideas? Is it actually reading the apns-conf.xml?

[Guest t0mm13b]

Looking closer on this, this was the result and reason why Phone apk was blowing up... somewhat...

E/AndroidRuntime(  251): java.lang.RuntimeException: Unable to create application com.android.phone.PhoneApp: java.lang.ArrayIndexOutOfBoundsException: length=4; index=4p.ActivityThread.handleBindApplication(ActivityThread.java:3928)

E/AndroidRuntime(  251):        at android.app.ActivityThread.access$1300(ActivityThread.java:122)

E/AndroidRuntime(  251):        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1184)

E/AndroidRuntime(  251):        at android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime(  251):        at android.os.Looper.loop(Looper.java:137)

E/AndroidRuntime(  251):        at android.app.ActivityThread.main(ActivityThread.java:4340)

E/AndroidRuntime(  251): Caused by: java.lang.ArrayIndexOutOfBoundsException: length=4; index=4

E/AndroidRuntime(  251):        at android.net.NetworkConfig.<init>(NetworkConfig.java:70)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GsmDataConnectionTracker.initApnContextsAndDataConnection(GsmDataConnectionTracker.java:257)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GsmDataConnectionTracker.<init>(GsmDataConnectionTracker.java:174)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GSMPhone.<init>(GSMPhone.java:143)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GSMPhone.<init>(GSMPhone.java:126)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GsmDataConnectionTracker.<init>(GsmDataConnectionTracker.java:174)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GSMPhone.<init>(GSMPhone.java:143)

E/AndroidRuntime(  251):        at com.android.internal.telephony.gsm.GSMPhone.<init>(GSMPhone.java:126)

E/AndroidRuntime(  251):        at com.android.internal.telephony.PhoneFactory.makeDefaultPhone(PhoneFactory.java:141)

E/AndroidRuntime(  251):        at com.android.internal.telephony.PhoneFactory.makeDefaultPhones(PhoneFactory.java:55)

E/AndroidRuntime(  251):        at com.android.phone.PhoneApp.onCreate(PhoneApp.java:428)

E/AndroidRuntime(  251):        at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:969)

E/AndroidRuntime(  251):        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3925)

Looks like the telephony somewhere when reading apns blew up, that's my hunch based on it... Edit: On further investigation, digging into frameworks/base/telephony/java/com/android/internal/telephony/gsm/GsmDataConnectionTracker.java

 protected void initApnContextsAndDataConnection() {

        boolean defaultEnabled = SystemProperties.getBoolean(DEFALUT_DATA_ON_BOOT_PROP, true);

        // Load device network attributes from resources

        String[] networkConfigStrings = mPhone.getContext().getResources().getStringArray(

                com.android.internal.R.array.networkAttributes);

for (String networkConfigString : networkConfigStrings) {

            NetworkConfig networkConfig = new NetworkConfig(networkConfigString);

            ApnContext apnContext = null;


            switch (networkConfig.type) {

            case ConnectivityManager.TYPE_MOBILE:

                apnContext = addApnContext(Phone.APN_TYPE_DEFAULT);

                apnContext.setEnabled(defaultEnabled);

                break;

            case ConnectivityManager.TYPE_MOBILE_MMS:

                apnContext = addApnContext(Phone.APN_TYPE_MMS);

                break;

            case ConnectivityManager.TYPE_MOBILE_SUPL:

                apnContext = addApnContext(Phone.APN_TYPE_SUPL);

                break;

            case ConnectivityManager.TYPE_MOBILE_DUN:

                apnContext = addApnContext(Phone.APN_TYPE_DUN);

                break;

            case ConnectivityManager.TYPE_MOBILE_HIPRI:

                apnContext = addApnContext(Phone.APN_TYPE_HIPRI);

                ApnContext defaultContext = mApnContexts.get(Phone.APN_TYPE_DEFAULT);

                if (defaultContext != null) {

                    applyNewState(apnContext, apnContext.isEnabled(),

                            defaultContext.getDependencyMet());

Notice the mis-spelling DEFALUT_DATA_ON_BOOT_PROP :huh: that's actually in there, and points to a property 'net.def_data_on_boot'... something worth mentioning and to keep in mind... ;) This apparently proceeds further to extract the apn's That is called by this frameworks/base/core/java/android/net/NetworkConfig.java

 /**

     * input string from config.xml resource.  Uses the form:

     * [Connection name],[ConnectivityManager connection type],

     * [associated radio-type],[priority],[dependencyMet]

     */

    public NetworkConfig(String init) {

        String fragments[] = init.split(",");

        name = fragments[0].trim().toLowerCase();

        type = Integer.parseInt(fragments[1]);

        radio = Integer.parseInt(fragments[2]);

        priority = Integer.parseInt(fragments[3]);

        restoreTime = Integer.parseInt(fragments[4]);

        dependencyMet = Boolean.parseBoolean(fragments[5]);

    }

So we're getting on to something, it pulled in something, perhaps a file found in /etc that is length 4, comma delimited, over-stepped the boundary and blew up.

Question is - what the f..k does that contain? 'com.android.internal.R.array.networkAttributes'. Its an xml resource that may contain the name of the file or a string and where is it coming from, as fgrep failed to pick up on it! Any ideas?

Also, I did notice a lot of similar messages in initializing the APKs each time which is indicative of somewhat, I/O errors, with sqlite3 being part of the stacktrace, permissions problem somewhere that's preventing sqlite3 from re-creating databases somewhere? Or is it the partitions layout as result of TPT? i.e. possibly not enough space...hence the slowdown on boot as a result of attempting to recreate their own content provider databases?

Edited November 25, 2011 by t0mm13b

[Guest t0mm13b]

Touchscreen is responding, a BIG thank you to Tilal6991 for his input and help. :D

Modified kernel's drivers/input/synaptics_i2c_rmi.c and commented out the offending line!

but the bloody com.android.phone process keeps jamming....related to the previous posting...

Power management sucks donkey balls on this, very slow to respond to screen on...so don't panic and think something is wrong, its just runs like darn treacle!

Unzip the attached and...

sudo fastboot flash boot boot.img

Oh and rename synaptics-rmi-touchscreen.idc.txt to synaptics-rmi-touchscreen.idc, push it out to /system/usr/idc and reboot.

adb remount

adb push synaptics-rmi-touchscreen.idc /system/usr/idc/synaptics-rmi-touchscreen.idc

adb remount 

fixed_touchscreen.zip

synaptics-rmi-touchscreen.idc.txt

Edited November 25, 2011 by t0mm13b

[Guest furrabbit.nh]

Touchscreen is responding, a BIG thank you to Tilal6991 for his input and help. :D

Modified kernel's drivers/input/synaptics_i2c_rmi.c and commented out the offending line!

but the bloody com.android.phone process keeps jamming....related to the previous posting...

Power management sucks donkey balls on this, very slow to respond to screen on...so don't panic and think something is wrong, its just runs like darn treacle!

Unzip the attached and...

sudo fastboot flash boot boot.img

Oh and rename synaptics-rmi-touchscreen.idc.txt to synaptics-rmi-touchscreen.idc, push it out to /system/usr/idc and reboot.

adb remount

adb push synaptics-rmi-touchscreen.idc /system/usr/idc/synaptics-rmi-touchscreen.idc

adb remount 

BRILLL Just tried and can confirm... XD

Thanks

Edited November 25, 2011 by furrabbit.nh

[Guest t0mm13b]

@furrabbit.nh: Great! :)

Now, the phone - apns file changed in ICS? Can anyone confirm in order to get that very nice "Unfortunately, the process com.android.phone has stopped", would anyone know of someone who would have the Galaxy Nexus, and try rip out the apns configuration and replace the CM7 version...?

[Guest furrabbit.nh]

@furrabbit.nh: Great! :)

Now, the phone - apns file changed in ICS? Can anyone confirm in order to get that very nice "Unfortunately, the process com.android.phone has stopped", would anyone know of someone who would have the Galaxy Nexus, and try rip out the apns configuration and replace the CM7 version...?

@t0mm13b

ive just tried the new boot.img with the hero port from one of the other threads, touchscreen is also working on there but on the hero port i dont get the process com.android.phone error i can run full setup browse app draw etcetc.

Edited November 25, 2011 by furrabbit.nh

[Guest t0mm13b]

@t0mm13b

ive just tried the new boot.img with the hero port from one of the other threads, touchscreen is also working on there but on the hero port i dont get the process com.android.phone error i can run full setup browse app draw etcetc.

:huh:

How? can you post the ramdisk from that hero port to see whats different as the ramdisk used is from cm7? :)

[Guest furrabbit.nh]

:huh:

How? can you post the ramdisk from that hero port to see whats different as the ramdisk used is from cm7? :)

Im using the new boot.img, not the one that came with hero port. So ramdisk is in your new boot.img if im not mistaken. Sorry im still learning. I can post you the system.img or update.zip with new boot image you supplied. (I got fast upload)

Some sreens attatched

[Guest hedgepigdaniel]

hey, looks like a good start.

how about setting a public github repo with all blade modifications in one place to make development effort easier? i'd certainly help out, but not feeling like starting just another build version:)

YES!!!!

Then I can try stuff out as well as setting up a build environment.