Post Reply

[ROM][GT-I9100][4.0.4] CyanogenMod 9 nightly builds | DEVELOPMENT THREAD

OP codeworkx

marcellocord
2nd July 2012, 07:56 AM   |  #3141  
Guest
Thanks Meter: 0
 
n/a posts
Can someone submit this [attached]? PT-Br translations of LatinIME for Volume Cursor. [res/values-pt]

[Any brazilian here agree with the translations?]
Attached Files
File Type: 7z values-pt.7z - [Click for QR Code] (2.8 KB, 15 views)
3rd July 2012, 02:55 PM   |  #3142  
grzesdroid's Avatar
Senior Member
Flag Jaworzyna Śląska
Thanks Meter: 257
 
751 posts
Join Date:Joined: Feb 2012
Donate to Me
More
hat is the difference between rc1, the nightly. which version is better?
3rd July 2012, 03:06 PM   |  #3143  
Senior Member
Thanks Meter: 875
 
1,284 posts
Join Date:Joined: Jan 2012
Quote:
Originally Posted by grzesdroid

hat is the difference between rc1, the nightly. which version is better?

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
The Following User Says Thank You to drakester09 For This Useful Post: [ View ]
4th July 2012, 08:20 AM   |  #3144  
golcheck's Avatar
Senior Member
Flag Edinburgh
Thanks Meter: 79
 
416 posts
Join Date:Joined: Jan 2010
Donate to Me
More
I got this weird message when doing make clean && make clobber

Code:
Checking build tools versions...
build/core/main.mk:324: implicitly installing apns-conf_sdk.xml
rom builds fine as usual, but never got the above message. does it mean something?
4th July 2012, 06:50 PM   |  #3145  
mihaits's Avatar
Senior Member
Thanks Meter: 63
 
106 posts
Join Date:Joined: May 2012
More
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.
6th July 2012, 06:50 AM   |  #3146  
Senior Member
Thanks Meter: 37
 
222 posts
Join Date:Joined: Jul 2011
More
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
7th July 2012, 08:59 AM   |  #3147  
Senior Member
Seattle
Thanks Meter: 267
 
231 posts
Join Date:Joined: Jul 2009
More
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
Last edited by sam3000; 7th July 2012 at 09:12 AM.
The Following 2 Users Say Thank You to sam3000 For This Useful Post: [ View ]
7th July 2012, 05:07 PM   |  #3148  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 24,466
 
13,347 posts
Join Date:Joined: Aug 2007
Donate to Me
More
Quote:
Originally Posted by sam3000

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

Do we actually want to filter out IPv6? Samsung does it in stock, but tuna does not.
8th July 2012, 01:33 PM   |  #3149  
RagingHarry's Avatar
Senior Member
Flag Havelte
Thanks Meter: 129
 
376 posts
Join Date:Joined: Jan 2012
More
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/show...ostcount=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?

Quote:
Originally Posted by codeworkx

correct local_manifest.xml

Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <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" revision="ics" />
  <project name="teamhacksung/buildscripts" path="buildscripts" remote="github" revision="ics">
    <copyfile dest="build.sh" src="samsung/build.sh" />
  </project>
  <project name="CyanogenMod/android_packages_apps_SamsungServiceMode" path="packages/apps/SamsungServiceMode" remote="github" />
</manifest>
Sent from my Galaxy Nexus using XDA


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>
8th July 2012, 03:31 PM   |  #3150  
Senior Member
Flag Lisboa
Thanks Meter: 10
 
238 posts
Join Date:Joined: Jun 2006
More
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.

bugfix.zip

The Following User Says Thank You to c3l5o For This Useful Post: [ View ]
Post Reply Subscribe to Thread

Tags
alpha build, android 4.0, best sgs2 rom ever, bitte nicht stören codeworkx, cm9, cm9sgs2, development thread, epic winning, for experienced users, ics, not for user questions or discussion, schreiben sie keine scheiße, use the 'thanks' buttons - don't spam noobz0rz
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Top Threads in Galaxy S II Original Android Development by ThreadRank