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.
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.
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
Hi Guys,
I wanna start developing apps for the gearS2. Foir now I have some experience with html and several other languages mainly for windows applications and also last programming job was like 6 years ago so I'm not really up to date with all the different options for developing.
For start I tried to use the tizen SDK but I'm a little lost due to the variaty of options and also the quite buggy SDK. Installing the 2.4 SDK left me with an error for the simulator (hax not working). I t hink i got arround this by installing this manually. Emulator works now but for example the UI builder doesnt work. So my thought is to start a web app with tau as this seems to work quite reliable. My goal is to write a basic control of my hue lights (I know there is an app for that but I wanna try to build my own). My plan is to use an java lib for the hue commands and do the rest via the tau/html/javascript.
Now my question is if anyone can give me any advice on how to start developing. Does my plan seem valid. Can anyone help me or give me some tips? Maybe I'm missing something or someone just has some shortcuts.
Thanks in advance.
Björn
Hi.
I found this "howto" : http://www.tizenexperts.com/2015/12/how-to-deploy-to-gear-s2-smartwatch/
It helped me to successfully deploy a project sample on my gear s2 folllowing these steps :
- install sdk
- generate & configure author certificate.
- download, compile and run/deploy a project sample on the gear s2 (SensorBall).
During the "Request the Certificate" step, I ran into this java exception :
Unhandled event loop exception No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]
Click to expand...
Click to collapse
I'm on "debian jessie" with "openjdk7":
If this happens:
- install package "libwebkitgtk-1.0-0"
- add "-Dorg.eclipse.swt.browser.DefaultType=webkit" to you "eclipse.ini" file
- restart tizen.
At the end, you'll have a new app installed on your watch. You can recognized it with the tizen icon.
I hope this can help you.
Bye.
thank you for your feedback akaiah.
I found this site earlier, requested a certificate but then I couldnt find the site again. So thx for the link.
My problems are more linked to
a) the general structure of webapps for tizen
b) rusty coding skills (last time i coded was 6 years ago and mainly c# / object pascal for windows)
c) problems with tau / it's documentation
Maybe someone can help with a few detailed questions.
First question is regarding the online samples. I've found the following code in one sample for wearables (calendar app) but I don't know what this is and if I should be using stuff like this. It doesn't look like standard javascript to me but I can't find any API/library included either:
Code:
/**
* App module.
* @requires {@link Calendar/views/initPage}
* @namespace Calendar/app
* @memberof Calendar
*/
define({
name: 'app',
requires: [
'views/initPage'
],
def: function appInit() {
'use strict';
/**
* Initializes the app.
* @memberof Calendar/app
*/
function init() {
console.log('app::init');
}
return {
init: init
};
}
});
Second question is regarding jquery. Which version should I use and how am I supposed to include this? I'm using the 2.4 SDK download but programming a wearable web app with 2.3.1. I tried inlcuding jquery by downloading the latest version 2.1.4 (uncompressed) and putting it in my lib file folder, then including it in the html header. I have the feeling though that this is causing some issues. E.G. some notations don't work:
Code:
$( "#divname" ).innerHTML = "newtext";
doesnt work. No error just no result.
Third question is regarding tau. I tried to create a popup and register a callback for the popupafterclose-event like this but it doesn't work (event is not fired)
HTML:
<!--Popup HTML code-->
<div id="popup" data-role="popup">
<p>This is a completely basic popup, no options set.</p>
</div>
<script>
// Use popup events
var popup = document.getElementById("popup");
popup.addEventListener("popupafteropen", function()
{
// Implement code for popupafteropen event
});
</script>
taken form HERE
What am I doing wrong here? Is this the correct API im looking here or maybe does it collide with the jquery library?
For any tips I would be very thankfull.
Greetings
Björn
Wow thanks finally some one. I wold love to root my device ..
If theres a way.
If anyone was wondering about this issue, I kind of got this solved.
I just started an new project copied over all code and removed my jquqery imports and the code that gave me errors before just works fine. TAU in generell seems to be quite buggy and is easily be destroyed by an "unlucky" combination of UI changes (opening a popup or another window).
Even a week later I still don't know what the code in the calendar sample is from and tau seems not to be the most stable library out there. If anyone else has trouble starting developing for this I'm happy to share more experiences.
Greetings from germany