23/Sep: Kernel Source

[Guest oh!dougal]

Thanks :) How do I disable this memory bus overclocking at stock speed?

Take a look at http://android.modaco.com/index.php?s=&amp...t&p=1524134

(And post 2 has some other options).

Edited December 20, 2010 by oh!dougal

[Guest Sven Killig]

Take a look at http://android.modaco.com/index.php?s=&amp...t&p=1524134

(And post 2 has some other options).

I can't discover what source code files I need to modify/exclude to build a kernel without memory bus overclocking at stock speed.

Edited December 20, 2010 by Sven Killig

[Guest oh!dougal]

I can't discover what source code files I need to modify/exclude to build a kernel without memory bus overclocking at stock speed.

For source, try sending kk a PM. I don't think he's yet published the stuff that he's only released in the last couple of days.

[Guest fonix232]

Okay, I'm looking to contact ZTE in case of the RIL source/framework mods. What email address should I send my mail?

[Guest rjm2k]

Okay, I'm looking to contact ZTE in case of the RIL source/framework mods. What email address should I send my mail?

Pm me youremail and i will add you to my zte mail list but doubt you will get anywhere

[Guest rjm2k]

Okay, I'm looking to contact ZTE in case of the RIL source/framework mods. What email address should I send my mail?

I had a look at reverse engineering the frameworks.jar and found at least one tool which does a good job of producing readable java, I wonder if we get hold of a stock Eclaire framework and do the same if there will be few enough differences to make it possible to identify and re-produce them in another version of android? The tool I used is seg faulting at the moment when attempting to save the source though. Probably good enough for a manual compare though, anyone know where I can find a stock aosp framework.jar for frf91 which is not odexed?

I suspect the lack of network unlock maybe caused by the engineering rom putting the radio into test mode, or maybe it's deliberate so that they could demo the phone with any sim in it.

update - attached telephonymanager from zte and another frf91 rom, you can compare, for example getsimstate has lots more options in the zte version which maybe why we can use it unlocked with different sims in, it just carrys on. would be interesting to do a full comparison between stock frf91, zte blade engineering and zte blade release. will try get some time to see why the decompiler is crashing part way through generating files.

Original

public int getSimState()

  {

	String str = SystemProperties.get("gsm.sim.state");

	int i;

	if ("ABSENT".equals(str))

	  i = 1;

	while (true)

	{

	  return i;

	  if ("PIN_REQUIRED".equals(str))

	  {

		i = 2;

		continue;

	  }

	  if ("PUK_REQUIRED".equals(str))

	  {

		i = 3;

		continue;

	  }

	  if ("NETWORK_LOCKED".equals(str))

	  {

		i = 4;

		continue;

	  }

	  if ("READY".equals(str))

	  {

		i = 5;

		continue;

	  }

	  i = 0;

	}

  }

ZTE

public int getSimState()

  {

	String str = SystemProperties.get("gsm.sim.state");

	int i;

	if ("ABSENT".equals(str))

	  i = 1;

	while (true)

	{

	  return i;

	  if ("PIN_REQUIRED".equals(str))

	  {

		i = 2;

		continue;

	  }

	  if ("PUK_REQUIRED".equals(str))

	  {

		i = 3;

		continue;

	  }

	  if ("NETWORK_LOCKED".equals(str))

	  {

		i = 4;

		continue;

	  }

	  if ("READY".equals(str))

	  {

		i = 5;

		continue;

	  }

	  if ("CARD_IO_ERROR".equals(str))

	  {

		i = 6;

		continue;

	  }

	  if ("SIM_NETWORK_SUBSET_LOCKED".equals(str))

	  {

		i = 7;

		continue;

	  }

	  if ("SIM_CORPORATE_LOCKED".equals(str))

	  {

		i = 8;

		continue;

	  }

	  if ("SIM_SERVICE_PROVIDER_LOCKED".equals(str))

	  {

		i = 9;

		continue;

	  }

	  if ("SIM_SIM_LOCKED".equals(str))

	  {

		i = 10;

		continue;

	  }

	  if ("RUIM_NETWORK1_LOCKED".equals(str))

	  {

		i = 11;

		continue;

	  }

	  if ("RUIM_NETWORK2_LOCKED".equals(str))

	  {

		i = 12;

		continue;

	  }

	  if ("RUIM_HRPD_LOCKED".equals(str))

	  {

		i = 13;

		continue;

	  }

	  if ("RUIM_CORPORATE_LOCKED".equals(str))

	  {

		i = 14;

		continue;

	  }

	  if ("RUIM_SERVICE_PROVIDER_LOCKED".equals(str))

	  {

		i = 15;

		continue;

	  }

	  if ("RUIM_RUIM_LOCKED".equals(str))

	  {

		i = 16;

		continue;

	  }

	  i = 0;

	}

  }

though my java is a little rusty so I can't see why the return i; wouldn't immediatly exit before the if block unless it's in the wrong place due to a bug in the decompiler?

asoptelephonymanager.txt

ztetelephonymanager.txt

