I am working on an open source RTL support for Android and I need help testing...
I have attached a normal app (that should work on any Android 1.5 and up) that runs my method before calling drawText.
The purpose is to make drawText call to it so it will support BiDi.
It reads a file called /sdcard/test.txt from which it gets the test string.
It does not support newlines.
Try it and tell me what you think.
The reason I don't publish the source yet is because knowing how it works would prevent it from being tested properly.
I hope I'm putting this in the right forum...
Hebrew Supported...
Is it also, support the font for Hebrew?
Because in ver 2.1, the have Hebrew but sometimes you see square or ? signs.
TheAgent1982 said:
Is it also, support the font for Hebrew?
Because in ver 2.1, the have Hebrew but sometimes you see square or ? signs.
Click to expand...
Click to collapse
The fonts exist, there's no work necessary on them, you have to push them to the device and that's it...
biditest with Android 2.2 FroYo (FRF50) Arabic test.txt
I tested with Android 2.2 FroYo (FRF50)
without /sdcard/test.txt and with my own text
I don't know about the Hebrew, the Arabic text are not joined (re-shaped) correctly
dudyk said:
The fonts exist, there's no work necessary on them, you have to push them to the device and that's it...
Click to expand...
Click to collapse
I have TP2 running Android 2.1 .
So, any idea how to do it?
Thanks for writing an open source BiDi support.
I did a very short test:
1. It did not render the whole line of text.
2. It looks like it has problems when switching from one language to another. E.g. the closing bracket after the hebrew word is rendered as open.
I attached the original text files and screen shots.
In addition I attache a screen shot of TxtPad Light and how it is rendered there.
TheAgent1982 said:
Is it also, support the font for Hebrew?
Because in ver 2.1, the have Hebrew but sometimes you see square or ? signs.
Click to expand...
Click to collapse
This might be a problem of character encoding.
I did a test with a UTF-8 file and a Hebrew ISO 8859-8. The first rendered the letters correct but the second showed only question marks. (See picture)
As alternative keyboard I recommend using either AnySoftKeyboard or SmartKeyboard.
It is in CM-5.0.8, with a fix on the issue list.
Dear Dudy,
Will your fix work for 2.1 as well? Can you give directions how to apply it to other ROMs? I own an HTC Desire, and would love to implement the fix. So far I just have the common StaticLayout fix.
Thanks,
Ron
EDIT: More specifically, it would be great if you can tell us which files to take from the CM update with the help of baksmali and smali in order to graft them into other distros. That's the way I implanted StaticLayout.smali in MoDaCo roms.
CM 5.0.8 is 2.1. It should apply to any 2.1/2.2 rom, just take my 4 commits from CM's git from framework base repository.
dudyk said:
CM 5.0.8 is 2.1. It should apply to any 2.1/2.2 rom, just take my 4 commits from CM's git from framework base repository.
Click to expand...
Click to collapse
Thanks for the reply, Dudy. I'll be more specific about what I am trying to do: I am trying to pull the files with your patches from the CM-5.0.8 ROM without compiling anything.
With the StaticLayout fix, I used baksmali and smali to disassemble the classes.dex from framework.jar and replace StaticLayout.smali. This worked.
When I look at the page github.com/dudyk/android_frameworks_base/commit/1b0aca31c3e03a5a323276cd15a8df4203a1792c - the one with your commits (is that the right one?) I cannot figure out all the files that I would need to replace. Sorry, I am not a programmer...
I can pretty much figure out that all the files preceeded by core/java/android/ will be found with their exact names in the classes.dex from framework.jar. But I have no idea where to locate the compiled files that resulted from AndroidGraphics2D, the three Canvas files and the ResourceTypes.
If you can point me at the right direction I'll be able to convert a script that was used for the StaticLayout fix so that anyone with a Mac or Linux would be able to easily implement your fix to any none-odexed distro.
Thanks so much in advance!
you didn't add U+0600 support in your Canvas.java @ cyanogen's git
PapaDocta said:
you didn't add U+0600 support in your Canvas.java @ cyanogen's git
Click to expand...
Click to collapse
Why do you say that? I tested for U0590 to U07B1, isn't that enough?
my bad.. i don't know how i overlooked the U07B1.... it's more than enough
Dear Dudy, I really need your help.
Back in the old days (a month ago), before your wonderful work, the best fix we had was Omri Baumer's StaticLayout fix. I was able to use the baksmali and the smali utilities to extract the smali file from framework.jar of CM, and graft it into ANY phone. Another user on the iAndroid forums created a script that automated everything.
I wanted to do the same with your fix. So I compiled a vanilla 2.1 and then applied only your patches, manually, and recompiled. I used baksmali to disassemble all the framework files, and discovered that the changed files were:
android/graphics/Canvas.smali
android/graphics/Canvas$EdgeType.smali
android/graphics/Canvas$VertexMode.smali
android/text/Layout.smali
android/text/SpannableStringBuilder.smali
android/text/Styled.smali
android/widget/TextView$CharWrapper.smali
The two additional Canvas files were tagged as changed, but no textual difference is evident. So altogether we are talking about 5 files that ideally would be easily grafted into ANY device running 2.1, without recompilation.
The problem was that the new Canvas.smali file caused boot loops on my HTC Desire. Logcat caught this:
Code:
D/AndroidRuntime( 103): --- registering native functions ---
W/dalvikvm( 103): Unable to register: not native: Landroid/graphics/Canvas;.drawText (Ljava/lang/String;FFLandroid/graphics/Paint;)V
E/JNIHelp ( 103): RegisterNatives failed for 'android/graphics/Canvas'
E/AndroidRuntime( 103): Unable to register all android natives
This did NOT happen when I tried the vanilla Canvas.smali. So it must be something in your patches. If you can help me figure out how to fix this, your fix will be easily implemented into any un-odexed 2.1 device. The script is all reworked and ready... Just this problem needs ironing out.
Thanks so much - for your wonderful work, and for taking the time to read this.
Ron
ClassicalDude said:
I wanted to do the same with your fix. So I compiled a vanilla 2.1 and then applied only your patches, manually, and recompiled. I used baksmali to disassemble all the framework files, and discovered that the changed files were:
android/graphics/Canvas.smali
android/graphics/Canvas$EdgeType.smali
android/graphics/Canvas$VertexMode.smali
android/text/Layout.smali
android/text/SpannableStringBuilder.smali
android/text/Styled.smali
android/widget/TextView$CharWrapper.smali
The two additional Canvas files were tagged as changed, but no textual difference is evident. So altogether we are talking about 5 files that ideally would be easily grafted into ANY device running 2.1, without recompilation.
The problem was that the new Canvas.smali file caused boot loops on my HTC Desire. Logcat caught this:
Code:
D/AndroidRuntime( 103): --- registering native functions ---
W/dalvikvm( 103): Unable to register: not native: Landroid/graphics/Canvas;.drawText (Ljava/lang/String;FFLandroid/graphics/Paint;)V
E/JNIHelp ( 103): RegisterNatives failed for 'android/graphics/Canvas'
E/AndroidRuntime( 103): Unable to register all android natives
This did NOT happen when I tried the vanilla Canvas.smali. So it must be something in your patches. If you can help me figure out how to fix this, your fix will be easily implemented into any un-odexed 2.1 device. The script is all reworked and ready... Just this problem needs ironing out.
Thanks so much - for your wonderful work, and for taking the time to read this.
Ron
Click to expand...
Click to collapse
My changes add a native method (a C++ one) to the sources, from what I know, it is in the dex file, but maybe smali's files do not extract it, or extract it differently.
I never tried to disassemble files in android and reassemble them, so I have no idea how to help you besides describing the changes to you.
P.S.
Do you think that HebVillian is using my fix this way? I believe that I'm the first to fix this for ROMs above 2.0 (BTW, it's in the froyo branch of CM as well).
I don't know about HebVillain. The maker of the rom was made aware of the way I patched StaticLayout, so it may well be. Perhaps he also read your thread and applied the actual patches...
I noticed that in one of your commits:
http://github.com/dudyk/android_fra...0aca31c3e03a5a323276cd15a8df4203a1792c#diff-5
You added "native" to drawText. It is exactly the function in that line that is throwing the error on boot - about not being native. I tried recompiling with that particular change reversed, but it did not make a difference. Can you investigate the matter? Perhaps the way the Nexus 1 boots is different than that of other devices, and the checks are not as strict. If this is indeed a code problem, perhaps it needs to be addressed for the patch to be viable for other devices.
Take everything I say with a grain of salt - I am no programmer. Just following what I read and understand.
I have no idea if this helps, but googling the words
android registernatives
results in quite a few technical posts complaining about similar problems...
I am sorry for being a nag. But I hope I am getting closer to the source of the problem.
The Android emulator was able to boot up just fine with the patches applied. The logcat stated at the beginning of the runtime:
Code:
D/AndroidRuntime( 29): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
D/AndroidRuntime( 29): CheckJNI is ON
I/ ( 30): ServiceManager: 0xad08
D/AudioHardwareInterface( 30): setMode(NORMAL)
I/CameraService( 30): CameraService started: pid=30
The very same smali files, when applied to the HTC Desire's framework, generated the native error I quoted before. But logcat shows that the beginning of its runtime is indeed different:
Code:
D/AndroidRuntime( 197): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
D/AndroidRuntime( 197): CheckJNI is OFF
D/dalvikvm( 197): Precise GC configured ON
D/dalvikvm( 197): creating instr width table
I/dalvikvm( 197): mlock: /data/dalvik-cache/[email protected]@[email protected], fd=7
So - how do we make the Desire, or any other device, turn on CheckJNI and turn off precise GC?
EDIT: In one of CM's change logs it was written that Precise GC was turned off because of its memory consumption. I am just assuming that this is indeed the cause for my problems. How can we check it?
CheckJNI and Precise GC don't matter.
Repatched and recompiled 2.2 source. The emulator runs beautifully with or without JNI checks. My HTC desire, with a 2.2 rom, still complains about the same function not being native.
The port dudyk did to Omri Baumer's patch works partially - the numbers are not reversed, but the whole line is aligned to the left (with hebrew text appearing to the left of the number, instead of the right).
I have no idea what else to do or to check.
i tried the latest cm6 nightly build and still it won't align Arabic RTL correctly.. it aligns it as LTR and there no reshaping as well....
Related
I have been following the Android scene here pretty regularly but the os I have always really wanted is a full fledged Linux. I heard about, and wanted a N900 because of Maemo but I'm too poor to buy one . I then heard about the Mer project https://wiki.maemo.org/Mer to port Maemo to other devices and saw it booted on the kaiser http://forum.xda-developers.com/showthread.php?t=565480. On page two of that thread it is stated that someone (Mdrobnak) got it up and running pretty well on his Fuze with a couple tweaks to Xorg.conf, the kernel, and to the splash screen (resized to 640x480). I've been working over the past few days on getting it to start on my fuze but haret keeps giving errors about pc_clk_disable. I resized the splash, changed Xorg.conf to be 640x480 and did the rest of the directions on the Kaiser thread, but no luck. I would love to get a port of this going, as being able to use ~95% of Ubuntu packages working on my phone would be awesome. I wasn't quite sure how to patch the kernel; that would be the zImage, right? Any suggestions?
I'm going to be on #mer and #htc-linux irc on freenode quite a bit until we get this working well if anyone wants to discuss things, not that I can contribute much.
Would it be possible to create a rootfs.img file similar to how XDANDROID does it for people too lazy to partition their card or just plain suck like me?
Sounds interesting! Keep us updated!
Oh god! Ill be in 7th heaven if it's going to be done!
I think you can use the zImage of xdandroid, maybe it'll work
I tried the xdandroid zImage but it didn't work. This is really a call for help. I really don't know what I am doing, lol. I'm not even close to being a dev. Try out the steps on the Kaiser thread but use the stable 0.16 distribution as the testing links don't work. See if you can figure anything out.
Maemo on the Raph ? that would be great! maybe we could run it in dual boot with android and abandon WM for ever !
To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)
phhusson said:
To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)
Click to expand...
Click to collapse
Thanks, phh. Will try it when I get home.
that's the old and ugly msm_fb refresh hack.
I will update here once I have xorg working on kovsky and kaiser.
Man, I actually feel like this is getting places. Got Phhusson from XDANDROID and dcordes from the original Android on Diamond thread. Quite the star power.
@dcordes: What needs to be edited to use VGA; just the first screen resolution dimensions in Xorg.conf?
what image are you using?
I'm using the Smartq5 from here: http://wiki.maemo.org/Mer/Releases/0.16. My main problem is with the kernel though I think; haret hangs after about 15 seconds; I'm gonna create a log of it.
On my Raph300 I can login on the terminal using the Q5 image. I was using the latest zimage from gelmsom. But kernel is screaming some stuff a bout a clock not having an ena bit and something about an rpcrouter being blocked. When I try to start X, I get an error loading libpicacces.so.0
I get that same error, but Haret hangs when I get it. Please share what you did: e.g. editing xorg, exact zImage used, what you used to partition, your default.txt, whether you edited the splash screen image etc. I'd like to get a database of sorts of people's configurations. Good to know though. Did you add Phhusson's tip to default.txt?
"To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)"
Yes i added the msm_fb.fix_x=1 to the cmdline. Unfortunatly it is not the solution for this problem. We have got some trouble with the libraries. Maybe something is missing.
LordKiwi said:
Yes i added the msm_fb.fix_x=1 to the cmdline. Unfortunatly it is not the solution for this problem. We have got some trouble with the libraries. Maybe something is missing.
Click to expand...
Click to collapse
Last time I tried it worked automatically (I mean for X video output.) with msm_fb.fix_x=1
Sorry it works. JesusFreak and I extracted the tar file the wrong way.
I should have type tar -pxvf. I forgot the p which is very important.
Now it stops with a different error.
Code:
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.6.0, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Dang it; I just can't get it to work. I'm the thread starter and I can't do it, lol. Here's what I did:
1. Downloaded 0.16 stable smartq5 rootfs.
2. Extracted the tar to my home folder. (Now that I think of it; I did it with archive manager not the command line, so no -p setting or anything. That could be the problem.)
3. Edited the xorg.conf file to change the resolution to 640x480.
4. Changed the splash screen size to 640x480.
5. Formatted my sd card to ext2 for 1.5 gb and fat32 for .5 gb using command line following these directions for ext2: http://wiki.maemo.org/Mer/Documentation/SmartQ_Installation_for_the_Windows_user and gparted for fat32.
6. I then used the directions on the same pagee as before to copy the file, except using cp instead of mv.
7. I copied haret, a zImage, and the startup.txt that I renamed to default.txt and edited to the fat32 partition.
8. I started Haret.
I attached my default.txt.
The formatting is done correct. You should try to use the tar command line wich you can find on the same page. It should solve the problem of loading the library.
•Type sudo tar -pxzvf *.gz and press return. This will now untar the entire 'rootfs' to the card. (Install Mer).
LordKiwi said:
Sorry it works. JesusFreak and I extracted the tar file the wrong way.
I should have type tar -pxvf. I forgot the p which is very important.
Now it stops with a different error.
Code:
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.6.0, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Click to expand...
Click to collapse
I'm an idiot....... I saved my startup.txt as startup.doc. That's why X didn't start.
0.17 release
Is possible run the 0.17 realease in raphael more fast than in N810?
Hello. I have the latest Android SDK and Eclipse w/ADT set up on my Ubuntu 10.10 box. I have tried many examples and wrote my own practice apps. Everything so far has worked well!
My goal is to modify the stock MMS app so that I can modify the Delete functionality to require a pin or password. This will help keep my 11 and 13 year old children's texting clean and under control. (yes, I understand that they could install another MMS app, but thats something I can watch for too)
I'm a well seasoned programmer (c/c++/php/bash) and I'm just learning java/Android API. I thought this project would be a great place to start...
My problem is, I can't build the mms app at all. I have used git to download the approriate sources:
Code:
[email protected]sktop:~/dev$ git clone git://android.git.kernel.org/platform/packages/apps/Mms.git
I then created a new workspace in Eclipse, and created a new Android project, where I imported from existing source. In the "problems" tab in Eclipse, I get:
Code:
1,464 errors, 112 warnings, 0 others (filter matched 200 of 1576 items)
Errors (100 of 1464 items)
Description Resource Path Location Type
AcknowledgeInd cannot be resolved to a type RetrieveTransaction.java /ConversationList/src/com/android/mms/transaction line 222 Java Problem
Description Resource Path Location Type
AcknowledgeInd cannot be resolved to a type RetrieveTransaction.java /ConversationList/src/com/android/mms/transaction line 222 Java Problem
...
...
Description Resource Path Location Type
Addr cannot be resolved AddressUtils.java /ConversationList/src/com/android/mms/util line 47 Java Problem
...
...
Description Resource Path Location Type
ArrayListCursor cannot be resolved to a type RecipientsAdapter.java /ConversationList/src/com/android/mms/ui line 208 Java Problem
...
...
etc
Basically tons of errors. Its almost like an include path isn't set properly somewhere.
Can anybody help me to get this to compile, then I can begin modifying and testing my changes!
thanks!
I think you'll need a good portion of the AOSP source tree to get all the base framework stuff needed to compile this.
Ok thanks, pulling down the AOSP tree now. I'll retry once its pulled down and report back here if I have more problems
Compile Mms Eclair AOSP using Eclipse
hello to all,
can anyone point me how to edit/compile a 'default/vanilla' mms app of AOSP using Eclipse?
I'm currently using ubuntu 10.04 with the with android sdk's for Eclair and Froyo and I was trying to compile the Eclair Mms
************ UPDATE *****************
update.zip flashable for DSC and DSC PDroid can be found at
openssl 1.0.1e update for DSC/407
*****************************************
Hello,
you may have heard of the badly choosen default ssl ciphers (1) in gingerbread.
Gingerbread devices use outdated encryption algorithms for ssl communication.
That problem effects also gingerbread based roms like 407 or dsc. You can check this by sending
your default browser (or for example nakedbrowser) to a ssl browser test-server (2)
You will get a result like in attachment 1 ciphers_original: We are using the RC4-SHA without perfect forward secrecy. That is problematic cause of the Lucky 13 attack agains this encryption (3)
With some patch in core.jar in our framework (attachment ciphers_reorder.patch) I got DHE-RSA-AES128-SHA which is considered more secure and also supports perfect forward secrecy. (attachment ciphers_pfs)
You can get my core.jar from http://ge.tt/api/1/files/1MKLbUv/0/blob?download. Install it into /system/framework and rebuild your dalvik-cache.
I can't support TLSv1.1 or TLSv1.2 yet, because it would need to recompile a more recent version of libssl.so.
Users of Opera get even DHE-RSA-AES256-SHA in their connection (attachment ciphers_opera) which is considered state-of-the art cryptography. But even than, other android apps will use the badly choosen systems default. So it is a good idea even for opera
users, to update core.jar.
Can please someone confirm my findings, and install core.jar in a 407 or dsc rom and check your browser on (2)
(1) http://op-co.de/blog/posts/android_ssl_downgrade/
(2) https://cc.dcsec.uni-hannover.de/
(3) http://www.isg.rhul.ac.uk/tls/Lucky13.html
@hunderteins,
Thanks for the post.
I am on currently BB407, PCM ROM. Should I do this too?
How is it, which one to choose? Copy your given "core.jar" and paste to "/system/framework" and rebuild your dalvik-cache... OR flash " ciphers_reorder.patch" ?
Ops, sorry I don't know how to handle file.patch... how is it?
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.
Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM
Razak RK said:
I am on currently BB407, PCM ROM. Should I do this too?
Click to expand...
Click to collapse
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example
Code:
$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar
If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).
If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.
Razak RK said:
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.
Click to expand...
Click to collapse
Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.
There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'
Good luck,
hunderteins
Thank you Hunderteins!
How about kernel 3.0?
Are you still working on it?
Regards...
hunderteins said:
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example
Code:
$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar
If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).
If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.
Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.
There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'
Good luck,
hunderteins
Click to expand...
Click to collapse
~•~•~•~•~
@hunderteins,
Thank you for your reply.
Here is the checksum I get when I run in Terminal Emulator:-
$ export PATH=/data/local/bin:$PATH
$sha1sum /system/framework/core.jar
1291fcce44f4be036e2209ccb46d3313b65bdfdc /system/framework/core.jar
$md5sum /system/framework/core.jar
19bd48b8eac1bb123a823d039415a344 /system/framework/core.jar
$
So, they are NOT the same.
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.
As for Firefox mobile on my Streak PCM7, I have check the menu and settings, here is NO option as per you mention.
Reason I'm interested to know is to set my Streak at best.
BTW, I'm currently installing and testing all the Streak Custom ROMs in XDA, trying to find a ROM that would probably best for my daily use = Performance+Save Power+Other Features. I probably end up having to learn to mix some ROMs into my own personal use...if I got the time to do it though...
Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM
Razak RK said:
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.
Click to expand...
Click to collapse
basically you need http://code.google.com/p/smali/downloads/list
a good tutorial how the framework is decompiled/updated can be found at
http://forum.xda-developers.com/showthread.php?t=1084850
for how to apply a patch to a source-file consult the manpage of patch
back to topic. I updated core.jar http://ge.tt/api/1/files/7F3UKbv/0/blob?download
Now DHE-RSA-AES256-SHA is included in the list of useable ciphers.
This way in stockbrowser/nakedbrowser the same encrpytion is used as in opera/firefox
look into attached image.
Patch is also included for thoose who find it useful.
Have a nice weekend,
hunderteins
sinan33 said:
How about kernel 3.0?
Are you still working on it?
Click to expand...
Click to collapse
didn't post in that thread, did I?
hunderteins said:
didn't post in that thread, did I?
Click to expand...
Click to collapse
Sorry dude; just eagerness
Confirmed working on Traveller DSC. ROM updates will be coming shortly.
Flashable zip for core.jar patch suitable for DSC and Traveller DSC: MediaFire | Mega
Elliptic curve Diffie–Hellman Key exchange
Hello,
the libssl 1.0.0a on the streak supports elliptic curve Diffie–Hellman key exchange.
With the right server, this speeds up https compared to normal Diffie–Hellman key exchange.
So I had to change the core.jar again to support these cyphers.
With this update I removed the know weak ciphers (export, 56bit etc)
I attached a openssl command for the commandline, to check libssl.so for features. It might
be useful elsewhere.
Have fun,
hunderteins
TLSv1.1 and TLSv1.2 protocol
Hello,
SSLv3/TLSv1.0 are known to be problematic with stream ciphers (the cbc ones) and
as mentioned before, I had to compiled a more recent version of libssl to support
the modern TLS variants.
Attached are the openssl binary and the libssl.so and libcrypto.so of openssl 1.0.1e.
They work on my streak and I get a clean https TLSv1.2 connection to the testserver.
Next step is, to modify core.jar again to get the modern GCM streaming methods
and SHA384 hashes.
Have a nice evening,
hunderteins
GCM streaming, sha384 hashes and server name indication (SNI)
Hello,
as mentioned before, I modified core.jar to match the ciphers from libssl 1.01e. So we get modern ciphers like ECDHE-RSA-AES256-GCM-SHA384 which are considered strong cryptographie. That's even more recent than Android 4.4 KitKat.
But Android Gingerbread has another serious flaw: SNI (server name indication) is not supported with Apache Http Client. Google fixed this *tada* in Honeycomb.
I looked into that problem, but we have to change framework.jar for that, too.
I attached the patches against the backsmalied core.jar and framework.jar. Together with openssl 1.0.1e I get a very beautiful https connection to the testservers (attached screenshots): ECDHE-RSA-AES256-GCM-SHA384 with TLS V1.2 and SNI - in stock android 2.3 browser.
Please confirm my findings. I'll try to make an streakmod compatible update.zip to spread that little security to the masses. If you point me to your core.jar/framework.jar I will consider to integrate your rom into that update.zip.
Have fun,
hunderteins
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?
BTW, the PDroid version is working perfectly.
Strephon Alkhalikoi said:
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?
BTW, the PDroid version is working perfectly.
Click to expand...
Click to collapse
Thank you for your feedback.
Update.zip deploys openssl 1.0.1e into /system/lib and /system/bin. It replaces classes.dex inside framework.jar and core.jar when the sha1_check is correct. That is mostly like replacing the files itself, because classes.dex is the main ingredient.
An elegant way would be to baksmali/smali on the device itself, but that didn't work because of memory constraint.
have fun,
hunderteins
openssl 1.0.1g for android 2.3
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.
Good luck,
hunderteins
[1] http://heartbleed.com/
hunderteins said:
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.
Good luck,
hunderteins
[1] http://heartbleed.com/
Click to expand...
Click to collapse
I'll make a flashable zip for this shortly as well as release an update to Traveller DSC.
hunderteins said:
you may have heard of the heartbleed bug before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected.
Click to expand...
Click to collapse
I stand corrected. The 1.0.1e version was build with -DOPENSSL_NO_HEARTBEATS. So it was not affected at all. Tested it with the stock browser and naked browser against pacemaker [1].
Anyway, 1.0.1g is not affected, too.
warning: Stock browser on Android 4.1.1 is affected.
[1] https://github.com/Lekensteyn/pacemaker
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?
Strephon Alkhalikoi said:
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?
Click to expand...
Click to collapse
I don't think so. As of today in 1.0.1-versions of openssl there are only bugfixes. New, improved features are in 1.0.2. [1]
The changelog between 1.0.1e and 1.0.1g shows detailed bugfixes:
Code:
Changes between 1.0.1f and 1.0.1g [7 Apr 2014]
*) A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <[email protected]> and Bodo Moeller <[email protected]> for
preparing the fix (CVE-2014-0160)
[Adam Langley, Bodo Moeller]
*) Fix for the attack described in the paper "Recovering OpenSSL
ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
by Yuval Yarom and Naomi Benger. Details can be obtained from:
http://eprint.iacr.org/2014/140
Thanks to Yuval Yarom and Naomi Benger for discovering this
flaw and to Yuval Yarom for supplying a fix (CVE-2014-0076)
[Yuval Yarom and Naomi Benger]
*) TLS pad extension: draft-agl-tls-padding-03
Workaround for the "TLS hang bug" (see FAQ and PR#2771): if the
TLS client Hello record length value would otherwise be > 255 and
less that 512 pad with a dummy extension containing zeroes so it
is at least 512 bytes long.
[Adam Langley, Steve Henson]
Changes between 1.0.1e and 1.0.1f [6 Jan 2014]
*) Fix for TLS record tampering bug. A carefully crafted invalid
handshake could crash OpenSSL with a NULL pointer exception.
Thanks to Anton Johansson for reporting this issues.
(CVE-2013-4353)
*) Keep original DTLS digest and encryption contexts in retransmission
structures so we can use the previous session parameters if they need
to be resent. (CVE-2013-6450)
[Steve Henson]
*) Add option SSL_OP_SAFARI_ECDHE_ECDSA_BUG (part of SSL_OP_ALL) which
avoids preferring ECDHE-ECDSA ciphers when the client appears to be
Safari on OS X. Safari on OS X 10.8..10.8.3 advertises support for
several ECDHE-ECDSA ciphers, but fails to negotiate them. The bug
is fixed in OS X 10.8.4, but Apple have ruled out both hot fixing
10.8..10.8.3 and forcing users to upgrade to 10.8.4 or newer.
[Rob Stradling, Adam Langley]
It is sad, that on regular android devices, these bugfixes never see the light. Basically you can take these known bugs and rig most of the android 4.x devices.
reg. hunderteins
[1] http://www.openssl.org/news/changelog.html
Regardless, it's not a bad thing to have the latest version.
I need to rebuild libmedia.so from CM10.1 because I want to make some minor modifications for reasons I won't go into detail here because that's a whole other story. I've researched online and it seems I need to use repo sync (http://wiki.cyanogenmod.org/w/Build_for_p990) I tried doing that to get the android source the other day but stopped after 20 min when I realised the entire source tree is around a gigantic 8-10GB. This is bad as I live in Australia where every MB counts and I'm only on a 30GB/month plan!
Which brings me to my first quesiton, how big is the CM 10.1 source tree?
If not too big, I might be able to download it all, but I really only need to rebuild libmedia.so (https://github.com/CyanogenMod/android_frameworks_av/tree/cm-10.2/media/libmedia) and I think I'll need the source for it's dependencies (from my limited understanding about shared libs). Using arm-eabi-ld with rpath option, I was able to find the dependencies required which are
Code:
libaudioutils.so libgccdemangle.so libspeexresampler.so
libbinder.so libGLES_trace.so libstagefright_foundation.so
libcamera_client.so libGLESv2.so libstdc++.so
libcorkscrew.so libgui.so libstlport.so
libc.so libhardware.so libsync.so
libcutils.so libicuuc.so libui.so
libdl.so liblog.so libutils.so
libEGL.so libmedia_native.so libz.so
libexpat.so libm.so
libgabi++.so libsonivox.so
My second question is how do I go about downloading the minimal amount in order to successfully rebuild libmedia.so? This post tends to suggest it is possible, but I don't know where this manifest is, or how to edit it for my own purposes.
Can the mods move this to the Android Software and Hacking General [Developers Only] forum? I think it would be more relevant there as this is more a dev question than a general one. Or should I just delete this and repost there?
Hello there! I'm new to these parts because I recently acquired a Gear Fit.
TL;DR: I took aooga's stuff (thanks!) and made it work on my CM 12 (5.0.2) phone. I hope it works for you. Get it here.
Anyway, I'm using a Galaxy Nexus running a cm 12 build from Ziyan, and I quickly realized that I needed to do some extra work. Unfortunately, zwegnet's patched Gear Fit Manager didn't work for me, and neither did aooga's very comprehensive guide, so I figured I'd try doing it myself. I see that some of you are interested in how this works, so I'm documenting my process for everyone's benefit (let's collaborate!).
You will learn the basics of:
how to debug using adb logcat
how to disassemble an app (specifically, a dex file) into smali
how to navigate and modify smali code
how to reassemble smali to dex and rebuild the app
how to sign an app for deployment
You will need:
adb
java runtime environment
smali/baksmali
signapk with test keys
I've collected some of the tools for you here; just add adb and java.
1. Debugging
So, we've got Gear Fit Manager and Gear Fitness installed... but Gear Fit Manager crashes! Darn it. How are we gonna connect a Gear Fit? Let's see.
First, let's pop open your favorite terminal (yes, we will be using the command line) and start streaming some logs:
Code:
adb logcat
There should be a bunch of text scrolling through the terminal. While that's going on, try to launch the offending app, and wait until it crashes. As soon as it crashes, hit Ctrl+C in the terminal to stop logging. Look, a fatal exception:
Code:
E/AndroidRuntime(32368): FATAL EXCEPTION: main
E/AndroidRuntime(32368): Process: com.samsung.android.wms, PID: 32368
E/AndroidRuntime(32368): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.samsung.android.wms/com.samsung.android.wms.app.base.ContentsActivity}: android.content.res.Resources$NotFoundException: Resource ID #0x0
E/AndroidRuntime(32368): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2298)
E/AndroidRuntime(32368): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2360)
E/AndroidRuntime(32368): at android.app.ActivityThread.access$800(ActivityThread.java:144)
E/AndroidRuntime(32368): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
E/AndroidRuntime(32368): at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(32368): at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(32368): at android.app.ActivityThread.main(ActivityThread.java:5223)
E/AndroidRuntime(32368): at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(32368): at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime(32368): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
E/AndroidRuntime(32368): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)
E/AndroidRuntime(32368): Caused by: android.content.res.Resources$NotFoundException: Resource ID #0x0
E/AndroidRuntime(32368): at android.content.res.Resources.getValue(Resources.java:1233)
E/AndroidRuntime(32368): at android.content.res.Resources.getDrawable(Resources.java:756)
E/AndroidRuntime(32368): at android.content.res.Resources.getDrawable(Resources.java:724)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.brandGlowEffect(WingtipBaseActivity.java:136)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.onCreate(WingtipBaseActivity.java:94)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.ContentsActivity.onCreate(ContentsActivity.java:139)
E/AndroidRuntime(32368): at android.app.Activity.performCreate(Activity.java:5933)
E/AndroidRuntime(32368): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
E/AndroidRuntime(32368): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2251)
E/AndroidRuntime(32368): ... 10 more
When you've been bug-hunting for a while, you start to notice these stack traces quite readily, even in a sea of irrelevant output. This one tells us that:
the offending app is named com.samsung.android.wms
a Resources$NotFoundException occurred, likely because the app requested a resource that did not exist
... and so on
Note that the stack trace appears in reverse-chronological order; that is, what happens later appears first. I often like to read these things backwards. Now, have a look at these lines:
Code:
E/AndroidRuntime(32368): at android.content.res.Resources.getDrawable(Resources.java:724)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.brandGlowEffect(WingtipBaseActivity.java:136)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.onCreate(WingtipBaseActivity.java:94)
What happened?
a WingtipBaseActivity is created to display the app, and is being initialized in its onCreate method
... which calls brandGlowEffect
... which calls into the Android system
... which eventually leads to the crash
With the entire chain of events exposed to us, we could now look for the culprit! Why don't we examine WingtipBaseActivity.brandGlowEffect? It's the last thing the app does before passing control over to Android, and we're assuming that the app (not Android) is faulty.
2. Disassembly
To do this, we need to take a peek under Gear Fit Manager's hood. An apk file is just a zip file, so we already know how to unpack it. We're interested in the classes.dex within, which contains the executable code. dex is not a very human-readable format, so we need to disassemble it using baksmali.
Firstly, let's extract the classes.dex from the archive. Then, we could disassemble it by running:
Code:
java -jar baksmali.jar -o dexout classes.dex
3. Modification
This generates a folder full of disassembled code. Because we're interested in com.samsung.android.wms.app.base.WingtipBaseActivity, we'll look inside the file dexout/com/samsung/android/wms/app/base/WingtipBaseActivity.smali
There, on line 693, we see the method WingtipBaseActivity.brandGlowEffect getting called from WingtipBaseActivity.onCreate. This looks like some cosmetic fluff that we could dispense with, so let's just delete the line altogether and save the file. Sorry, Samsung, your brand's not gonna glow this time.
4. Reassembly
Now we could re-generate the classes.dex:
Code:
java -jar smali.jar -o classes.dex dexout
... and we'll drop the new classes.dex inside the apk.
5. Signing
But wait! We couldn't install this new apk yet — it needs to be signed. This is easy enough with signapk:
Code:
java -jar signapk.jar testkey.x509.pem testkey.pk8 GearFitManager.apk GearFitManager_signed.apk
6. Deploying
We need to uninstall the original app before we could install the new one, because they were signed using different keys (the original was signed using Samsung's keys). After that, we just need to install and test!
We've barely scratched the surface. I hope this helps someone, and I certainly hope we could team up to make something awesome. I've had a look at the more recent versions of Gear Fit Manager, and I have a feeling a lot more work would be required...
Just when I was about to give up , I found this thread . Thank you so much .
The app finally doesn't crash . But it doesn't seem to be connecting with the Fitness app .
Running Nexus 4 with CyanogenMod 12 , v5.0.2 .
[DIY][CM 12][Android 5.0] Gear Fit on Non-Samsung Devices with Lollipop
Hello there! I'm new to these parts because I recently acquired a Gear Fit.
TL;DR: I took aooga's stuff (thanks!) and made it work on my CM 12 (5.0.2) phone. I hope it works for you. Get it here.
Anyway, I'm using a Galaxy Nexus running a cm 12 build from Ziyan, and I quickly realized that I needed to do some extra work. Unfortunately, zwegnet's patched Gear Fit Manager didn't work for me, and neither did aooga's very comprehensive guide, so I figured I'd try doing it myself. I see that some of you are interested in how this works, so I'm documenting my process for everyone's benefit (let's collaborate!).
You will learn the basics of:
1.how to debug using adb logcat
2.how to disassemble an app (specifically, a dex file) into smali
3.how to navigate and modify smali code
4.how to reassemble smali to dex and rebuild the app
5.how to sign an app for deployment
You will need:
•adb
•java runtime environment
•smali/baksmali
•signapk with test keys
I've collected some of the tools for you here; just add adb and java.
1. Debugging
So, we've got Gear Fit Manager and Gear Fitness installed... but Gear Fit Manager crashes! Darn it. How are we gonna connect a Gear Fit? Let's see.
First, let's pop open your favorite terminal (yes, we will be using the command line) and start streaming some logs:
Code:
adb logcat
There should be a bunch of text scrolling through the terminal. While that's going on, try to launch the offending app, and wait until it crashes. As soon as it crashes, hit Ctrl+C in the terminal to stop logging. Look, a fatal exception:
Code:
E/AndroidRuntime(32368): FATAL EXCEPTION: main
E/AndroidRuntime(32368): Process: com.samsung.android.wms, PID: 32368
E/AndroidRuntime(32368): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.samsung.android.wms/com.samsung.android.wms.app.base.ContentsActivity}: android.content.res.Resources$NotFoundException: Resource ID #0x0
E/AndroidRuntime(32368): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2298)
E/AndroidRuntime(32368): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2360)
E/AndroidRuntime(32368): at android.app.ActivityThread.access$800(ActivityThread.java:144)
E/AndroidRuntime(32368): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
E/AndroidRuntime(32368): at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(32368): at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(32368): at android.app.ActivityThread.main(ActivityThread.java:5223)
E/AndroidRuntime(32368): at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(32368): at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime(32368): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
E/AndroidRuntime(32368): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)
E/AndroidRuntime(32368): Caused by: android.content.res.Resources$NotFoundException: Resource ID #0x0
E/AndroidRuntime(32368): at android.content.res.Resources.getValue(Resources.java:1233)
E/AndroidRuntime(32368): at android.content.res.Resources.getDrawable(Resources.java:756)
E/AndroidRuntime(32368): at android.content.res.Resources.getDrawable(Resources.java:724)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.brandGlowEffect(WingtipBaseActivity.java:136)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.onCreate(WingtipBaseActivity.java:94)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.ContentsActivity.onCreate(ContentsActivity.java:139)
E/AndroidRuntime(32368): at android.app.Activity.performCreate(Activity.java:5933)
E/AndroidRuntime(32368): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
E/AndroidRuntime(32368): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2251)
E/AndroidRuntime(32368): ... 10 more
When you've been bug-hunting for a while, you start to notice these stack traces quite readily, even in a sea of irrelevant output. This one tells us that:
•the offending app is named com.samsung.android.wms
•a Resources$NotFoundException occurred, likely because the app requested a resource that did not exist
•... and so on
Note that the stack trace appears in reverse-chronological order; that is, what happens later appears first. I often like to read these things backwards. Now, have a look at these lines:
Code:
E/AndroidRuntime(32368): at android.content.res.Resources.getDrawable(Resources.java:724)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.brandGlowEffect(WingtipBaseActivity.java:136)
E/AndroidRuntime(32368): at com.samsung.android.wms.app.base.WingtipBaseActivity.onCreate(WingtipBaseActivity.java:94)
What happened?
1.a WingtipBaseActivity is created to display the app, and is being initialized in its onCreate method
2.... which calls brandGlowEffect
3.... which calls into the Android system
4.... which eventually leads to the crash
With the entire chain of events exposed to us, we could now look for the culprit! Why don't we examine WingtipBaseActivity.brandGlowEffect? It's the last thing the app does before passing control over to Android, and we're assuming that the app (not Android) is faulty.
2. Disassembly
To do this, we need to take a peek under Gear Fit Manager's hood. An apk file is just a zip file, so we already know how to unpack it. We're interested in the classes.dex within, which contains the executable code. dex is not a very human-readable format, so we need to disassemble it using baksmali.
Firstly, let's extract the classes.dex from the archive. Then, we could disassemble it by running:
Code:
java -jar baksmali.jar -o dexout classes.dex
3. Modification
This generates a folder full of disassembled code. Because we're interested in com.samsung.android.wms.app.base.WingtipBaseActivi ty, we'll look inside the file dexout/com/samsung/android/wms/app/base/WingtipBaseActivity.smali
There, on line 693, we see the method WingtipBaseActivity.brandGlowEffect getting called from WingtipBaseActivity.onCreate. This looks like some cosmetic fluff that we could dispense with, so let's just delete the line altogether and save the file. Sorry, Samsung, your brand's not gonna glow this time.
4. Reassembly
Now we could re-generate the classes.dex:
Code:
java -jar smali.jar -o classes.dex dexout
... and we'll drop the new classes.dex inside the apk.
5. Signing
But wait! We couldn't install this new apk yet — it needs to be signed. This is easy enough with signapk:
Code:
java -jar signapk.jar testkey.x509.pem testkey.pk8 GearFitManager.apk GearFitManager_signed.apk
6. Deploying
We need to uninstall the original app before we could install the new one, because they were signed using different keys (the original was signed using Samsung's keys). After that, we just need to install and test!
We've barely scratched the surface. I hope this helps someone, and I certainly hope we could team up to make something awesome. I've had a look at the more recent versions of Gear Fit Manager, and I have a feeling a lot more work would be required...
Click to expand...
Click to collapse
Very good explanation.
Thanks to you I was able to path version 1.98 and it works the media control, I can upload new watches styles using Watch Styler for Fit.
What doesn't work is the App connect. All applications say that I have to install Gear Manager Fit first.
It's working on my Nexus 4 with 5.0.1. I also updated the gear fit to the last firmware and it connects perfectly.
I attach it.
Help
bronxgsi said:
Very good explanation.
Thanks to you I was able to path version 1.98 and it works the media control, I can upload new watches styles using Watch Styler for Fit.
What doesn't work is the App connect. All applications say that I have to install Gear Manager Fit first.
It's working on my Nexus 4 with 5.0.1. I also updated the gear fit to the last firmware and it connects perfectly.
I attach it.
Click to expand...
Click to collapse
I installed the zip by renaming it as an apk but when I try to pair it give the same confirmation but doesn't finish pairing please help... I have Nexus 5 it has stock 5.0.1 rooted as well.
I haven't been able to sync the Fitness with Gear app either, even with Samsung Account installed per Virnik0's recommendation.
I believe this stack trace is relevant:
Code:
D/SessionInputStream(29439): move remain data to first index / mTotalDataLength : 83 mTotalReceivedLength : 88
W/SessionManager(29439): notifyDataReceived port : 2
I/SessionManager(29439): mBinderMap.get action:com.samsung.android.wms.communication.session_manager_for_interanalbinder:115174198
I/SessionManager(29439): listener.onDataReceived is called
V/DataExchangeManager(29439): SessionManagerEventListener onDataReceived
W/DataExchangeManager(29439): From : HEALTH, Attempt to invoke interface method 'void com.samsung.android.wms.service.communication.DataExchangeManager$OnDataReceivedListener.onDataReceived(com.samsung.android.wms.service.communication.WingtipApp, byte[])' on a null object reference
W/DataExchangeManager(29439): java.lang.NullPointerException: Attempt to invoke interface method 'void com.samsung.android.wms.service.communication.DataExchangeManager$OnDataReceivedListener.onDataReceived(com.samsung.android.wms.service.communication.WingtipApp, byte[])' on a null object reference
W/DataExchangeManager(29439): at com.samsung.android.wms.service.communication.DataExchangeManager$InternalHandler.handleMessage(DataExchangeManager.java:126)
W/DataExchangeManager(29439): at android.os.Handler.dispatchMessage(Handler.java:102)
W/DataExchangeManager(29439): at android.os.Looper.loop(Looper.java:135)
W/DataExchangeManager(29439): at android.app.ActivityThread.main(ActivityThread.java:5223)
W/DataExchangeManager(29439): at java.lang.reflect.Method.invoke(Native Method)
W/DataExchangeManager(29439): at java.lang.reflect.Method.invoke(Method.java:372)
W/DataExchangeManager(29439): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
W/DataExchangeManager(29439): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)
It seems that it actually connected to Samsung's servers, but had some trouble handling the response. I'll investigate this sometime...
will1549 said:
I installed the zip by renaming it as an apk but when I try to pair it give the same confirmation but doesn't finish pairing please help... I have Nexus 5 it has stock 5.0.1 rooted as well.
Click to expand...
Click to collapse
Same here -- I'd blame the differences among ROMS
I actually haven't been able to get any recent versions working, myself...
inportb said:
I haven't been able to sync the Fitness with Gear app either, even with Samsung Account installed per Virnik0's recommendation.
I believe this stack trace is relevant:
Code:
D/SessionInputStream(29439): move remain data to first index / mTotalDataLength : 83 mTotalReceivedLength : 88
W/SessionManager(29439): notifyDataReceived port : 2
I/SessionManager(29439): mBinderMap.get action:com.samsung.android.wms.communication.session_manager_for_interanalbinder:115174198
I/SessionManager(29439): listener.onDataReceived is called
V/DataExchangeManager(29439): SessionManagerEventListener onDataReceived
W/DataExchangeManager(29439): From : HEALTH, Attempt to invoke interface method 'void com.samsung.android.wms.service.communication.DataExchangeManager$OnDataReceivedListener.onDataReceived(com.samsung.android.wms.service.communication.WingtipApp, byte[])' on a null object reference
W/DataExchangeManager(29439): java.lang.NullPointerException: Attempt to invoke interface method 'void com.samsung.android.wms.service.communication.DataExchangeManager$OnDataReceivedListener.onDataReceived(com.samsung.android.wms.service.communication.WingtipApp, byte[])' on a null object reference
W/DataExchangeManager(29439): at com.samsung.android.wms.service.communication.DataExchangeManager$InternalHandler.handleMessage(DataExchangeManager.java:126)
W/DataExchangeManager(29439): at android.os.Handler.dispatchMessage(Handler.java:102)
W/DataExchangeManager(29439): at android.os.Looper.loop(Looper.java:135)
W/DataExchangeManager(29439): at android.app.ActivityThread.main(ActivityThread.java:5223)
W/DataExchangeManager(29439): at java.lang.reflect.Method.invoke(Native Method)
W/DataExchangeManager(29439): at java.lang.reflect.Method.invoke(Method.java:372)
W/DataExchangeManager(29439): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
W/DataExchangeManager(29439): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)
It seems that it actually connected to Samsung's servers, but had some trouble handling the response. I'll investigate this sometime...
Same here -- I'd blame the differences among ROMS
I actually haven't been able to get any recent versions working, myself...
Click to expand...
Click to collapse
My problem getting the Bluetooth pair to GFM. On version 1.49 for lollipop it was but not this zip
will1549 said:
My problem getting the Bluetooth pair to GFM. On version 1.49 for lollipop it was but not this zip
Click to expand...
Click to collapse
It works. Sort of. Basically it asks for update every time I connect to my Fit. That update then fail due to different signing keys, but then it works.
I have used the version from OP
Virnik0 said:
It works. Sort of. Basically it asks for update every time I connect to my Fit. That update then fail due to different signing keys, but then it works.
I have used the version from OP
Click to expand...
Click to collapse
My problem is it only pair Bluetooth but never connect gear fit manager to the gear fit it keeps send verification codes.
bronxgsi said:
Very good explanation.
Thanks to you I was able to path version 1.98 and it works the media control, I can upload new watches styles using Watch Styler for Fit.
What doesn't work is the App connect. All applications say that I have to install Gear Manager Fit first.
It's working on my Nexus 4 with 5.0.1. I also updated the gear fit to the last firmware and it connects perfectly.
I attach it.
Click to expand...
Click to collapse
This one works fine! Thanks for sharing!
---------- Post added at 10:43 PM ---------- Previous post was at 10:25 PM ----------
Virnik0 said:
This one works fine! Thanks for sharing!
Click to expand...
Click to collapse
BTW, we'll need version 1.102, and original genuine keys. so, once you'll compile/smali odex, just add it to original APK, that shall do it, otherwise we won't be able to use any gear app plugin
I don't know why it doesn't pair... Sorry I'm not an expert in this issue.
Virnik0 said:
This one works fine! Thanks for sharing!
---------- Post added at 10:43 PM ---------- Previous post was at 10:25 PM ----------
BTW, we'll need version 1.102, and original genuine keys. so, once you'll compile/smali odex, just add it to original APK, that shall do it, otherwise we won't be able to use any gear app plugin
Click to expand...
Click to collapse
I tried to patch the last versión (GearFitManager_NL1_1.111.1216_USER.apk) but it doesn't pair. The original one, in a G2 with KitKat doesn't pair neither.
I was able to use all the plugins from App connect patching the "dexout\com\samsung\android\sdk\cup\Scup.smali" file to not to check the keys. Just changing:
if-eq v1, v6, :cond_e2
to
if-ne v1, v6, :cond_e2
The problema is that I had to patch every App I want to use and it is a little tedious. Maybe we can make an script or a program to automatically doing it...
Dunno what will be best way to do this now. I have a very little time to do any coding nowadays. But at least version 1.98 works fine. Running RR 5.2.9 (CM12 - Android 5.0.2) on GT9300. Pairing works correctly
A script would be wonderful
pcp12 said:
A script would be wonderful
Click to expand...
Click to collapse
Of course!!!
Works on my Nexus 5 (the APK in the first post)
I'll try to patch the last release
Does this versions just work on cm12? I have GPE lollipop on my s4 and when I connect my phone to the gear fit, the gear fit manager crashes immediately.
poaudet said:
Of course!!!
Works on my Nexus 5 (the APK in the first post)
I'll try to patch the last release
Click to expand...
Click to collapse
Because you have to modify ro.product.manufacturer=samsung to something else (like ro.product.manufacturer=GPE) in /system/build.prop
Reboot after modification is done and you should be OK.
BTW, SGS5 does have LP available for download for more then month, but GFM is the same. Works there fine, because all classes are provided from TW framework.
Virnik0 said:
Because you have to modify ro.product.manufacturer=samsung to something else (like ro.product.manufacturer=GPE) in /system/build.prop
Reboot after modification is done and you should be OK.
BTW, SGS5 does have LP available for download for more then month, but GFM is the same. Works there fine, because all classes are provided from TW framework.
Click to expand...
Click to collapse
Thanks, got it working. Really nice work! [emoji1]
poaudet said:
Of course!!!
Works on my Nexus 5 (the APK in the first post)
I'll try to patch the last release
Click to expand...
Click to collapse
Poaudet do you have a stock rom or another rom? I have a stock nexus 5 with kitkat and i am not about to upgrade to lollipop until my gear fit doesnt have the functionalities that are now working with 4.4.4. Anyone is using a stock nexus 5 with lollipop?
alexxio said:
Poaudet do you have a stock rom or another rom? I have a stock nexus 5 with kitkat and i am not about to upgrade to lollipop until my gear fit doesnt have the functionalities that are now working with 4.4.4. Anyone is using a stock nexus 5 with lollipop?
Click to expand...
Click to collapse
Im using google play edition on my s4. Its like the lollipop on nexus 5 and everything for me is working.
alexxio said:
Poaudet do you have a stock rom or another rom? I have a stock nexus 5 with kitkat and i am not about to upgrade to lollipop until my gear fit doesnt have the functionalities that are now working with 4.4.4. Anyone is using a stock nexus 5 with lollipop?
Click to expand...
Click to collapse
I've stock lollipop rom.
Things that didn't work:
-music control
-everything that need Samsung Account
-Endomondo
-GPS (Gear Navigation, Weather, ...)
Everything else seems to work, with some edit it the apk of Connected App, see the other post in this thread.
I've attached those i've already edit.
Noob question: I flew over the tutorial and didn't really noticed any variable data. Is there something preventing someone from generating and sharing a patched apk of GFM that would work with basically any non-Samsung Lollipop phone ?