[ROM][GT-I9100][4.0.4] CyanogenMod 9 nightly builds | DEVELOPMENT THREAD
They all are awesome.
Rc1 is code frozen, only fixes are added. Nightly is bleeding edge.
Also better ask these kind of questions in the general thread. This one is for development. Thanks!
Sent from my SGH-I777 using Tapatalk 2
I got this weird message when doing make clean && make clobber
rom builds fine as usual, but never got the above message. does it mean something?
Code:
Checking build tools versions...
build/core/main.mk:324: implicitly installing apns-conf_sdk.xmlrom builds fine as usual, but never got the above message. does it mean something?
could someone here change the Romanian translations of the on-off toggles? it is currently like this:
ON = ACTIVAT
OFF = DEZACTIVAT
change it to:
ON = Ac.
OFF = Dez.
the way it is now makes the sliders too big
Also, could someone point me to a more proper place where I can request other cm9 translations? Currently, I don't think there is anyone responsable for Romanian translations and I would gladly help, BUT, for the love of God, please don't ask me to make and send patches myself, I have NO Android and gerrit knowledge, I would have done it if I could.
ON = ACTIVAT
OFF = DEZACTIVAT
change it to:
ON = Ac.
OFF = Dez.
the way it is now makes the sliders too big
Also, could someone point me to a more proper place where I can request other cm9 translations? Currently, I don't think there is anyone responsable for Romanian translations and I would gladly help, BUT, for the love of God, please don't ask me to make and send patches myself, I have NO Android and gerrit knowledge, I would have done it if I could.
a2dp audio issues returned today. I'm using 07-03 nighlty. Last two days a2dp works except submitting title information (known issue).
Today after automatic pairing with my car unit was done, audio playback doesn't start automatically. After starting playback manually (with player pro) my car unit doesn't even show "unknown" for title information.
I couldn't change titles with my steering wheel keys. Logcat shows some errors and timeouts.
Last time this issue occurs I had to renew pairing at my SGS2. Perhaps foloowing logfile will help you to solve this annoying issue.
http://pastebin.com/download.php?i=RUXYW659
Today after automatic pairing with my car unit was done, audio playback doesn't start automatically. After starting playback manually (with player pro) my car unit doesn't even show "unknown" for title information.
I couldn't change titles with my steering wheel keys. Logcat shows some errors and timeouts.
Last time this issue occurs I had to renew pairing at my SGS2. Perhaps foloowing logfile will help you to solve this annoying issue.
http://pastebin.com/download.php?i=RUXYW659
RE: http://review.cyanogenmod.com/#/c/18475/ screen off packet filters
RE: http://review.cyanogenmod.com/#/c/18475/
I think I'm making some progress with decoding the filter format:
<id> <negate match 0|1> <filter type> <offset> <mask> <value>
ID - unique filter id. It looks possible that different ranges have different effects but more research is needed.
If negate match field is 0, normal processing is applied. If 1, the sense of the test is reversed (rather than the accept/drop action itself).
Filter type 0 seems to be match from the beginning of the ethernet frame. Haven't tested for any other types.
Offset is the number of bytes into the frame to begin checking the mask/value.
Mask identifies the bits of interest.
Value is what the bits of interest must be set to.
Mask and value must be the same length.
The default filters (ie pre patch) are:
100 0 0 0 0x010000000000000000000000000020 0x000000000000000000000000000000
104 0 0 0 0xFFFFFF 0x01005E
Processing logic seems to be accept on any match (where accept means the packet is permitted to the host stack when the screen is off).
So the above rules are:
id 100:
bits of interest are the first bit of the first byte of the dest eth address and the value must be 0. ie must be unicast
14 bytes further in we get to the IP header. the first nibble is the IP protocol version and the second bit must be zero which means it will never match ipv6 traffic.
summary: permit any unicast non-ipv6 traffic
id 104:
much simpler - match any frames with a dest mac 01005E, ie standard multicast frames.
Both of above decodes seem match tcpdump testing - multicast is permitted and wakes the phone, any unicast is also permitted but broadcast traffic is not.
Some of the comments in the code do not match the direction of the logic so either things have changed or the language is simply incorrect. For example, one of the filters referenced but not used in kernel/samsung/smdk4210/drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c is:
/* discard NAT Keepalive packets */
102 0 0 36 0xffffffff 0x11940009
This would mean skip past the eth and IP headers (14+20 bytes) and then go two bytes into the layer 4 header. We're matching on the following 8 bytes so, in practice this is likely to be UDP (if this were TCP it would cover the sequence number) and corresponds to the destination port (0x1194 = 4500 IPSEC NAT traversal) and udp datagram size field in bytes. The udp header is 8 bytes so this implies the packet must have a 1 byte of udp payload. So, certainly, it looks like it's matching NAT keepalives but, contrary to the comment, it would permit them not discard them.
=================================
The filter logic enables some interesting concepts like you could permit unicast udp, tcp and arp only with:
100 0 0 0 0x0100000000000000000000000000200000000000000000ff 0x000000000000000000000000000000000000000000000006
101 0 0 0 0x0100000000000000000000000000200000000000000000ff 0x000000000000000000000000000000000000000000000011
102 0 0 0 0x010000000000000000000000ffff 0x0000000000000000000000000806
I've verified this actually works (and it does. It would break IPSEC but it's interesting nonetheless..
In short, the best general purpose filter right now is probably: accept any non-IPv6 unicast.
ie
100 0 0 0 0x010000000000000000000000000020 0x000000000000000000000000000000
RE: http://review.cyanogenmod.com/#/c/18475/
I think I'm making some progress with decoding the filter format:
<id> <negate match 0|1> <filter type> <offset> <mask> <value>
ID - unique filter id. It looks possible that different ranges have different effects but more research is needed.
If negate match field is 0, normal processing is applied. If 1, the sense of the test is reversed (rather than the accept/drop action itself).
Filter type 0 seems to be match from the beginning of the ethernet frame. Haven't tested for any other types.
Offset is the number of bytes into the frame to begin checking the mask/value.
Mask identifies the bits of interest.
Value is what the bits of interest must be set to.
Mask and value must be the same length.
The default filters (ie pre patch) are:
100 0 0 0 0x010000000000000000000000000020 0x000000000000000000000000000000
104 0 0 0 0xFFFFFF 0x01005E
Processing logic seems to be accept on any match (where accept means the packet is permitted to the host stack when the screen is off).
So the above rules are:
id 100:
bits of interest are the first bit of the first byte of the dest eth address and the value must be 0. ie must be unicast
14 bytes further in we get to the IP header. the first nibble is the IP protocol version and the second bit must be zero which means it will never match ipv6 traffic.
summary: permit any unicast non-ipv6 traffic
id 104:
much simpler - match any frames with a dest mac 01005E, ie standard multicast frames.
Both of above decodes seem match tcpdump testing - multicast is permitted and wakes the phone, any unicast is also permitted but broadcast traffic is not.
Some of the comments in the code do not match the direction of the logic so either things have changed or the language is simply incorrect. For example, one of the filters referenced but not used in kernel/samsung/smdk4210/drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c is:
/* discard NAT Keepalive packets */
102 0 0 36 0xffffffff 0x11940009
This would mean skip past the eth and IP headers (14+20 bytes) and then go two bytes into the layer 4 header. We're matching on the following 8 bytes so, in practice this is likely to be UDP (if this were TCP it would cover the sequence number) and corresponds to the destination port (0x1194 = 4500 IPSEC NAT traversal) and udp datagram size field in bytes. The udp header is 8 bytes so this implies the packet must have a 1 byte of udp payload. So, certainly, it looks like it's matching NAT keepalives but, contrary to the comment, it would permit them not discard them.
=================================
The filter logic enables some interesting concepts like you could permit unicast udp, tcp and arp only with:
100 0 0 0 0x0100000000000000000000000000200000000000000000ff 0x000000000000000000000000000000000000000000000006
101 0 0 0 0x0100000000000000000000000000200000000000000000ff 0x000000000000000000000000000000000000000000000011
102 0 0 0 0x010000000000000000000000ffff 0x0000000000000000000000000806
I've verified this actually works (and it does
. It would break IPSEC but it's interesting nonetheless..In short, the best general purpose filter right now is probably: accept any non-IPv6 unicast.
ie
100 0 0 0 0x010000000000000000000000000020 0x000000000000000000000000000000
Last edited:
Do we actually want to filter out IPv6? Samsung does it in stock, but tuna does not.RE: http://review.cyanogenmod.com/#/c/18475/
I think I'm making some progress with decoding the filter format:
<id> <negate match 0|1> <filter type> <offset> <mask> <value>
ID - unique filter id. It looks possible that different ranges have different effects but more research is needed.
If negate match field is 0, normal processing is applied. If 1, the sense of the test is reversed (rather than the accept/drop action itself).
Filter type 0 seems to be match from the beginning of the ethernet frame. Haven't tested for any other types.
Offset is the number of bytes into the frame to begin checking the mask/value.
Mask identifies the bits of interest.
Value is what the bits of interest must be set to.
Mask and value must be the same length.
The default filters (ie pre patch) are:
100 0 0 0 0x010000000000000000000000000020 0x000000000000000000000000000000
104 0 0 0 0xFFFFFF 0x01005E
Processing logic seems to be accept on any match (where accept means the packet is permitted to the host stack when the screen is off).
So the above rules are:
id 100:
bits of interest are the first bit of the first byte of the dest eth address and the value must be 0. ie must be unicast
14 bytes further in we get to the IP header. the first nibble is the IP protocol version and the second bit must be zero which means it will never match ipv6 traffic.
summary: permit any unicast non-ipv6 traffic
id 104:
much simpler - match any frames with a dest mac 01005E, ie standard multicast frames.
Both of above decodes seem match tcpdump testing - multicast is permitted and wakes the phone, any unicast is also permitted but broadcast traffic is not.
Some of the comments in the code do not match the direction of the logic so either things have changed or the language is simply incorrect. For example, one of the filters referenced but not used in kernel/samsung/smdk4210/drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c is:
/* discard NAT Keepalive packets */
102 0 0 36 0xffffffff 0x11940009
This would mean skip past the eth and IP headers (14+20 bytes) and then go two bytes into the layer 4 header. We're matching on the following 8 bytes so, in practice this is likely to be UDP (if this were TCP it would cover the sequence number) and corresponds to the destination port (0x1194 = 4500 IPSEC NAT traversal) and udp datagram size field in bytes. The udp header is 8 bytes so this implies the packet must have a 1 byte of udp payload. So, certainly, it looks like it's matching NAT keepalives but, contrary to the comment, it would permit them not discard them.
=================================
The filter logic enables some interesting concepts like you could permit unicast udp, tcp and arp only with:
100 0 0 0 0x0100000000000000000000000000200000000000000000ff 0x000000000000000000000000000000000000000000000006
101 0 0 0 0x0100000000000000000000000000200000000000000000ff 0x000000000000000000000000000000000000000000000011
102 0 0 0 0x010000000000000000000000ffff 0x0000000000000000000000000806
I've verified this actually works (and it does
In short, the best general purpose filter right now is probably: accept any non-IPv6 unicast.
ie
100 0 0 0 0x010000000000000000000000000020 0x000000000000000000000000000000
Hiya,
Just was redoing my buildrig since a big crash ruined my install.
But ran into a small problem with repo sync after adding the local_manifest.xml.
So one of the first things was doing a search on XDA to look for simular problems, and first hit was this post with exactly the same errors for main.py and the others aswell, http://forum.xda-developers.com/showpost.php?p=27515521&postcount=36505
Then rememberd that when pastie.org was offline/ddossed, Codework posted the correct local_manifest.xml
So gave that on a try, and repo sync on a fresh setup started working properly again.
The only difference i can find is in the kernel part, where the one posted a while back by codeworkx has a revision="ics" and the current link in the how to build to pastebin.com misses that.
<project name="CyanogenMod/android_kernel_samsung_smdk4210" path="kernel/samsung/smdk4210" remote="github" revision="ics" />
So the question is, should revision="ics" be there or not?
Current Local_manifest.xml on pastbin.com http://pastebin.com/Xig7BtHV
Just was redoing my buildrig since a big crash ruined my install.
But ran into a small problem with repo sync after adding the local_manifest.xml.
So one of the first things was doing a search on XDA to look for simular problems, and first hit was this post with exactly the same errors for main.py and the others aswell, http://forum.xda-developers.com/showpost.php?p=27515521&postcount=36505
Then rememberd that when pastie.org was offline/ddossed, Codework posted the correct local_manifest.xml
So gave that on a try, and repo sync on a fresh setup started working properly again.
The only difference i can find is in the kernel part, where the one posted a while back by codeworkx has a revision="ics" and the current link in the how to build to pastebin.com misses that.
<project name="CyanogenMod/android_kernel_samsung_smdk4210" path="kernel/samsung/smdk4210" remote="github" revision="ics" />
So the question is, should revision="ics" be there or not?
Current Local_manifest.xml on pastbin.com http://pastebin.com/Xig7BtHV
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project name="teamhacksung/buildscripts" path="buildscripts" remote="github" revision="ics">
<copyfile dest="build.sh" src="samsung/build.sh" />
</project>
<project name="CyanogenMod/android_device_samsung_galaxys2" path="device/samsung/galaxys2" remote="github" />
<project name="CyanogenMod/android_kernel_samsung_smdk4210" path="kernel/samsung/smdk4210" remote="github" />
<project name="CyanogenMod/android_packages_apps_SamsungServiceMode" path="packages/apps/SamsungServiceMode" remote="github" />
</manifest>Hello.
I've been having this bug, so I made a patch for it.
It's a change to:
"android_frameworks_base/core/res/res/values-pt-rPT/donottranslate-cldr.xml"
and:
"android_frameworks_base/core/res/res/values-pt/donottranslate-cldr.xml"
Since I'm on Windows, I don't know how to submit it to gerrit. So I've attached the files here. If someone would be so kind as to submit them for me, I'd appreciate it.
View attachment bugfix.zip
I've been having this bug, so I made a patch for it.
It's a change to:
"android_frameworks_base/core/res/res/values-pt-rPT/donottranslate-cldr.xml"
and:
"android_frameworks_base/core/res/res/values-pt/donottranslate-cldr.xml"
Since I'm on Windows, I don't know how to submit it to gerrit. So I've attached the files here. If someone would be so kind as to submit them for me, I'd appreciate it.
View attachment bugfix.zip
I guess not since it will break any app making use of native ipv6 transport. patch reverted to your most recent upload.
---
Thinking ahead, there are some interesting possibilities I can think of:
*) allow for two independent sets of filters [**]:
i) deep sleep
ii) awake but screen off
*) create sysfs specials for configuring the filter sets
I'm imagining a world where icmp ping and tcp syn scan traffic don't wake my phone but, once the phone has woken anyway, such traffic is then allowed to pass.
More research on the filter format is needed first but I don't think the above is pie in the sky.
[**] I've seen this implemented in one dhd driver variant by using packet id < 200 for enable only during sleep and packet id>=200 for enable only when awake. sleep/resume code then just needs to walk the rules and flip them enabled/disabled depending on numeric packet id value.
Your question goes here: http://forum.xda-developers.com/showthread.php?t=1419102
The answer is here: http://teamhacksung.org/wiki/index.php/CyanogenMod9:GT-I9100:Nightly:Known_issues
codeworkx said:
Hey Guys/Devs, just found this thread about hacking proprietary libs, maybe its helpful for you, at least I learned something
http://forum.xda-developers.com/showthread.php?t=1374345
http://forum.xda-developers.com/showthread.php?t=1374345
Today, pairing SGS2 running CM9 07-06 nightly with my car unit failed repeatably. I tried to pair from my car unit, it found my sgs2 and sent request. At my SGS2 I entered the correct pairing key. But the car unit shows that the key was wrong. I tried it several times. I restarted my phone but this didn't solve this issue.
Attached is a logcat showing some errors while trying to pair.
http://pastebin.com/7vHqYHAQ
I noticed on both my SGS2 running CM9 nightlies that pairing sometimes won't work correctly and we have to re-pair.
Attached is a logcat showing some errors while trying to pair.
http://pastebin.com/7vHqYHAQ
I noticed on both my SGS2 running CM9 nightlies that pairing sometimes won't work correctly and we have to re-pair.
I just tried to sync my repo but in the last two days, I've got the following error. Is it normal?
From git://github.com/CyanogenMod/android_vendor_cm
78fdcc7..ed3e91e jellybean -> github/jellybean
error: Cannot fetch teamhacksung/android_kernel_samsung_smdk4210
error: Exited sync due to fetch errors
From git://github.com/CyanogenMod/android_vendor_cm
78fdcc7..ed3e91e jellybean -> github/jellybean
error: Cannot fetch teamhacksung/android_kernel_samsung_smdk4210
error: Exited sync due to fetch errors
@codeworkx / teamhacksung: I'd like to request you to start branch jellybean for galaxys2 (Not asking to remove the lunch combo comment, I think is the best idea for avoiding rushed devs to softbrick their phone. but it would be funny if they do), that way we can help you to start the porting to jellybean via gerrit, there are a few things that must be edited, as dependencies and so. I understand though if you want to keep it till you decide is stable or ready to merge on CM git, and do this things by yourself. At this time it may be already done, who knows, you guys work like a thunder. Patiently waiting those branches appearing anyway
You must edit your manifest file and change
teamhacksung/android_kernel_samsung_smdk4210
for
CyanogenMod/android_kernel_samsung_smdk4210
As for now it doesn't haves a jellybean branch, are you trying to fetch jellybean?
================== EDIT =====================
Seems like one cannot ask nothing here, why is this thread here then if you get this kind of answers. A simple "No, we will keep it private" would be enough.
You think I'm a noob waiting for nighlies or asking "ZOMG when CM10 will have camera working and will be stable"? come on, I was just looking to contribute to the open source I don't think is such a "Stupid question", but yes I'll go away till it's ready, I do respect other people.
You must edit your manifest file and change
teamhacksung/android_kernel_samsung_smdk4210
for
CyanogenMod/android_kernel_samsung_smdk4210
As for now it doesn't haves a jellybean branch, are you trying to fetch jellybean?
================== EDIT =====================
Seems like one cannot ask nothing here, why is this thread here then if you get this kind of answers. A simple "No, we will keep it private" would be enough.
You think I'm a noob waiting for nighlies or asking "ZOMG when CM10 will have camera working and will be stable"? come on, I was just looking to contribute to the open source I don't think is such a "Stupid question", but yes I'll go away till it's ready, I do respect other people.
Last edited:
I just did a repo sync, but there's some JB... I don't understand why.
Also your advice is worked. I think I used old manifest...
repo branches
help | in packages/apps/Settings
*p ics | in:
device/samsung/galaxys2
frameworks/base
packages/apps/Camera
packages/apps/Contacts
packages/apps/DeskClock
packages/apps/Mms
packages/apps/Phone
packages/apps/Settings
Also your advice is worked. I think I used old manifest...
repo branches
help | in packages/apps/Settings
*p ics | in:
device/samsung/galaxys2
frameworks/base
packages/apps/Camera
packages/apps/Contacts
packages/apps/DeskClock
packages/apps/Mms
packages/apps/Phone
packages/apps/Settings
@codeworkx / teamhacksung: I'd like to request you to start branch jellybean for galaxys2 (Not asking to remove the lunch combo comment, I think is the best idea for avoiding rushed devs to softbrick their phone.but it would be funny if they do), that way we can help you to start the porting to jellybean via gerrit, there are a few things that must be edited, as dependencies and so. I understand though if you want to keep it till you decide is stable or ready to merge on CM git, and do this things by yourself. At this time it may be already done, who knows, you guys work like a thunder. Patiently waiting those branches appearing anyway
You must edit your manifest file and change
teamhacksung/android_kernel_samsung_smdk4210
for
CyanogenMod/android_kernel_samsung_smdk4210
As for now it doesn't haves a jellybean branch, are you trying to fetch jellybean?
Last edited:
@codeworkx / teamhacksung: I'd like to request you to start branch jellybean for galaxys2 (Not asking to remove the lunch combo comment, I think is the best idea for avoiding rushed devs to softbrick their phone.but it would be funny if they do), that way we can help you to start the porting to jellybean via gerrit, there are a few things that must be edited, as dependencies and so. I understand though if you want to keep it till you decide is stable or ready to merge on CM git, and do this things by yourself. At this time it may be already done, who knows, you guys work like a thunder. Patiently waiting those branches appearing anyway
Code:
[email protected] ~/CM10 $ stat out/target/product/i9100/cm-10-20120711-UNOFFICIAL-i9100.zip
File: `out/target/product/i9100/cm-10-20120711-UNOFFICIAL-i9100.zip'
Size: 136018210 Blocks: 265664 IO Block: 4096 regular file
Device: 801h/2049d Inode: 1341101 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ espen) Gid: ( 1000/ espen)
Access: 2012-07-12 08:45:13.635867003 +0200
Modify: 2012-07-12 08:45:13.503869326 +0200
Change: 2012-07-12 08:45:13.503869326 +0200
Birth: -Now go away please.
Repo's will be closed until it's in a usable state.
We're still in the process of merging things together.
If you want us to make progress, stop wasting our time with stupid questions and requests.
Bugging us will result in slowed down development.
Be patient. Thank you.
We're still in the process of merging things together.
If you want us to make progress, stop wasting our time with stupid questions and requests.
Bugging us will result in slowed down development.
Be patient. Thank you.
Similar threads
- Locked
- Locked
Top Liked Posts
-
There are no posts matching your filters.
-
1284DEVELOPMENT THREAD
FOR DEVELOPERS ONLY
CyanogenMod is a free, community built, aftermarket firmware distribution of Android 4.0 (ICS), which is designed to increase performance and reliability over stock Android for your device.
Code:#include <std_disclaimer.h> /* * Your warranty is now void. * * I am not responsible for bricked devices, dead SD cards, * thermonuclear war, or you getting fired because the alarm app failed. Please * do some research if you have any concerns about features included in this ROM * before flashing it! YOU are choosing to make these modifications, and if * you point the finger at me for messing up your device, I will laugh at you. * * Submitting bug reports on nightly builds is the leading * cause of male impotence. */
CyanogenMod is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. Linked below is a package that has come from another Android project that restore the Google parts. CyanogenMod does still include various hardware-specific code, which is also slowly being open-sourced anyway.
All the source code for CyanogenMod is available in the CyanogenMod Github repo. And if you would like to contribute to CyanogenMod, please visit out Gerrit Code Review. You can also view the Changelog for a full list of changes & features.
General:
http://github.com/CyanogenMod
Device:
http://github.com/CyanogenMod/android_device_samsung_galaxys2
Kernel:
https://github.com/CyanogenMod/android_kernel_samsung_smdk4210
http://teamhacksung.org/wiki/index.php/CyanogenMod9:How_to_build
Getting Started:
http://wiki.cyanogenmod.com/wiki/Howto:_Gerrit
Example:
- cd ~/android/system
- repo start branchname CyanogenMod/android_device_samsung_galaxys2
-- Make your changes at device/samsung/galaxys2
- cd device/samsung/galaxys2
- git add -A
- git commit -a
- cd ~/android/system
- repo upload CyanogenMod/android_device_samsung_galaxys2
Navigate to http://review.cyanogenmod.com , click your commit and add codeworkx and xplodwild as reviewer.238UNOFFICIAL BUILD
http://developer.clockworkmod.com/d...e-cm-9-20120303-CODEWORKX-galaxys2-signed.zip
- fixed hw codecs (videos smooth as butter)217thread closed
WATCH THIS: http://www.youtube.com/watch?v=JmvCpR45LKA
- USE YOUR BRAIN
- READ THE FAQs
- READ THE KNOWN ISSUES
- FOLLOW THE INSTRUCTIONS
- DON'T BE LAZY
otherwise leave this thread and forum and come never back!
Edit:
Updates will be published here. We'll only do new builds if something gots fixed.
So don't expect any in the next few days. HWCodecs = headaches.165We've merged any Galaxy S II specific sourcecode into CyanogenMod mainline.
Nightly builds should happen frequently now.
Nightly builds can be found at ROM-Manager or at
http://download.cyanogenmod.com
Google Apps
Get the latest Version from: http://goo-inside.me/gapps
Device specific changelog
http://cm-nightlies.appspot.com/?device=galaxys2