Edited December 23, 2010 by rjm2k

[Guest Arr Too]

though my java is a little rusty so I can't see why the return i; wouldn't immediatly exit before the if block unless it's in the wrong place due to a bug in the decompiler?

Those tools don't quite understand the Dalvik code or the optimisations the compiler has done (or can't represent them properly). Therefore, don't expect to be able to compile it and get the same result! The only real way to do that is to put up with the Smali version, although perhaps referring to this dodgy Java version to get the general gist (with much easier to read code) -- just don't rely on the control flow being correct!

The SIM lock is also handled in the Phone.apk, where ZTE have added a special case for a specific device ID to ignore the lock (on the stock Orange one). I tried (once) to adjust the code (via Smali), but it didn't work and I gave up (since it's hardly a critical task, now we have free calculators) -- I suspect this is because it was compiled against the private OEM Android stuff, but I'm not sure...

[Guest rjm2k]

Those tools don't quite understand the Dalvik code or the optimisations the compiler has done (or can't represent them properly). Therefore, don't expect to be able to compile it and get the same result! The only real way to do that is to put up with the Smali version, although perhaps referring to this dodgy Java version to get the general gist (with much easier to read code) -- just don't rely on the control flow being correct!

The SIM lock is also handled in the Phone.apk, where ZTE have added a special case for a specific device ID to ignore the lock (on the stock Orange one). I tried (once) to adjust the code (via Smali), but it didn't work and I gave up (since it's hardly a critical task, now we have free calculators) -- I suspect this is because it was compiled against the private OEM Android stuff, but I'm not sure...

Yeah I realised that the flow was probably being incorrectly identified but hopefully it's still useful for comparison between say stock and zte because it will make the same mistakes in both instances so wont show a difference where there isn't one. Will have to see how TomG gets on with RIL to see if any of this is necessary.

[Guest TheDOC1]

Any news on the 2.2 kernel sources? Why are there compiled versions in the wild and ZTE doesn't provide the source code?

[Guest oh!dougal]

Any news on the 2.2 kernel sources? Why are there compiled versions in the wild and ZTE doesn't provide the source code?

I'm not sure that its actually in the hands of ordinary retail customers yet!

Does anyone know if its actually 'out' yet?

[Guest fonix232]

I'm not sure that its actually in the hands of ordinary retail customers yet!

Does anyone know if its actually 'out' yet?

The 2.2 sources are awaited between 1st, January and 7th January!

[Guest dadashi]

The 2.2 sources are awaited between 1st, January and 7th January!

does that mean we can expext decent froyo roms in coming January... :unsure:

[Guest That-Guy]

does that mean we can expext decent froyo roms in coming January... :unsure:

I think so but I guess time will tell B)

[Guest oh!dougal]

In the "next wednesday, perfect rom" thread

ZTE did release the 2.1 kernel source which was found to be broken and they uploaded a newer version which fixes most of the issues. So they've done their part with regards to Eclair. They promised the Froyo source soon. Lets wait and see if they deliver.

But in the Jellyfish thread

...

EDIT: The hangup on removing charging seems to be related to the custom kernel. With the original kernel it doesn't happen. I think this was introduced in the latest source from ZTE and I think I know what to change to fix it.

The question this raised in my mind was whether anyone had done a diff between the two versions of 2.1 source that ZTE have released?

Sure they changed a few things so it would compile, but did anyone look to see what else they might have changed? (Or at least in what areas changes had been made?)

[Guest Dashes]

Froyo

[Guest jurrasstoil]

Froyo

O M F G!

it's f***ing christmas - again!

Edited January 6, 2011 by jurrasstoil

[Guest rjm2k]

Froyo

Yes, just chased them up and it appeared straight away!

Looks like they have fixed the links in the V9 kernel post too, maybe they have updated the .29 kernel source too.

Edited January 6, 2011 by rjm2k

[Guest Frankish]

SICK.

[Guest Frankish]

Now i wonder if those screen freezes are kernel related? All i want is Froyo with overclock and no screen freeze :unsure:

Ooh time for CyanogenMod ports and MIUI ports too? B)

Edited January 6, 2011 by Frankish

[Guest rayraven]

^No gingerbread? :unsure:

Edited January 6, 2011 by rayraven

[Guest Sebastian404]

All i want is Froyo with overclock and no screen freeze :unsure:

Buy a Nexus S

[Guest Sebastian404]

^No gingerbread? :unsure:

Narr, Gingerbread is boring... 2.4 is where it is!

[Guest Sebastian404]

And there ZTE's site falls apart as hundreds of people download it for no real reason...

I do think its great they still included links to the old version of the kernel in the HTML source.... very professional bunch :unsure:

[Guest Frankish]

Buy a Nexus S

Err no ta. If i had the money to buy a high end Android phone it wouldn't be on a piece of plastic. HTC have far better build quality than Samsung. Plus i love my Blade :unsure:

[Guest lordofangels]

Narr, Gingerbread is boring... 2.4 is where it is!

Is that the new Motorola XOOM tablet one?