Can someone submit this [attached]? PT-Br translations of LatinIME for Volume Cursor. [res/values-pt]

[Any brazilian here agree with the translations?]

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

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

I got this weird message when doing make clean && make clobber

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?

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.

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

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

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.

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?

Originally Posted by codeworkx

correct local_manifest.xml

<?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

    <?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.

bugfix.zip