Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,808,901 Members 52,982 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
marcellocord Old
#3141  
Guest
Thanks Meter 0
Posts: n/a
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, 14 views)
 
grzesdroid
Old
#3142  
grzesdroid's Avatar
Senior Member
Thanks Meter 257
Posts: 751
Join Date: Feb 2012
Location: Jaworzyna Śląska

 
DONATE TO ME
hat is the difference between rc1, the nightly. which version is better?
 
drakester09
Old
#3143  
Senior Member
Thanks Meter 872
Posts: 1,283
Join Date: Jan 2012
Quote:
Originally Posted by grzesdroid View Post
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
Devices: Nexus 5 - Nexus 7 (2013) - OnePlus One
The Following User Says Thank You to drakester09 For This Useful Post: [ Click to Expand ]
 
golcheck
Old
#3144  
golcheck's Avatar
Senior Member
Thanks Meter 79
Posts: 416
Join Date: Jan 2010
Location: Edinburgh

 
DONATE TO ME
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?
 
mihaits
Old
#3145  
mihaits's Avatar
Senior Member
Thanks Meter 63
Posts: 106
Join Date: May 2012
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.
*insert pseudo-inspirational quote here*
 
thunderger
Old
#3146  
Senior Member
Thanks Meter 37
Posts: 222
Join Date: Jul 2011
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
 
sam3000
Old
(Last edited by sam3000; 7th July 2012 at 09:12 AM.)
#3147  
Senior Member
Thanks Meter 267
Posts: 230
Join Date: Jul 2009
Location: Seattle
Default 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
The Following 2 Users Say Thank You to sam3000 For This Useful Post: [ Click to Expand ]
 
Entropy512
Old
#3148  
Senior Recognized Developer
Thanks Meter 24,361
Posts: 13,267
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by sam3000 View Post
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.
*so much sig updating needed*

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.

Code:
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
Code:
<Entropy512> gotta be careful not to step on each other's work.  :)
<Bumble-Bee> thats true
<jerdog> compeete for donations
 
RagingHarry
Old
#3149  
RagingHarry's Avatar
Senior Member
Thanks Meter 128
Posts: 373
Join Date: Jan 2012
Location: Havelte
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 View Post
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>
One says it's a bit of a bad habbit another said it's a good quality, but I definitely got ORD.

Phone: Find7s @ OmniROM 4.4.4 [KTU84P] @ LVM-mode
Tablet Samsung TabPro 10.1 SM-t520 @ CM11
Tablet: TF300TG @ CROMBi-kk 4.4.2 [KOT49L] @ That's - F2FS - ART



Out of use:
Well they all died!!

 
c3l5o
Old
#3150  
Senior Member
Thanks Meter 10
Posts: 238
Join Date: Jun 2006
Location: Lisboa
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
device: Samsung Galaxy S II
rom: CM9 nightlies

The Following User Says Thank You to c3l5o For This Useful Post: [ Click to Expand ]
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
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes