[Guide] demystifying build.prop [Valid entries] - Android Software/Hacking General [Developers Only]

Tired of see so many "tweaks" that do not work, I decided to dig deeper.
Scavenging the entire Android source, I checked entries which are actually valid.
Note 1: Ignored the build.prop entries created by buildinfo.sh (default entries)
Note 2: I'll update/upgrade the topic gradually.
I accept all help, suggestions, observations, comments and so on.
Entries that DO NOT exist in the source:
(Again: I scaveged all Android source code)
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-bytecode
debug.performance.tuning
video.accelerate.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
ersist.sys.shutdown.mode
ro.HOME_APP_ADJ
Notes:
dalvik.vm.verify-bytecode
Previous version of the runtime supported the boolean
dalvik.vm.verify-bytecode property, but that has been
superceded by dalvik.vm.dexopt-flags.
ro.kernel.checkjni
The correct entry is ro.kernel.android.checkjni
ro.HOME_APP_ADJ
The interaction with this is been removed.
From google:
This is a process holding the home application -- we want to try
avoiding killing it, even if it would normally be in the background,
because the user interacts with it so much.
All ro.media.enc* entries
A more elegant alternative would be to edit /system/etc/media_profiles.xml
Valid entries on CyanogenMod and AOSP:
dalvik.vm.checkjni and ro.kernel.android.checkjni
platform_frameworks_base/core/jni/AndroidRuntime.cpp (480:489/466:475)
Code:
property_get("dalvik.vm.checkjni", propBuf, "");
if (strcmp(propBuf, "true") == 0) {
checkJni = true;
} else if (strcmp(propBuf, "false") != 0) {
/* property is neither true nor false; fall back on kernel parameter */
property_get("ro.kernel.android.checkjni", propBuf, "");
if (propBuf[0] == '1') {
checkJni = true;
}
}
wifi.supplicant_scan_interval
android_external_wpa_supplicant/wpa_supplicant.c (2459:2460)
Code:
if (property_get("wifi.supplicant_scan_interval", scan_prop, "5") != 0) {
wpa_s->scan_interval = (int)strtol(scan_prop, &endp, 0);
service.adb.tcp.port
platform_system_core/adb/adb.c (1366:1372/1350:1356)
Code:
// If one of these properties is set, also listen on that port
// If one of the properties isn't set and we couldn't listen on usb,
// listen on the default port.
property_get("service.adb.tcp.port", value, "");
if (!value[0]) {
property_get("persist.adb.tcp.port", value, "");
}
ro.sf.lcd_density and qemu.sf.lcd_density
platform_frameworks_base/core/java/android/util/DisplayMetrics.java (286:294)
Code:
private static int getDeviceDensity() {
// qemu.sf.lcd_density can be used to override ro.sf.lcd_density
// when running in the emulator, allowing for dynamic configurations.
// The reason for this is that ro.sf.lcd_density is write-once and is
// set by the init process when it parses build.prop before anything else.
return SystemProperties.getInt("qemu.sf.lcd_density",
SystemProperties.getInt("ro.sf.lcd_density", DENSITY_DEFAULT));
}
}
debug.sf.nobootanimation
platform_frameworks_base/cmds/bootanimation/bootanimation_main.cpp (45:49)
Code:
char value[PROPERTY_VALUE_MAX];
property_get("debug.sf.nobootanimation", value, "0");
int noBootAnimation = atoi(value);
ALOGI_IF(noBootAnimation, "boot animation disabled");
persist.adb.notify
Cyanogen: android_frameworks_base/services/java/com/android/server/usb/UsbDeviceManager.java (747:753)
Code:
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))
|| Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ADB_NOTIFY, 1) == 0)
return;
AOSP: android_frameworks_base/services/java/com/android/server/usb/UsbDeviceManager.java (714:715)
Code:
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))) return;
net.rmnet0.dns* and net.dns*
This is ok for Wifi and 2G/3G conection
wifi.supplicant_scan_interval
android_external_wpa_supplicant/wpa_supplicant.c (2459:2460)
Code:
if (property_get("wifi.supplicant_scan_interval", scan_prop, "5") != 0) {
wpa_s->scan_interval = (int)strtol(scan_prop, &endp, 0);
Valid entries only on CyanogenMod:
persist.sys.purgeable_assets
android_frameworks_base/core/jni/android/graphics/BitmapFactory.cpp (632:634)
Code:
char value[PROPERTY_VALUE_MAX];
property_get("persist.sys.purgeable_assets", value, "0");
mPurgeableAssets = atoi(value) == 1;
persist.sys.use_dithering
android_packages_app_CMParts/src/com/cyanogenmod/cmparts/activities/PerformancesettingsActivity.java (102)
Code:
String useDithering = SystemProperties.get(USE_DITHERING_PERSIST_PROP, USE_DITHERING_DEFAULT);
persist.sys.jit-mode (Only "fast" and "portable" modes)
android_packages_app_CMParts/src/com/cyanogenmod/cmparts/activities/PerformancesettingsActivity.java (96:99)
Code:
mJitPref = (CheckBoxPreference) prefSet.findPreference(JIT_PREF);
String jitMode = SystemProperties.get(JIT_PERSIST_PROP,
SystemProperties.get(JIT_PROP, JIT_ENABLED));
mJitPref.setChecked(JIT_ENABLED.equals(jitMode));
pm.sleep_mode (Do not work on Non-MSM chipsets)
See sleep modes on device kernel in pm-data.c and pm.h
:highfive:
Some background info:
XLOUD, ClearAudio
If, and ONLY if your phone support xloud on stock ROM, is highly probable that this is ported for CyanogenMod and AOSP based roms, because these custom roms use proprietary drivers, firmwares, frameworks, app....
To enable, use this:
Code:
ro.semc.sound_effects_enabled=true
ro.semc.xloud.supported=true
persist.service.xloud.enable=1
The same is valid for ClearAudio. To enable use this:
Code:
ro.semc.sound_effects_enabled=true
ro.semc.clearaudio.supported=true
persist.service.clearaudio.enable=1

For ics 4.0 .4 ?
Sent from my MegaFon_SP-AI using xda premium

Ranisblogru said:
For ics 4.0 .4 ?
Sent from my MegaFon_SP-AI using xda premium
Click to expand...
Click to collapse
I'm looking at latest GIT tree of Android source code and latest CyanogenMod source code, so this topic is valid for latests releases (KK, JB, CM10.X, CM11), but may not be the same for earlier versions (to be sure I'm would have to look old commits...).

wow...I ve always wanted to do this resarch...but nerver had time
so all the "famous" build.prop tweaks are useless ????[

Crostantin said:
wow...I ve always wanted to do this resarch...but nerver had time
so all the "famous" build.prop tweaks are useless ????[
Click to expand...
Click to collapse
Yes they have been fake all the time, you might even get surprised when I tell you battery calibration is also totally bogus (it's for emulator only)

really?? I am surprise !!!!
You mean that i haven't to charge one for month from 0% to 100% and etc.......
If it's true a lot stuff I red about Lithium batteries make sense.....maybe

Most of the tweaks are useless, i totally agree!
Funny to see people "copy & paste" everything they see on the internet, just to "magically" make their phones faster...
Some interesting links regarding the topic:
First one...
Second one...
Take care

Wooaarr said:
Most of the tweaks are useless, i totally agree!
Funny to see people "copy & paste" everything they see on the internet, just to "magically" make their phones faster...
Some interesting links regarding the topic:
First one...
Second one...
Take care
Click to expand...
Click to collapse
what about 3G fast dormancy??
the tweak should be:
ro.rill.fast.dormancy.rule=0
...your opinion??

@LaraCraft304 great guide, might want to mention the fact that those cyanogenmod specific changes can be found in performance settings anyway so although the build.prop lines would work, there is no need to use them.

Your post looks eerily similar to Jeff Mixon's article.
http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/
http://www.jeffmixon.com/examining-build-prop-tweaks-android-ics-comprehensive-guide-part-2/
And FYI, this is a Motorola build.prop tweak ("mot") that in fact works (or at least used to) on Motorola devices.
Code:
ro.mot.eri.losalert.delay

upndwn4par said:
Your post looks eerily similar to Jeff Mixon's article.
http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/
http://www.jeffmixon.com/examining-build-prop-tweaks-android-ics-comprehensive-guide-part-2/
And FYI, this is a Motorola build.prop tweak ("mot") that in fact works (or at least used to) on Motorola devices.
Code:
ro.mot.eri.losalert.delay
Click to expand...
Click to collapse
But not quite, as "pm.sleep_mode" was debunked at that blog post. Atleast here it is stated that it does something for Qualcomm/MSM Devices.
@LaraCraft304 - Kudos to your work!

Does are only some "lines" some do really work like ones for ultra fast boot and deep sleep states
It depends on the device's chipset actually. It works on Qualcomms, Idk about exynos and nvidia

How about the Killjoy mod pack?

broodplank1337 said:
Yes they have been fake all the time, you might even get surprised when I tell you battery calibration is also totally bogus (it's for emulator only)
Click to expand...
Click to collapse
Haha..I've have that same debate for a while now with some friends. I agree 100% with you..But who am I a lowly Xda user with small thanks amount

yeah, I was surprised when I found out that lots of those tweaks were fake, I thought XDA folks knew better than that. I think the main reason people think they work is that to apply them you have to reboot your device, and EVERY device feels snappier after rebooting.

Please answer some of my questions related to build.prop and they are too many, can't be posted here. Located here: Please answer them!
http://forum.xda-developers.com/showthread.php?p=76239
Sent from my ST25i using XDA Premium 4 mobile app

Are you sure that the various APP_ADJ weren't implemented in Gingerbread? I remember seeing them in Samsung stock firmwares (although commented)...

In my opinion this is one of the most useful informative threads I have seen in a while.
I hope now everybody will realise that they have to be careful when reading the list of features of so many blazing fast and buttery smooth roms.
A lot of users and rom chefs use those build.prop tweaks just because everybody use them and because they have read tons of times that it improves the battery life, performance, etcetera. But the truth is that none of them checked or proved if those lines make a difference, so it's good to see that someone made research to prove that some of the most famouse buildprop tweaks are placebo effect.
I personally always wanted to understand what those "tweaks" exactly do and check if there is some kind of documentation that proves that it works before applying those changes to my phone. I wouldn't be surprised if the list of placebo effect tweaks gets bigger!

Sad part is that despite the build.prop tweaks being disproved, or rather most of them, it won't stop people from trying. Its the same as the Entropy generator thing we saw a while back. All these tweaks are pointless as if there was something you could change in terms of performance or battery then Google or the OEMs would have done it already.
Edit: should mention that when I was doing custom ROMs, the only tweaks I used where ones to the VM which I spent many countless hours investigating whether it improved or not, and the home screen lock (back when it did something).

hillbeast said:
......All these tweaks are pointless as if there was something you could change in terms of performance or battery then Google or the OEMs would have done it already.......
Click to expand...
Click to collapse
+10000000

Related

Source code for the G1 multitouch proof-of-concept posted

Anyone interested in exploring how the device tracks the two fingers can grab the source and play with it.
http://www.ryebrye.com/blog/2008/11/30/g1-multitouch-proof-of-concept-soure-code-posted/
RyeBrye said:
Anyone interested in exploring how the device tracks the two fingers can grab the source and play with it.
http://www.ryebrye.com/blog/2008/11/30/g1-multitouch-proof-of-concept-soure-code-posted/
Click to expand...
Click to collapse
It looks like the stuff you uncommented is just debug code, and the driver is still in fact reporting 2 finger tracking:
Code:
if (z) {
input_report_abs(ts->input_dev, ABS_X, pos[0][0]);
input_report_abs(ts->input_dev, ABS_Y, pos[0][1]);
}
input_report_abs(ts->input_dev, ABS_PRESSURE, z);
input_report_abs(ts->input_dev, ABS_TOOL_WIDTH, w);
input_report_key(ts->input_dev, BTN_TOUCH, finger);
finger2_pressed = finger > 1 && finger != 7;
input_report_key(ts->input_dev, BTN_2, finger2_pressed);
if (finger2_pressed) {
input_report_abs(ts->input_dev, ABS_HAT0X, pos[1][0]);
input_report_abs(ts->input_dev, ABS_HAT0Y, pos[1][1]);
}
pos[1][0] and pos[1][1] is the position of finger 2, and pos[0][0] and pos[0][1] is the position of finger 1.
They are populated in the loop:
Code:
int p = buf[base + 1];
...
pos[f][a] = p;
My guess is that the C++ framework code and Java code need to be tweaked to handle multitouch (with no changes to the driver at all). I'm not too familiar with the code. Have you figured out how the input_report_abs gets handled?
apple's software pattents
I am afraid this is becoming *ALSO* a legal issue now :
http://www.newlc.com/en/multitouch-feature-any-screen#comment-50240
Way to dig up a 3 month old thread and post a completely irrelevant news article in it.
LPChris said:
Way to dig up a 3 month old thread and post a completely irrelevant news article in it.
Click to expand...
Click to collapse
relax. next time, just move on to the next thread it won't hurt anybody.
and it is relevant, sorta.

Wanting to develop for WM haivng some problems

Hi I want to make an application using location, I found this tutorial
http://msdn.microsoft.com/en-us/library/dd938890.aspx#RetrievingLocationInformationthroughGPS
which looks very helpful but because I am new to visual studio I am having some problems.
1) is the article it says "This article includes complete sample code." but I cant find a download for all the code.
2) he only mentions referencing Microsoft.WindowsMobile.Samples.Location.dll which I have done but the class LatLong is still unknown
3) I made a sample program without the LatLong class just to experiment I get the following error on my device
"Microsoft.WindowsMobile.Samples.Location, Version=1.0.3448.25673, Culture=neutral, PublicKeyToken=null, or one of its dependencies, was not found
any idea what this means?
4) Could all my problems be because I am using visual studio 2005 and not 2008? I found a code project that looked really helpful but when trying to open it it says that it cant because it is from a newer version of the software, anything that can be done?
5) I find MSDN confusing for finding out what to reference to add a class for example this is the page for the LatLong class http://msdn.microsoft.com/en-us/library/cc514548.aspx
with the java online info the first thing you always see is where the class is found but it seems to be missing for this class. Other basig classes appear similar to java.
below is my sample code its basically taken from the article but I have commented out the references to LatLong and put in checks instead
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using Microsoft.WindowsMobile.Samples.Location;
namespace DeviceApplication3
{
public partial class Form1 : Form
{
private Gps gps;
int count = 0;
public Form1()
{
InitializeComponent();
gps = new Gps();
gps.Open();
}
private void button1_Click(object sender, EventArgs e)
{
textBox1.Text = (getGpsString());
}
private string getGpsString()
{
GpsPosition position = gps.GetPosition();
/*LatLong location = new LatLong();
if (position.LatitudeValid)
location.Latitude = position.Latitude;
if (position.LongitudeValid)
location.Longitude = position.Longitude;
if (position.HeadingValid)
location.Heading = position.Heading;*/
StringBuilder sb = new StringBuilder();
sb.Append("\n");
sb.Append("Latitude = ");
if (position.LatitudeValid)
{
sb.Append(position.Latitude.ToString() + "\n");
}
else
{
sb.Append("Not found yet\n");
}
sb.Append("Longitude = ");
if (position.LongitudeValid)
{
sb.Append(position.Longitude.ToString() + "\n");
}
else
{
sb.Append("Not found yet\n");
}
sb.Append("Heading = ");
if (position.HeadingValid)
{
sb.Append(position.Heading.ToString() + "\n");
}
else
{
sb.Append("Not found yet\n");
}
return sb.ToString();
}
}
}
Microsoft.WindowsMobile.Samples.Location.dll
is this file located in bin\debug and or \bin\release
?
and does it only give runtime errors or also compile time ?
no it compiles fine, can you see anything wrong with my code? The weird thing is the form comes up using the emulator but not on the device. Could it be because I have a custom rom that seems to have compact framework 3.5? I would assume it would be back compatible?
How have you deployed it to the device? Have you copied the .exe and the Location.dll?
one thing you could also test was if you could disable the stuff in the gps
and just run a program without it to verify that it's not missing net3.5's fault
heliosdev said:
How have you deployed it to the device? Have you copied the .exe and the Location.dll?
Click to expand...
Click to collapse
Hi thanks for this I didnt copy over the dll I'm very silly.
So what do you guys think about loading projects ment for vs 2008 in 2005 is this impossible ? or can i convert them somehow?
sure it's only the project and solution files which differ
add the cs files manualy and it should work fine
Use the same name to create the new project in vs2005 to have the same namespace.
You'll have to do some manual changes if the code uses c#3.0 .net 3.5 features.
Thanks guys your awesome,
very random and off topic but since your programming kings ill ask anyway,
I think I want to eventually work in the gaming industry, I'm close(3months) to finishing my MSc CompSci conversion course and I am looking for jobs, its quite aparent that most games companys don't want unexperienced people so do you guys have any ideas of places to apply for that will give the the necessary experience? btw I have no taught experience with C++ which I think is my biggest dissadvantage, I do know C and java quite well though and as you can tell just starting to play with C#.
your help is always appreciated.
well, continue with general programming (object oriented programming, ui development, database, network,...). There are so many different fields in software development!
For example take a look at the chapters of the books in the game programming gems series to see what (not only) gaming companies are working on. In general for beginning there is a lot of information online where you'll find tons of tutorials.
Try to get a profound base in programming.
Starting with your gps application, develop a gui, save/load the positions (database), visualize the points...
heliosdev said:
well, continue with general programming (object oriented programming, ui development, database, network,...). There are so many different fields in software development!
For example take a look at the chapters of the books in the game programming gems series to see what (not only) gaming companies are working on. In general for beginning there is a lot of information online where you'll find tons of tutorials.
Try to get a profound base in programming.
Starting with your gps application, develop a gui, save/load the positions (database), visualize the points...
Click to expand...
Click to collapse
Hi sorry for the late reply I upgraded to windows 7 last night to try and improve my rubbish laptop, seems to be a bit better btw,
anyway just want to say thanks for the advice. also my app will use google maps yahoo zonetag and windows live earth (or bing maps if thats what there calling it now) I think for some of thoes services I will need to pay to realease my app to the public even if its free but what about testers would I be able to give it to say 10 people?

[dev] do you want HTC official kernel 2.6.29 sources for ALL devices?

I think that some devs already knew this and they are working on this, but I cannot understand why they didn't tell this to other devs.
download HTC desirec_2.6.29 kernel sources here:
http://developer.htc.com/ , if you couldn't see it, use tor or some other proxy software to visit the site.
extract it. look into arch/arm/configs folder.
you will find a file named "0001-Symptom-HeroC-remove-other-project-board-config-fi.patch"
revert this patch, you will get almost all board files. with some minor changes, you could boot the HTC official 2.6.29 kernel on your devices.
what changes? 32A new radio for example:
1. the "EBI1 supports 256MB" is removed, add it or make your changes, a simple modification, at beginning of board-sapphire.h:
#ifndef __ARCH_ARM_MACH_MSM_BOARD_SAPPHIRE_H
#define __ARCH_ARM_MACH_MSM_BOARD_SAPPHIRE_H
#define CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1 //add this line.
2. the freq table for 32A is not added (this is the main reason why you can't boot), edit it in the acpulock-arm11.c:
static struct freq_tbl_map acpu_freq_tbl_list[] = {
/* you do not need to comment out these devices, though they are useless for 32A
TABLE_CONFIG(LEGEND, 7227),
TABLE_CONFIG(LATTE, 7227),
TABLE_CONFIG(LIBERTY, 7227),
TABLE_CONFIG(BAHAMAS, 72xx),
TABLE_CONFIG(MEMPHIS, 72xx),
TABLE_CONFIG(PARADISE, 72xx),
TABLE_CONFIG(HERO, 72xx),
TABLE_CONFIG(HEROC, 72xx),
TABLE_CONFIG(DESIREC, 72xx),
*/
TABLE_CONFIG(SAPPHIRE, 72xx), //our device
{ 0, 0, 0}
};
3. touchscreen data for elan hardware is not correct. but our 32A phone don't use it. comment out these things in board-sapphire.c:
/* comment out this
static struct elan_i2c_platform_data elan_i2c_data[] = {
{
.version = 0x104,
.abs_x_min = 0,
.abs_y_min = 0,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x103,
.abs_x_min = 0,
.abs_x_max = 512 * 2,
.abs_y_min = 0,
.abs_y_max = 896 * 2,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x102,
.abs_x_min = 0,
.abs_x_max = 384,
.abs_y_min = 0,
.abs_y_max = 576,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x101,
.abs_x_min = 32 + 1,
.abs_x_max = 352 - 1,
.abs_y_min = 32 + 1,
.abs_y_max = 544 - 1,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, // or you could just comment out these fields (in all structs in this array)
.display_height = 480, // in this case, you don't need to comment out all elan things.
}
};
*/
static struct i2c_board_info i2c_devices[] = {
{
I2C_BOARD_INFO(SYNAPTICS_I2C_RMI_NAME, 0x20),
.platform_data = sapphire_ts_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_TP_ATT_N)
},
/* comment out this, if you disabled the entire elan data array.
{
I2C_BOARD_INFO(ELAN_8232_I2C_NAME, 0x10),
.platform_data = &elan_i2c_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_TP_ATT_N),
},
*/
{
I2C_BOARD_INFO("akm8976", 0x1C),
.platform_data = &compass_platform_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_COMPASS_IRQ),
},
};
maybe there are other modifications to be needed by compiling the kernel, but they could be found easily, just follow the output by your compiler.
I remembered that with only these changes, the kernel could be compiled, the device could be booted, and all things were working fine except the color of the screen is not correct(for this problem, we could get right settings from htc-kernel-2.6.27 for sapp and hero).
I am under Windows now so I can't make a patch which would work directly. but with the original leaked patch, I think that it is not difficult to make things right by yourselves.
Great news Sanpei. Now maybe our android 2.1 will work better on new radio.
Thats more than great news What can we say more ? Thank U for that But there are not many devs who wants to play with kernels for Magic ;P You were the only one Hope one day U`ll bring us good .29 to live Cheers !
And it only took you about six months to share this info with others. How great...
Nevertheless, thanks.
Case_ at least he is sharing it now
sanpei I'm working off HeroC source:
http://github.com/toastcfh/CdMa-HeRoC-2.6.29/
The correct changes were made in board-sapphire files already. Might be other stuff.
All devs need is to add the EBI1 config!
there are additional mods sanpei has not mentioned. maybe that's why his kernels have been a little finicky. but this is probably it: http://github.com/cyanogen/cm-kernel/commit/fef60feb4caa22d82a35636b1679243e67512ce5#L7L160
CPU freq tablets already fully support our CPU there. Overclock should work as well.
As for eflan, I'll have to play with it
toastcfh sent me a compile last night with board files added, but I think there was still some stuff missing, but...
EBI1 was why my device didn't boot! Going to compile that and see what happens now!
As for him not sharing it, at least he is sharing it now.
Thanks sanpei my fellow countryman
I feel dumb for compiling the source when the board files wheren't even there. I don't know if this is all I needed to do but this is a big step in the right direction. I have no knowledge of how stuff like this works. I am not a dev still.
sanpei I wish I had better understanding of all this code. But I don't. In any case thanks for sharing this with us now.
the only two reasons i didnt make the patch public is one because of the EVO (superconic) source in it, second in hopes that it wouldnt be the last mess up by HTC. the source has ony been up for 3 or 4 weeks. so the 6 months idk. i released the source as i got it to compile. i had other projects also like making source for the CDMA heroc. which oddly enough the patch says heroc on it :/ but lacks source for our device. as soon as i finished the heroc project of creating board files compatible with the heroc, i moved on to commitig the board files for the other devices. starting with the GSM hero (which was unfinished) and then the Sapphire (also unfinished). all know devices have been commited and someone at least informed of the files being there. im a busy person and have a life of my own. the patch did me no good while i was creating board files for the CDMA hero. once i finished that i turned my attention to releasing the rest of the devices. but yeah i doubt HTC will make this mistake again for sure now that its publicly announced.
so yeah i only was trying to protect a interest that everyone can gain from.
interesting none the less...
first try didn't go (defined ebi1 in .h file, compiled and flashed)
i'm giving it another last chance, this time defining ebi1 in the kconfig.
i might be missing more stuff than this.
edit: I'm blind. didnt' edit acpuclock properly. lol. doing another compile.
for the color issues look into ur panel settings. its most likely the reason the color is messed up. maybe wrong settings
Holy **** it's booting
Colors look okay actually. My touchscreen is broked though!
Cursorsense too lol
BUTTONS ALL OKAY
sounds interesting lets see what you get fixed
I'm hoping you can get it to work properly, good luck mate, crossed fingers !
All you need to start with to get 2.1 roms working
Not all of sanpei's changes are needed to fix what is on toastcfh's github.
My .config is still messed I bet.
In Cursorsense pretty much everything is broken.
http://www.youtube.com/watch?v=lasToRLQQCA&feature=player_embedded
I HAVE A BOOTSCREEN ON AHERO
For devs, if you are working off toastcfh's github source, this is what you need to get it working:
a)
acpuclockarm11.c sanpei mentioned
edit it in the acpulock-arm11.c:
static struct freq_tbl_map acpu_freq_tbl_list[] = {
/* you do not need to comment out these devices, though they are useless for 32A
TABLE_CONFIG(LEGEND, 7227),
TABLE_CONFIG(LATTE, 7227),
TABLE_CONFIG(LIBERTY, 7227),
TABLE_CONFIG(BAHAMAS, 72xx),
TABLE_CONFIG(MEMPHIS, 72xx),
TABLE_CONFIG(PARADISE, 72xx),
TABLE_CONFIG(HERO, 72xx),
TABLE_CONFIG(HEROC, 72xx),
TABLE_CONFIG(DESIREC, 72xx),
*/
TABLE_CONFIG(SAPPHIRE, 72xx), //our device
{ 0, 0, 0}
};
Click to expand...
Click to collapse
b) touchscreen fix by using the aosp synaptics driver here (rename this file)
http://github.com/toastcfh/CdMa-HeRoC-2.6.29/tree/master/drivers/input/touchscreen/
synaptics_i2c_rmi.c-AOSP-fix -> synaptics_i2c_rmi.c
c)
make changes to 'Kconfig' here, and enabled the config option during make
http://github.com/cyanogen/cm-kernel/commit/fef60feb4caa22d82a35636b1679243e67512ce5
The board files that are up work perfectly.
d) work off my config or similar:
http://pastebin.com/cKkBNtKJ
e) download aHero for GSM Hero here:
http://forum.xda-developers.com/showthread.php?t=638584
e) PROFIT
note that all apps are force-closing on aHero right now. but launcher works. boot screen works. radio works.
I will play with this later. For now I need a working phone.
Did a wipe. Most apps work. Random stuff is broken but that's okay.
But I talked to zinx in irc. He said CM-Kernel actually already supports new radio Magics.
commited the changes above to alow the sapphire to boot
github.com/toastcfh
It boots but the drivers are broked. I messed up my source and don't want to touch it for a while.
Sanpei?
Case_ said:
And it only took you about six months to share this info with others. How great...
Nevertheless, thanks.
Click to expand...
Click to collapse
do you know when the desirec_2.6.29 had been released? or, do you think that I was a time traveler?
I found this leaked patch 1~2 weeks ago. I was working on my career jobs these days (I even didn't have time to visit here), and I thought that others would find it and share with each other, so I didn't post it immediately.
yesterday, when I visited here, I found that it was not mentioned by any other people. so I decided to write something.
and hope that it won't surprise you, the .29 and .32 kernel builds made by me are not based on htc-kernels, and I never use any files from HTC. I just made aosp kernel working with our devices.
to put it simply: for 32A device, I don't need any pieces of codes from HTC, I just need the information about radio versions and interfaces between hardware and software, and I already know/understand some of them.
to be honest, I never change my mind. I won't open "my" sources before I would have considered that they could be open.
but this patch, it is leaked from HTC's sources and I don't make any efforts on it. so I think that if I shared this information, all of you will get what you want, and it is not conflict with my "moral standards" what I had mentioned in previous arguments.
maybe you and others think that I am a selfish man or bad person. I don't care. take what you want, and leave me alone.
but if you and others could reconsider what I am, and think about if I could be a friend of you, I will be very happy.
Oh but we (I) did make a thread. It should be on the 3rd page or so by now. This ROM is flooded by rom ports and has zero dev activity. There's just hopelessly few devs on Sapphire forums. That's why all you see see are ports and no AOSP stuff.
But since you have a .3X kernel anyways I don't see you really needing this. Toastcfh did remind me to replace the synaptic touchscreen driver to get it working properly for the Sapphire.
Or we could use your source. Because I have no idea what I need to do to fix wifi and camera on my port. I have CM5 working with sound, rotation, sleep, Youtube, 3D on a 32A Magic. It's not my phone though so I wont try much more on it now.
I first booted into Cursorsense, then aHero and finally Cyanogenmod 5. CM5 as a ***** because squash fs didn't compile, so it broke my xbin completely. I worked around it by extracting xbin through my virtual machine since my PC runs windows before I realized I can just install busybox from the recovery onto the phone. I pushed the lib*camera*.so files from aHero and after data wipe I had ZERO force closes, bluetooth + audio + video + rotation. Not bad for a noob, but I have no idea how to fix. This isn't my career path
toastcfh helped me a lot
Question
Doesn't it make more sense to get Cyanogen's kernel source working? All it needs is AMSS 6355 support, and the code difference doesn't seem to be that great. It already has up to AMSS6350 the last time I checked. It's actually not that bad to add new phones, but their kernel source is kind of different than HTC's now that it's now harder to just add new phones. zinx expressed interest, and I'm sure bcrook is interested as well.
We can use a plain HTC source and adapt it, but CM already should have a lot of 32a bits in it including native EBi1 support, compatible makefiles and a kernel version ready to boot any 2.1 rom.
The major differences between the AMSS versions 6350 and 6355 seem to be in the multimedia msm drivers. That's probably less than 10 files to edit in total.
The existing CM5 config should build new radio 32As no problem.
But is there a point anymore? Sanpei your kernel seems pretty darn stable right now. If I figure out how to throw it in Koush Anykernel we can probably have working ports for every ROM out there. The only thing is since you have source code sometimes the local version doesn't work well with some ROMs. So yes we still want your source because it works well.
xaueious said:
Oh but we (I) did make a thread. It should be on the 3rd page or so by now. This ROM is flooded by rom ports and has zero dev activity. There's just hopelessly few devs on Sapphire forums. That's why all you see see are ports and no AOSP stuff.
But since you have a .3X kernel anyways I don't see you really needing this. Toastcfh did remind me to replace the synaptic touchscreen driver to get it working properly for the Sapphire.
Or we could use your source. Because I have no idea what I need to do to fix wifi and camera on my port. I have CM5 working with sound, rotation, sleep, Youtube, 3D on a 32A Magic. It's not my phone though so I wont try much more on it now.
I first booted into Cursorsense, then aHero and finally Cyanogenmod 5. CM5 as a ***** because squash fs didn't compile, so it broke my xbin completely. I worked around it by extracting xbin through my virtual machine since my PC runs windows before I realized I can just install busybox from the recovery onto the phone. I pushed the lib*camera*.so files from aHero and after data wipe I had ZERO force closes, bluetooth + audio + video + rotation. Not bad for a noob, but I have no idea how to fix. This isn't my career path
toastcfh helped me a lot
Question
Doesn't it make more sense to get Cyanogen's kernel source working? All it needs is AMSS 6355 support, and the code difference doesn't seem to be that great. It already has up to AMSS6350 the last time I checked. It's actually not that bad to add new phones, but their kernel source is kind of different than HTC's now that it's now harder to just add new phones. zinx expressed interest, and I'm sure bcrook is interested as well.
We can use a plain HTC source and adapt it, but CM already should have a lot of 32a bits in it including native EBi1 support, compatible makefiles and a kernel version ready to boot any 2.1 rom.
The major differences between the AMSS versions 6350 and 6355 seem to be in the multimedia msm drivers. That's probably less than 10 files to edit in total.
The existing CM5 config should build new radio 32As no problem.
But is there a point anymore? Sanpei your kernel seems pretty darn stable right now. If I figure out how to throw it in Koush Anykernel we can probably have working ports for every ROM out there. The only thing is since you have source code sometimes the local version doesn't work well with some ROMs. So yes we still want your source because it works well.
Click to expand...
Click to collapse
no, it is not that "my" kernel works well, it is the original aosp kernel works well, except some minor bugs (which are already fixed in my kernel build). and I think that .32 is more suitable than .33, since .33 is marked as experimental by Google.
some "custom" mods of .33 use older drivers which are taken from kernel sources of an older version. I can't sure if these drivers could work properly with new radio, though you could boot your device and most features will works.
and sorry, I don't want to talk about other's works. but I must repeat again: all "custom" kernels are just original kernels from Google/Qualcomm/HTC's repo, and with little public patches made by some real programmers.
so don't care about their brands. you should find out what they are using: drivers, hacks, and patches of features.
if you use a lib (in userspace or android layer) because it is necessary for a radio version (because the lib and the radio have some conventions directly), then you should choose the kernel driver which could work with this lib. KERNEL itself is NOT the KEY problem in this case.
in fact, the most programming jobs I had done are in android layer; and if I have spare time, what I would work on are in android layer too. (except OC or other things which do most things in the kernel).
for devs who don't have enough experiences in kernel jobs or programming, and if they want a most stable kernel which would works with new radio, I recommend them start from htc-kernel. it's always more reliable, because we (I, you and others) can't know every changes of hardware configurations between each radio versions, and HTC knows these things exactly.
but why I would still be working on .32 kernel?
because I think that I could fix every bugs (if we would encounter) by myself , and I want to learn and remember the new changes Google made in kernel. thus, I wouldn't need to learn these things again when newer versions of android (they might need these changes in kernel) will be coming.
a kernel and some libs for new radio, and they could work with both AOSP and HTC ROMs, it's my current goal. and you could see giant's work on AOSP ROM, I think that we are more close to this goal now.
"my" sources..., I will think about it (and I often considered if it's the time). but I am rather obstinate
and for problems of using htc-kernel, I can't remember all the details of my tweaks and tests. maybe I will take a look for you. but I won't make any promise, since I really don't have enough time at current.
Here is a slightly separate but related thought.
It seems to me (and I am the first to admit I am not knowledgeable in this stuff so I could be wrong) that one of the following statements are true regarding the devs working on the G1 and other phones:
(1) Either they are not very knowledgeable when it comes to kernel programming and development (and so they are not capable of getting a kernel working on the 32a like Sanpei did), or
(2) The other devs are not interested about the 32a user community enough to spend their time providing us with support (and so they do not focus their time getting a kernel working on the 32a).
My guess is that it is a combination of the two possibilities above. Devs are not as knowledgeable as we think when it comes to kernel development and the required changes HTC and qualcomm do to get a kernel working on different phones especially the 32a, and even if they could do some reverse engineering and some hacking that they don't want to spend the time and energy supporting the 32a user community which is probably a lot smaller than the 32b community. (I don't fault anyone for not wanting to support a community - it takes time and there is probably very little financial reward.)
I believe the lack of a working new radio kernel for 32a supports Sanpei's view that other devs should not be branding the kernel with their names after they have done some minor tweaks. I believe that anyone capable of doing major work on a kernel worth re-branding the kernel to their own name would have already been able to get it working on the 32a properly.
But what do I know.
Lastly, I don't mean to disrespect any dev with these views. All of the devs have contributed - big or small - to the user experience and all devs have done a lot more than I will or could ever do to support Android. However, I do think we should be honest about what we can and can't do and what we take credit for.
It is also interesting....
(1) How xaueious has good things to say about "Sanpei's" kernel
(2) How Sanpei refuses to call it his kernel, or to take credit for the 6.35 .32 kernel, and how Sanpei actually plays down or belittles what he had to do to get the .32 kernel working on the new radio (something which no one else has done), and
(3) How guys like Alan who know very little about kernel development choose to criticise the .32 new radio kernel ported by Sanpei, going so far to call it "garbage"
All of these things point to people's approach and character.

Any working 4G toggles yet?

I gotta say I'm a bit surprised by the lack of ambition to get a working 4G toggle. Every phone I've had, there has always been a demand to get a working 4G toggle. Has anyone heard of anything about this? Luckily this phone gets good battery life so its not that big of a deal but it'd be nice to have for those times when your trying to really save battery.
I know of the app Phone Info, but its gotten a lot of negative views around here about losing data with it so I've avoided it since.
rehpyc has been working on one. I've sent him some info that I discovered trying to find the right system call to switch between 3g and 4g.
Rather than simply be disappointed, would you like to help?
Sent from my SCH-I535 using xda premium
I'm trying to find where the settings (which can be accessed in the phone info -> Device Information area) are stored.
-Using dex2jar and jdgui, I decompiled the phone info app into java source (.java) files. It's a really small app that just calls the "TestingSettings" functionality of the SecSettings.apk
-We can access the "TestingSettings" by simply running "am start com.android.settings/.TestingSettings" in terminal. It essentially does the exact same thing as launching the Phone Info app.
-Using dex2jar and jdgui, I decompiled the SecSettings.apk into java source (.java) files. Digging through the files, I found that the RadioInfo class. This class contains a String array mPreferredNetworkLabels which lists all the settings in the spinner we choose the network type (CDMA Auto (PRL), LTE/CDMA/EvDo, etc). This class seems to provide functionality for listening to GUI changes on the "PreferredNetworkType" spinner. Not exactly sure what it does from there, but hopefully it can be traced down to some methods that either store the settings into a file or to a SQLite database.
In dex2jar -> JD gui for SecSettings.apk, Radioinfo class has
public RadioInfo()
{
String[] arrayOfString = new String[14];
arrayOfString[0] = "WCDMA preferred";
arrayOfString[1] = "GSM only";
arrayOfString[2] = "WCDMA only";
arrayOfString[3] = "GSM auto (PRL)";
arrayOfString[4] = "CDMA auto (PRL)";
arrayOfString[5] = "CDMA only";
arrayOfString[6] = "EvDo only";
arrayOfString[7] = "GSM/CDMA auto (PRL)";
arrayOfString[8] = "LTE/CDMA/EvDo";
arrayOfString[9] = "LTE/GSM/WCDMA";
arrayOfString[10] = "Global";
arrayOfString[11] = "LTE only";
arrayOfString[12] = "LTE/WCDMA";
arrayOfString[13] = "Unknown";
this.mPreferredNetworkLabels = arrayOfString;
}
RadioInfo.java sets the network type in the following code (lines 297-309):
AdapterView.OnItemSelectedListener mPreferredNetworkHandler = new AdapterView.OnItemSelectedListener()
{
public void onItemSelected(AdapterView paramAnonymousAdapterView, View paramAnonymousView, int paramAnonymousInt, long paramAnonymousLong)
{
Message localMessage = RadioInfo.this.mHandler.obtainMessage(1001);
if ((paramAnonymousInt >= 0) && (paramAnonymousInt <= -2 + RadioInfo.this.mPreferredNetworkLabels.length))
RadioInfo.this.phone.setPreferredNetworkType(paramAnonymousInt, localMessage);
}
public void onNothingSelected(AdapterView paramAnonymousAdapterView)
{
}
};
The key line is line 303:
RadioInfo.this.phone.setPreferredNetworkType(paramAnonymousInt, localMessage);
Some info about the setPreferredNetworkType() method:
void setPreferredNetworkType(int networkType, Message response);
Requests to set the preferred network type for searching and registering (CS/PS domain, RAT, and operation mode)
Parameters:
networkType one of NT_*_TYPE
response is callback message
The phone data member is a private data member set to null on line 422:
private Phone phone = null;
The phone data member is set to the Default Phone on RadioInfo object creation (onCreate) in line 916:
this.phone = PhoneFactory.getDefaultPhone();
Based on the above information, I believe we would need to create a toggle which would execute a small java program to access the setPreferredNetworkType() method from a Phone object instantiated from the PhoneFactory.getDefaultPhone() method. I believe Phone resides in com.android.internal.telephony, but in order to gain access to the internal android stuff we would need to do something like the following article provides:
https://devmaze.wordpress.com/2011/01/18/using-com-android-internal-part-1-introduction/
That's all the time I have for the moment...
great info! Unfortunately I have no idea how that stuff works. I praise the devs who do this work and members like you who work on it. I wish I could.
Sorry if I came off as demanding of wanting a toggle, I'm just surprised I haven't heard more about it. But good to know it's being worked on. I'd definitely be willing to help test when something is cooked up though
tu3218 said:
great info! Unfortunately I have no idea how that stuff works. I praise the devs who do this work and members like you who work on it. I wish I could.
Sorry if I came off as demanding of wanting a toggle, I'm just surprised I haven't heard more about it. But good to know it's being worked on. I'd definitely be willing to help test when something is cooked up though
Click to expand...
Click to collapse
Unfortunately I'm short on time these days, but I wanted to get the info out there so someone might be able to use it. I really do think we're close, but I'm more of a hacker/modder than an Android dev. Someone comfortable with development on Android might be able to speed this up significantly.
Sent from my SCH-I535 using xda premium

[Q] Potential fix for Katkiss 4.3 on Asus SL101 slider

I am a new member, and cannot post directly to the Dev forums yet, so I am placing this here, in the hopes that someone can repost, or pass this on to timduru (or other involved devs)
From the KatKiss thread -- http://forum.xda-developers.com/showthread.php?p=47853666&highlight=sl101#post47853666
Quote:
Originally Posted by martyr2k6 View Post
Just wanted to point out that I am running this on my SL101 with ZERO hiccups...
...
Any chance there is a way to resolve the hardware keyboard locking issue or the USB port not working?
Keyboard should most likely be a matter of inverting the lid switch in the kernel.
But difficult to test without an SL101.
Click to expand...
Click to collapse
I develop for my arch linux box , and have built custom kernels for it, so i took a quick stab at looking through the source code for the katkernel for the tf101 - > https://github.com/timduru/tf101-katkernel/blob/c6199499470976a55973e566b0b804e4b4796b5c/drivers/acpi/dock.c, and it would appear that the lid switch section he is referring to is here:
Code:
static void dock_event(struct dock_station *ds, u32 event, int num)
{
struct device *dev = &ds->dock_device->dev;
char event_string[13];
char *envp[] = { event_string, NULL };
struct dock_dependent_device *dd;
if (num == UNDOCK_EVENT)
sprintf(event_string, "EVENT=undock");
else
sprintf(event_string, "EVENT=dock");
/*
* Indicate that the status of the dock station has
* changed.
*/
if (num == DOCK_EVENT)
kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);
list_for_each_entry(dd, &ds->hotplug_devices, hotplug_list)
if (dd->ops && dd->ops->uevent)
dd->ops->uevent(dd->handle, event, dd->context);
if (num != DOCK_EVENT)
kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);
}
If that is true, a simple edit like so should do the trick:
Code:
if (num == UNDOCK_EVENT)
sprintf(event_string, "EVENT=dock");
else
sprintf(event_string, "EVENT=undock");
However, I have not set up a development environment for the android before, and it seems like a fairly large learning curve to setup the linaro toolchain, download, change that source, compile, package and test the change. Especially since my unfamiliarity with android dev in general would increase the odds of it not working due to user error!
If someone (initial dev??) would make that change, and save a sl101-version of the kernel for testing, I would be glad to load it and report back.
If someone would rather hold my hand a little bit with setting up the toolchain and building and packaging the kernel, I'd be willing to try it myself.
Thanks for any help, either way! The ROM looks/works great on my sl101...except for the whole 'not able to open it' thing

Categories

Resources