Related
For those who are after Cyanogens ROM for HTC Magic (32B/vodafone) here it is.
<snip>
Cyanogen original rom will now work on 32B
Read this page
http://forum.xda-developers.com/showthread.php?t=539744
please note, if your coming from another ROM I suggest you wipe.
I was using jerpelea's port of cyanogens rom and when I installed the rom this way I couldn't get wifi to work.
After a full wipe it was all fine.
Jerpelea's port of the rom uses (or used, I haven't checked lately) an old kernel, which meant compcache didn't work.
He has also added ringtones and changed some other things.
Personally I like to have it installed the way cyanogen intended it.
Downloading
and I will try
BTW, how about the chinese Input?
You will need to ask cyanogen to include any features.
I have no intentions in changing this rom except if something is broken that does work on his rom.
Could you tell me how to sign boot.img cuz I get wrong digest when trying to do this myself?
you dont sign the boot.img, you need to sign the update.zip
Yes i know that and i sign it. But when trying to flash i get wrong digest boot.img. boot.img works and my signing works with other roms. This is my pain
Compcache is running great now! Thanks!
Just uploaded a new version of the update and boot.img.
The only changes are that I used the init.sapphire.rc from a sapphire build (one minor change with relation to a debugging hotkey that hardly anyone would use or even know about)
And I have found one of the sapphire keymaps that it was complaining about in logcat and installed it.
If you have the existing one there is no need to reflash in my opinion.
The changes are very minor. Just wait for the next version.
If anyone spots anymore errors popping up in the log with relation to sapphire difference post them up and I will see if I can work out
These are two of the errors I have noticed.
If anyone has come across these files I will include them. (they aren't in any builds I have seen)
Code:
W/KeyCharacterMap( 5257): Can't open keycharmap file
W/KeyCharacterMap( 5257): Error loading keycharmap file '[B]/system/usr/keychars/sapphire-nav-button.kcm.bin[/B]'. hw.keyboards.65538.devname='sapphire-nav-button'
W/KeyCharacterMap( 5257): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
Code:
W/KeyCharacterMap( 5257): Can't open keycharmap file
W/KeyCharacterMap( 5257): Error loading keycharmap file '[B]/system/usr/keychars/h2w_headset.kcm.bin[/B]'. hw.keyboards.0.devname='h2w headset'
W/KeyCharacterMap( 5257): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
....................
calendar
Seems not to be able to sync calendar? What do be done? (gmail & contacts no problem with syncing)
Upgraded from 3.9.6: Wifi, Calendar working and gmail. No contact sync as usual.
the g-sensor still doesn't work :|
timal said:
Upgraded from 3.9.6: Wifi, Calendar working and gmail. No contact sync as usual.
Click to expand...
Click to collapse
contact and other sync works ok for me
murgo said:
the g-sensor still doesn't work :|
Click to expand...
Click to collapse
g sensor works too
cyano 3.9.7
Is bluetooth audio working with this rom?
Gmail calendar syncing ok here (both ways, phone to gmail, gmail to phone)
It does take around 10 seconds or so.
Gsensor working fine. Search the forums. There are a couple of files to delete if the sensors don't work, or wipe the device.
from a search - "If g-sensor still does not work, remove /data/misc/akmd* /data/misc/rild* in recovery mode."
Contacts also syncing fine for me.
Just tested bluetooth from another phone and they can see each other and pair up.
can anyone test a bluetooth stereo headset with this rom please? Not wanting o flash yet another rom and be dissappointed
technocat said:
can anyone test a bluetooth stereo headset with this rom please? Not wanting o flash yet another rom and be dissappointed
Click to expand...
Click to collapse
Yup, My Nokia bh 503 stereo headset working perfectly. Seems like a real snappy rom. I'm fed up flashing ****ty hero roms that look pretty but god help you if you actually want to do something..
nice one clacks!!!!! finally a rom with bluetooth
I get this error on compcache 0.6 when running the test
=== user.conf ===
*** general ***
apps2sd=0
media2sd=1
*** CompCache ***
compcache_en=1
cc_memlimit=16
cc_disksize=32
cc_backingswap_en=0
cc_backingswap=/dev/block/mmcblk0p3
swappiness=30
*** Linux Swap ***
linux_swap_en=0
linux_swap_partition=/dev/block/mmcblk0p3
*** VM ***
sys_vm_en=0
page_cluster=0
laptop_mode=0
dirty_expire_centisecs=3000
dirty_writeback_centisecs=500
dirty_background_ratio=5
dirty_ratio=10
*** CPU ***
proc_cpu_en=0
scaling_min_freq=128000
scaling_max_freq=528000
sampling_rate=2000000
powersave_bias=200
up_threshold=32
=== CompCache status ===
CompCache version 0.6+
!!!ERROR Compcache disabled
CompCache: DiskSize (system) 32768(user)
!!! Unable to set compcache cc_swappiness to user specific "30"
Current system value is "60"
=== CompCache status output ===
Failed to open /dev/block/ramzswap0: No such file or directory
Can someone help please ?
First off, I'll be honest - I'm not 100% certain this is the correct place for this, so apologies in advance if it isn't.
For all sorts of reasons I decided to downgrade my Wildfire from CM7 (2.3.3) to the last official rom (2.2.1).
I did the usual wipe alongside titanium backups and reinstalled the old rom.
A little after restoring my backups, I realized SQLite databases weren't restored properly.
So obviously, being the geek that I am, I dug in and realized that CM7 uses SQLite 3.7 while the other rom uses 3.6, and the database files aren't backwards compatible.
This leaves two options:
1. Upgrade libsqlite on the old rom
Which would save all sorts of DB conversions but I can't figure out how to do it, I assume all sorts of files are linked against a specific version of libsqlite, in which case it will be very complicated.
2. Convert all the DB files down to 3.6
I decided to go that route.
I wrote a small script that used sqlite to dump the databases back to sql statements and then recreate them using sqlite 3.6.
Everything seemed to work, but when I replaced the actual files in /data/data I ran into this exception
(taken from XBMC remote but happens with other apps):
Code:
E/Database( 1561): Failure 1 (table hosts already exists) on 0x26cc90 when preparing 'CREATE TABLE hosts (_id INTEGER PRIMARY KEY,name TEXT,address TE
XT,http_port INTEGER,user TEXT,pass TEXT,esport INTEGER,timeout INTEGER,wifi_only INTEGER,access_point TEXT,mac_addr TEXT,wol_port INTEGER,wol_wait IN
TEGER);'.
E/SQLiteOpenHelper( 1561): Couldn't open xbmc_hosts.db for writing (will try read-only):
E/SQLiteOpenHelper( 1561): android.database.sqlite.SQLiteException: table hosts already exists: CREATE TABLE hosts (_id INTEGER PRIMARY KEY,name TEXT,
address TEXT,http_port INTEGER,user TEXT,pass TEXT,esport INTEGER,timeout INTEGER,wifi_only INTEGER,access_point TEXT,mac_addr TEXT,wol_port INTEGER,w
ol_wait INTEGER);
....
E/AndroidRuntime( 1561): java.lang.RuntimeException: Unable to start activity ComponentInfo{org.xbmc.android.remote/org.xbmc.android.remote.presentati
on.activity.HomeActivity}: android.database.sqlite.SQLiteException: Can't upgrade read-only database from version 0 to 4: /data/data/org.xbmc.android.
remote/databases/xbmc_hosts.db
Which, I figure means it couldn't lock the DB file, probably to permission issues.
But in addition to running the well known fix_permissions script, I actually observed the permissions of a newly created xbmc_hosts.db (by removing the old one) and compared them to mine, they appeared to be the same but still mine crashed and the other one worked flawlessly.
I must be missing something stupid, but I can't for the life of me figure out what it is.
Any ideas (or pointers as to how I can upgrade the SQLite library) in the rom would be appreciated.
Thanks
Edit: I've created a xposed module which works with the banking app version 1.7.1 see post below.
---------------------------------------------------
Edit: The changes needed to work with the latest version of the app (1.7.1) are listed in a post below below.
---------------------------------------------------
*There was a error in the diff file. I've uploaded the correct version. Also this patch will definitely not work with the latest version of the app.*
I managed to patch the Barclays mobile banking app version 1.4.2 to make it work with cyanagonmod 10.0 and cyanogenmod 11.
I realize that the current version on play store is 1.7.1 but I haven't updated to the latest version yet. If you do try the latest version please let me know if it differs greatly from the current version in it's root checks
I'm not going to attach the patched apk since using banking app from a stranger on the internet is really not a smart thing . Instead I will detail the work I did which hopefully someone else will find useful.
This guide is geared towards more technical people who already have some experience with android development. It will not give a detailed step by step how to, rather a general information about the process.
Obfuscation methods used in the app
The app obfuscates the names of some but not all of the namespaces/classes/methods which can stump some decompilers.
It seems to generously sprinkle useless switch statements and loops which does nothing but make the code appear way more complicated than it really is. I would guess quite a lot of the bulk in the code is coming through these dummy statements. smali2java-toolkit was of great help to figure this out.
All strings in the app have been encrypted by a simple xor algorithm which is then decrypted at run time just before they are used:
for example rather than
Code:
myfunction(“Hello world”)
the code writes something in the sort of:
Code:
myfunction(decrypt(“Juqqdxidqw”, 'x'))
The decryption function is a static method 'bЮЮЮЮЮЮ' in the class appears to be 'rrrrrr.srrrrr' (the method/class/namespace names are obfusecated)
I extracted the decompiled code from this method to write a console application which let me decrypt any string in the application:
Code:
static String decrypt(String crypStr, char keyChar) {
char[] arrayOfChar1 = crypStr.toCharArray();
char[] arrayOfChar2 = new char[arrayOfChar1.length];
for (int i = 0; i < arrayOfChar1.length; i++)
{
int j = keyChar ^ arrayOfChar1[i];
arrayOfChar2[i] = ((char)j);
}
return new String(arrayOfChar2);
}
Anti root methods used in the app
Checking for 'test-keys' string in the build tag. (/system/build.prop file)
Checking for superuser related package/apk files.
Checking for superuser hider package/apk files.
Checking for existance of 'su' binary
Attempting to execute 'su' binaryThe above checks are done both in the java/dex code and in a native code library.
Defeating the anti-root methods in Java/dex code:
The Java code is fairly easy defeat since changing the strings of the apk/file names which are checked as root related will make it think that no 'bad' apps are on the phone.
A bulk of checks happen in the isRootedDevice method of the com.barclays.android.application.BMBApplication class. While it checks for quite a lot of apk's, for my particular purpose I only needed to patch 2 lines in the method:
Smali file line 306 – which starts the checks for “test-keys” string in the build tag.
Smali file line 407 – which start the check for the string “/system/app/Superuser.apk”.The next method in the same class 'runRootCommand' attempts to execute 'su'
Smali line: 956 – which contains the string “su” which will be passed to java.lang.Runtime.exec
A (mostly?) duplicate of the isRootedDevice function exists in the com.barclays.android.container.DeviceData the relevant lines are :
smali file line 1237: "test-keys" string check
smali file line 1271: "/system/app/Superuser.apk" file checkAll of the above checks can easily be defeated by changing the the string so that it will check for a non existent package or file.
Keep in mind that all the strings listed above are in encrypted form. You can use the decrypt function listed above to decode them. I found the key char/byte needed to decrypt a given string is in the very next line to the one containing the encrypted string.
Defeating the anti-root methods in Native library
From what I can see the exact same tests which were done in the Java code is repeated in the native code library 'libtest_ndk.so'. As this check appears to form part of the authentication mechanism i don't believe it's possible to simply stop this check from being called from the Java code.
Also the com.barclays.android.container.sampler.SharedLibraryLoader which loads the native library appears to be doing some kind of checksum validation. While this probably could be easily worked around, disassembling an arm shared library was non trivial for me.
My approach was to write another native library which would hook into all the system calls such as 'system' 'stat' 'fopen', '__system_property_get' and redirect any operations to non existent targets, or change the return value. This achieves the same thing as what was done for the java code.
I put in some extra code into the smali classes to load my native library and to call it's initializer with the path to the actual native library.
Basic steps performed to patch the library:
Use apktool to decompile the original apk.
Code:
apktool d barclays.apk barclays
Use smali2java as helper to understand the code: This tool cannot decompile the critical check functions due to obfuscation. However it made it easier to understand the smali files generated by the apktool.
Patch the smali files to work around the checks as described above.
Build the hooking native library seperately
Code:
~/adt/adt-bundle-linux-x86_64-20131030/sdk/tools/android update project --path . --target android-19
ndk-build
Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library.
Use apktool to rebuild the apk.
Code:
Apktool b barclays barclays.apk
Sign the apk from using your own key.
Create keystore:
Code:
keytool.exe -genkey -v -keystore my-release-key.keystore -alias release -keyalg RSA -keysize 2048 -validity 20000
Sign Keystore:
Code:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore barclays.apk release
Attached is the code for the hook library native project and the diff for the smali changes. Please note that this is for the smali files for generated by apktool (v1.5.2) for the version 1.4.2 of the Barclays mobile banking app.
For Users of other ROMs/SU applications and root hiders.
The app checks for a lot of common packages which I did not bother to patch since I don't use them, but if you do then you should put fixes for all those package/file names in both the smali and native code hook library.
A non exhustive list of files it check are:
Code:
/system/bin/amphoras
/system/bin/su
/system/xbin/su
/system/app/superuser.apk
/data/data/com.amphoras.hidemyroot
/data/data/eu.chainfire.supersu
/data/data/stericson.busybox
/data/data/stericson.busybox.donate
/data/data/com.jrummy.busybox.installer.pro
/data/data/com.jrummy.busybox.installer
/data/data/com.rootuninstaller.free
/data/data/com.rootuninstaller
Hey i will try this out shortly and post a APK (whether you use it or not thats up to you, but i am well known in the xperia play section of this website and should be trusted, Still its up to you.)
EDIT: well i am not a android developer, i can follow almost all this post except the bits about the native library any chance of a bit more information
specifically this bit "Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library."
i assume that means just simply copy the built lib file in to that folder then include the file in the code somewhere? where do i do that to?
Sorry about the late reply but I just saw this message.
fma965 said:
EDIT: well i am not a android developer, i can follow almost all this post except the bits about the native library any chance of a bit more information
specifically this bit "Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library."
i assume that means just simply copy the built lib file in to that folder then include the file in the code somewhere? where do i do that to?
Click to expand...
Click to collapse
That's pretty much correct. There is already a 'libtest_ndk.so' file in the lib/armeabi folder of the apk. You just have to build my code from the zip file to get the libhooktest.so, which should then be copied into the lib/armeabi folder alongside the libtest_ndk.so.
Edit: Not sure if this is enough instructions. I'm just not good at writing instructions. Steps you need to build the native library are in my post. If you need more info i suggest about building the library http://code.google.com/p/awesomeguy/wiki/JNITutorial#Setup_Environment is a good
Afterwards you have to do the modifications I've listed in the diff to the .smali files.
But i have some bad news about this patch:
The diff file i have attached in the post is wrong. I've mistakenly uploaded the patch to reverse the changes i did . I will update the post with the correct diff file.
It will only work for Barclays app version 1.4.2. it will definitely not work for the latest version of the app which is 1.7.1.
I'm currently going through the code of 1.7.1 I've made some headway into the code but there I'm quite way off from getting it to work.
If you wish I can give you a copy of the original 1.4.2 of Barclays app, the built lib file and the patched app. I would recommend against using the patched app blindly but it might make it easier to figure out the changes i did. I would rather not upload them to xda though.
HiddenRambler said:
Sorry about the late reply but I just saw this message.
That's pretty much correct. There is already a 'libtest_ndk.so' file in the lib/armeabi folder of the apk. You just have to build my code from the zip file to get the libhooktest.so, which should then be copied into the lib/armeabi folder alongside the libtest_ndk.so.
Edit: Not sure if this is enough instructions. I'm just not good at writing instructions. Steps you need to build the native library are in my post. If you need more info i suggest about building the library http://code.google.com/p/awesomeguy/wiki/JNITutorial#Setup_Environment is a good
Afterwards you have to do the modifications I've listed in the diff to the .smali files.
But i have some bad news about this patch:
The diff file i have attached in the post is wrong. I've mistakenly uploaded the patch to reverse the changes i did . I will update the post with the correct diff file.
It will only work for Barclays app version 1.4.2. it will definitely not work for the latest version of the app which is 1.7.1.
I'm currently going through the code of 1.7.1 I've made some headway into the code but there I'm quite way off from getting it to work.
If you wish I can give you a copy of the original 1.4.2 of Barclays app, the built lib file and the patched app. I would recommend against using the patched app blindly but it might make it easier to figure out the changes i did. I would rather not upload them to xda though.
Click to expand...
Click to collapse
No worries about the late reply, yeah you basically told me what i assumed it was i had to do, however when i was trying to do it i didn't have a 1.4.2 apk so was trying ot use 1.7.X and obviously failed .
Yeah the modifications to smali files is easy well when you know what your changing xD
if you could upload the apk for 1.4.2 that would be great, i would assume that as long as the signature matches the official apk its untampered, your modified one will obviously be signed with a different signature though.
:cyclops:
Good news. I've managed to get latest version 1.7.1 patched . I will try to post the patch information this weekend. In the meantime i suggest anyone interested download a copy from the play store and keep a backup of the apk in case they release a new version.
Fix for latest version of the mobile banking app (version 1.7.1)
I've figured out the changes required for the v1.7.1 of the app which is the latest version as of this post.
Changes from the old 1.4.2 are:
Almost all the classes in the app are now obfuscated, whereas before only some of the core class names were obfuscated.
The string encryption has changed. rather than a single encryption function it now uses a group of functions to perform the encryption. rrrrrr/vuuuvu class seems to manage invoking the proper decryptor based on the arguments.
All root checking is now done via the native library.
Native library now does some checks as soon as it's loaded before any methods are called.
The last change is a big problem since its not possible to do the patching of the dll after loading it as was done before. The onload/init of the dll exits the whole application as soon as it detects the phone is rooted.
My solution was to use a modified version of the 'crazy_linker' custom loader library which comes with the ndk to load the library into memory without invoking it's onload/init functions. This lets us hook into the necessary functions before they are called.
I've attached the smali changes as a diff and the new native hook library in this post.
As a side note I think the version 1.4.2 is a far better version. Why on earth would a banking app need to permissions to take pictures, who spends their time 'customizing' a banking app with personal pictures.
Edit: I've fixed a bug where the root was still being detected when used with chainfire su app. Special thanks to lil-diabo for helping me fix the issue. :good:
Xposed module for barclays banking app 1.7.1
Edit: New version (BarcPosed1.1.apk) has some support for barclays pingit. I've not tested this my self as I don't use the application personally. If anyone tries it please let me know.
I've converted my patch into xposed module. This module is compatible with the current banking app (version 1.7.1).
Please consider this as a beta version for now. I've tested it on cyanogenmod but it might have some issues with other roms. If you try it please let me know if it worked.
Assuming you already have a working xposed installation the steps to get the app working are:
1) Install banking app from playstore. Make sure it's version 1.7.1
2) Install the BarcPosed.apk from my post.
3) Run the BarcPosed app and click the 'install' button. You will need to grant it root permissions.
4) Enable the module in xposed and reboot.
5) Use the barclays app as normal.
6) Disable automatic updates for the banking app to prevent it from updating.
I've included the source code for the app.
Thanks, works perfectly. You sir (or madam) are a genius
Sent from my GT-I9300 using XDA Premium 4 mobile app
Works like a charm
Just tested it and it works!
Most excellent, Thanks again for your hard work.
So much easier than having to manually edit the files etc.
It works,excellent job, finally can use Barclays mobile, thank you very much
sent from Samsung Galaxy S4 Active
Just tested and it worked marvellously. Could you please make a fix for pingit as well?
Zell Dinch said:
Just tested and it worked marvellously. Could you please make a fix for pingit as well?
Click to expand...
Click to collapse
HiddenRambler said:
Edit: New version (BarcPosed1.1.apk) has some support for barclays pingit. I've not tested this my self as I don't use the application personally. If anyone tries it please let me know.
Click to expand...
Click to collapse
I've updated my post with version that stops the rooted warning from pingit. Don't use pingit myself so don't know how successful it is. Let me know if you try it.
Brilliant, been struggling in vain with Root Cloak Plus on my N5 but this works perfectly. Many thanks.
Sent from my Xoom Wifi using Tapatalk
Before I switched to KK, I used Barclays App 1.3 doing a small trick with SuperSU. It worked perfectly. I signed the app myself so that it wouldn't update itself from the market and so that I could still use the automatic update in the market.
Do you think it would be possible to make your AMAZING solution work with my v1.3 signed app instead?
thnx
vivelafrance said:
Before I switched to KK, I used Barclays App 1.3 doing a small trick with SuperSU. It worked perfectly. I signed the app myself so that it wouldn't update itself from the market and so that I could still use the automatic update in the market.
Do you think it would be possible to make your AMAZING solution work with my v1.3 signed app instead?
thnx
Click to expand...
Click to collapse
You could try "root cloak" or "root cloak plus" they probably will work.
Actually, what I did, is sign the app with OneClickSigner and it worked fine. Now, the app is not attached to the market anymore since the signature changed, so that means I can continue to use the "automatic update" from the market and it won't ask me to update the app all the time when Barclays upload a new version.
thnx
HiddenRambler said:
...
I've converted my patch into xposed module. This module is compatible with the current banking app (version 1.7.1).
...
Click to expand...
Click to collapse
Hello,
I have a request, can you make it compatible with GingerBread plz?
Thanks.
LoMAX_HUN said:
Hello,
I have a request, can you make it compatible with GingerBread plz?
Thanks.
Click to expand...
Click to collapse
Can you try the attached apk. It's the same code but built as an app for gingerbread version (API lvl 10). I couldn't test it as I don't have a phone for that version.
If it doesn't work please give me a logcat.
Banking Works, but Not PingIt
HiddenRambler said:
Edit: New version (BarcPosed1.1.apk) has some support for barclays pingit. I've not tested this my self as I don't use the application personally. If anyone tries it please let me know.
I've converted my patch into xposed module. This module is compatible with the current banking app (version 1.7.1).
Please consider this as a beta version for now. I've tested it on cyanogenmod but it might have some issues with other roms. If you try it please let me know if it worked.
Assuming you already have a working xposed installation the steps to get the app working are:
1) Install banking app from playstore. Make sure it's version 1.7.1
2) Install the BarcPosed.apk from my post.
3) Run the BarcPosed app and click the 'install' button. You will need to grant it root permissions.
4) Enable the module in xposed and reboot.
5) Use the barclays app as normal.
6) Disable automatic updates for the banking app to prevent it from updating.
I've included the source code for the app.
Click to expand...
Click to collapse
xposed is fantastic!
This worked for me. It's so nice to be able to update my SU binaries without fear of breaking the app.
I'm running Cyanogenmod v10.2.0 on a Samsung Galaxy S3 (International) (i9300).
I tried using the v1.1 of the BarcPosed.apk with PingIt, but it still tried to gain root and then closed itself immediately.
Disclaymer: I am not responsible by what this binary can cause to your phone.
In the past month I have been struggling with getting "rclone mount" working on my phone, and after not finding anyway to have fuse working on my phone I decided to compile the fusermount.
Yoy should copy the binary to /system/bin or add to your path "export PATH=$PATH:/path_to_fusermount"
I use the source code from: https://github.com/LineageOS/android_external_fuse/tree/cm-14.1
and https://github.com/kirbyfan64/zdata/blob/master/fs/jni/fusermount.mk to compile the binary
In my case I can now use rclone in the following way (you still need to have root access), on a terminal (termux) for android:
Code:
su
rclone mount Box:/ /storage/cloud --vfs-cache-mode minimal --allow-other --gid 1015
Tested on:
Mi4c cm14.1 (android 7.1)
Huawei Mediapad M5 (android 8)
na
Thank you very much. It's so nice that ican mount gdrive on my old phone. Helped me a lot.
Can see my mount point on termux but not see on file manager, please help??
boyrobbie said:
Can see my mount point on termux but not see on file manager, please help??
Click to expand...
Click to collapse
Are you using magisk module based rclone-mount?
darfri said:
Are you using magisk module based rclone-mount?
Click to expand...
Click to collapse
Same with me, I am using magisk module based rclone-mount.
I'm also using magisk module on android 6.0, but I get
Code:
cannot locate symbol "__aeabi_memcpy"
, because of this I can't use this module at all as intended.
Mount folders are created, but are empty. I am able to manually send files to cloud strorage, but they don't show up locally. Also, I can see the mounted folders in bot ES file explorer and Termux.
Edit: Tried it on my other phone running CarbonRom 6.1 (android 8.1.0), and I face the same issue described before me. Termux can list files when cloud storage is mounted, but file explorers show empty folders.
Edit2: Google drive seems to be working on 8.1.0 with Solid Explorer File Manager, mega folder still shows up empty :/
Has anyone got afwall? What to unblock? I'd hate to unblock multicomponent system apps.
Maybe a custom iptables script?
For people who are getting empty folders outside termux, is most likely because mount namespace seperation is enabled in their supersu or magisk. I don't use magisk so don't know the exact option but for supersu, just uncheck "Mount namespace seperation" in its settings and reboot and try after that.
I have successfully done a 64-bit on-device build inside termux for fusermount with the relevant patches. Its working fine for now and most likely will work better for people. I plan to release the binaries, the source code and tasker projects related to it hopefully in the next few days, but if someone needs the binaries earlier, let me know.
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux's. Would it be possible to include arm as well?
Click to expand...
Click to collapse
I initially was attempting a static compile within a ubuntu chroot in my phone but the static flags wouldn't work and it still linked to the "lib/arm-linux-gnueabihf/libc.so" and "/lib/ld-linux-armhf.so.3", which are glibc libs... i then decided to compile within termux itself since people would be using rclone with that anyways and dynamic linkage would hopefully not be a problem. For a 32bit compilation, i would have to look more into it cause that would require 32 libs/compiler dependencies. I tried in the morning but it failed as expected.
i have attached the termux patched source and 64bit fusermount. Instructions for termux compilation are inside the source zip... the source is the same as the OP... If someone could attempt compilation on a 32 bit phone, that would be quicker.
Edit: made some patches and improvements, use new binary.
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Click to expand...
Click to collapse
btw why do u need it outside termux, just curious... if u have root, u could call termux binaries from outside anyways, depending on selinux of course...
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Ah, check it out, looks pretty cool. yeah fixing bugs before bug reports arrive is always appreciated, but if there a no bugs reports that you are fixing with time, then it may look like you are not doing any work
yeah exporting LD_LIBRARY_PATH would work and other than during compilation for makeconf.sh, termux $PREFIX patches are not needed in the source code. The hardcoded binaries are never called if mtab is disabled or platform is not BSD. Also configure.ac does need the $PREFIX patch for setting paths which are read by util/Makefile.am for installing mount.fuse, udev and init.d scripts but those are only needed when "make install" is run and we don't need to run it just to get fusermount. So basically a static compile is possible which does not have hardcoded dependencies on termux binary path, provided that a static compile actually works. You could probabky copy the libs from termux too like you said. I'll have to first have to revert the prefix patches again though.
Few questions, do u sometimes get "transport end point not connected" error while unmounting?
and any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
@agnostic-apollo
do u sometimes get "transport end point not connected" error while unmounting?
Click to expand...
Click to collapse
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
Click to expand...
Click to collapse
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
Click to expand...
Click to collapse
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Geofferey said:
@agnostic-apollo
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Click to expand...
Click to collapse
I'll leave a detailed reply later, its 9 in the morning, i have to sleep now
fyi you can use "ldd util/fusermount" to find the libraries its linking against... and can run "export LD_LIBRARY_PATH=/system/lib64:/system/lib" before running a binary in termux...if it fails with library errors, it requires termux libraries... restart termux or restore LD_LIBRARY_PATH afterwards or other termux stuff wont work...
anyways i did an on-device build of fusermount binary that does not depend on termux/libandroid-support... reverted most of the previous patches and added a few more with new build instructions.... the fusermount binary still depends on /system/lib* libc.so and libdl.so but those are provided by every phone and would run fine on most phones, its basically like the OP one but symbol errors could be there in some devices... truly static might be possible but on device build might not be possible and will probably require cross-compile if even possible... will look into it later
check out the new binary on both devices and let me know...
I am using rclone mount magisk module
It cannot reach the host (its written in the log) when I have "apps running as root" blocked in Afwall
I really hate to allow all root apps to access inet. I would like to allow only rclone access only single local ip
What custom script would help?
It is ordinary iptables script
noob here. but i can follow. how to mount my google drive to my phone alongside to my sdcard i just want to use this as a failsafe to my files, so far i followed the step from rclone using google drive. since some apps has auto backup on phone only and thinking this is the best way to sync my phone and app settings without manually checking and uploading those files. but the problem is im stuck on this error. (screenshot) hope someone can help me. ty
im using magisk rclone module
@Geofferey
Well i managed to cross compile for all archs using NDK targeting API 21. Cannot target an API older than that due to missing function implementation in Android bionic older than that. But binaries will need to be tested on different archs and android versions/devices. You can download the binaries from my github release here. You or others can compile them yourself if they want, instructions are here.
Moreover I still couldn't manage to do a static compile. I doubt it is gonna be possible, atleast easily since Android bionic is probably not meant for that. mucl is the best hope i think, since it fully supports static linking.
However the binaries compiled by me have less library dependencies than the ones OP posted so it could be better for some, even though in OP's case, the binaries are linking to android system libraries so shouldn't be a problem in most cases. FYI I found that "ldd" command is not reliable for finding dynamic linking. Use "readelf -d "fusermount" | grep NEEDED"
The OP binary dynamic linking:
Code:
ARCH=arm64-v8a
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
ARCH=armeabi-v7a
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
The binary dynamic linking compiled by me:
Code:
Build Info:
NDK_FULL_VERSION=20.0.5594570
C_COMPILER=clang
HOST_TAG=linux-x86_64
BUILD_TIMESTAMP=2019-07-31 08.20.46
ARCH_SRC=arm64-v8a
API_LEVEL=21
FUSERMOUNT=fusermount-arm64-v8a
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi-v7a
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi-v7a
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86
API_LEVEL=21
FUSERMOUNT=fusermount-x86
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86-64
API_LEVEL=21
FUSERMOUNT=fusermount-x86-64
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
Alas, the things that need to be done just get binaries to run on our phones properly. If it were only me that had to use fusermount, it wouldn't be a problem at all, i would have just run one my scripts to merge my chroot ubuntu distro's rootfs with my android's rootfs and just run the ubuntu's fusermount and it would have worked fine for me. The ubuntu's libraries would have been dynamically linked to the binary since the ubuntu libraries would be linked to /lib and I wouldn't have to do any compilation at all. Now if it were only this simple for everybody...
Btw i read your previous comments, will try replying to them once i wake up, been too busy with this stuff.
Geofferey said:
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
Click to expand...
Click to collapse
Interesting, I use rclone supplied by termux apt repository. I get the errors if the mount point is busy like root explorer has opened up a directory inside the mount point and I stop the rclone mount command. The rclone mount command exits with resource is busy errors as expected and if i try to unmount the mount point manually i get "transport endpoint" errors, i have run a lazy unmount to get the mount point to unmount.
Geofferey said:
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
Click to expand...
Click to collapse
lolz no apologies needed, I ramble a lot too, not that anybody listens or understands
1. People in most cases are going to put the rclone file once, so going to the magisk module directory should not be a problem.
2. Most apps are granted storage permissions by users in recent android versions, and they are granted without explicit grants in old versions.... /sdcard is basically fuse/sdcardfs mounted to /storage/emulated/0, so all apps having storage permissions would have access to /storage/emulated/0/.rclone and any other directory except the /storage/emulated/0/Android of course... These popular apps are the main security risk tbh, who most likely monitor everything on the sdcard... and selinux wouldn't do anything for sdcard if storage permissions are granted.
And if a person has physical access the then it probably doesn't matter where its stored, but storing it in a root accessible would most likely still be better...
3. You could use the mount command or /proc/mounts to see active mounts to detect what has been mounted till now...
4. Yeah if your threat is a physical access than just keep your bootloader locked and encryption enabled and live a miserable life without all the benefits of rooting. I don't want to live that life, at all... I would be more worried about apps than physical access. And mostly encryption is not supported by twrp so if your device is lost, consider all the data gone if u r using a decrypted device flr using update/backup. Leaving adb enabled normally shouldn't be a problem unless you lose your authorized PC as well, then u probably have much bigger things to worry about
5. I am not familiar with magisk module access but /data/.rclone should be fine to use instead... Only root apps would have access. I'm not sure what selinux contexts magisk module directory has, it might be safer against root apps who have not been granted root access through magisk.
Geofferey said:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Click to expand...
Click to collapse
yeah caching could be hard for the device and will need to be looked over more. Wakelocks would be an issue too. I tried using minimal mode but i need to do more testing. I was getting some lags, might be related. Mobile data issues could be there too, my tasker based projects can most likely handle those by remounting. rclone remote control commands can only drop caches currently, not change their modes. Will need to ask the dev to add it if needed.
Geofferey said:
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
Click to expand...
Click to collapse
yeah I'm up for contributing to the project but only after I have completed and released my projects, gonna take a few days atleast. And yeah i have got github as u already know by now...
lolz C is not for everybody, but thats how I started programming with so I can understand it at most times, understanding the purpose of the code is another issue
TL;DR : working photo pro for systems without Sony telemetry services: AFH
Hey guys I've been running a GSI of Descendant OS on my Xperia 5 II and I have been trying to get this photo pro app to work. All the versions I found on apkmirror crashes on launch, not to mention the ones that refuse to install. So after tinkering with some magisk modules I decided to decompile it and see what's going on inside. After a bit of log checking, I discovered some unimplemented telemetry functions which seems to be the cause of those crashes. After patching these the app runs like how it should be. I also removed the restrictions in AndroidManifests.xml that prevents the app to be installed on devices without com.sony.device lib, so any system should be able to install it just fine (not sure why Sony set restrictions for photo pro but not cinema pro).
Let me know if there's more issues to be solved
I've been running the APK from Photopro III for months and have had no significant issues. I got my APK from, I think, ADK.
2nd post down its from the Xperia 1 iii
@hx64 any chance for a patch for the latest version, or a guide as to how to patch it?
That would be awesome!
SeventhRaven said:
@hx64 any chance for a patch for the latest version, or a guide as to how to patch it?
That would be awesome!
Click to expand...
Click to collapse
I'm a bit busy these days so maybe I'll work on that a few weeks later.
Meanwhile, what I did is fairly simple and anyone can do it themselves. Once the app crashes, grab the crash log with `adb logcat --buffer=crash` and find the entry with the package name. There will be an attribute that points to a specific line of code which caused the crash, usually an explicit error `throw` action. You'll then need to decompile the .apk file and modify the corresponding file. I use an extension called apklab in VScode but you can do it with apktool too. You should be able to edit the source code (.smali or .java, depending on the tools you used) and locate the lines that throw errors (based on my experience it is usually the unimplemented methods in com.sonyerricsson.idd.api.Idd component that caused the errors so I just removed those `throw` statements in .java files or replace them with `return-void` statements in .smali files). The last step is to recompile and sign the package (using the same tool you used to decompile). You may need to test and repeat these steps a few more times to resolve all the error throws but the process is fairly straight forward and you can find a lot of tutorials online.
Good luck fiddling!
hx64 said:
I'm a bit busy these days so maybe I'll work on that a few weeks later.
Meanwhile, what I did is fairly simple and anyone can do it themselves. Once the app crashes, grab the crash log with `adb logcat --buffer=crash` and find the entry with the package name. There will be an attribute that points to a specific line of code which caused the crash, usually an explicit error `throw` action. You'll then need to decompile the .apk file and modify the corresponding file. I use an extension called apklab in VScode but you can do it with apktool too. You should be able to edit the source code (.smali or .java, depending on the tools you used) and locate the lines that throw errors (based on my experience it is usually the unimplemented methods in com.sonyerricsson.idd.api.Idd component that caused the errors so I just removed those `throw` statements in .java files or replace them with `return-void` statements in .smali files). The last step is to recompile and sign the package (using the same tool you used to decompile). You may need to test and repeat these steps a few more times to resolve all the error throws but the process is fairly straight forward and you can find a lot of tutorials online.
Good luck fiddling!
Click to expand...
Click to collapse
I tried working on that by simply removing the requirements (although I actually have zero development experience), but I would always get a parsing error (probably an issue with the signing? No idea how to do that properly) when trying to install it.
As for the unmodified version, I cannot install it at all, as it says it's not compatible. So a crash technically never occurs.
But I don't mind waiting for a patch. Just glad to see it's an option still.
SeventhRaven said:
I tried working on that by simply removing the requirements (although I actually have zero development experience), but I would always get a parsing error (probably an issue with the signing? No idea how to do that properly) when trying to install it.
As for the unmodified version, I cannot install it at all, as it says it's not compatible (using a custom ROM). So a crash technically never occurs.
But I don't mind waiting for a patch. Just glad to see it's an option still.
Click to expand...
Click to collapse
Oh I forgot to mention the install issues. There's a `use-library` line in the AndroidManifest.xml that requires the `com.sony.device` library which you'll need to remove in order to install it on non-official systems.
And be sure to use deCOMPILE tools first (it won't work if you deCOMPRESS and edit since a signature is required), google for apktool or check out the apklab github page. I have little java knowledge previously but in this case fortunately you don't need much
I'll try switching to my dev environment as soon as possible.
hx64 said:
Oh I forgot to mention the install issues. There's a `use-library` line in the AndroidManifest.xml that requires the `com.sony.device` library which you'll need to remove in order to install it on non-official systems.
And be sure to use deCOMPILE tools first (it won't work if you deCOMPRESS and edit since a signature is required), google for apktool or check out the apklab github page. I have little java knowledge previously but in this case fortunately you don't need much
I'll try switching to my dev environment as soon as possible.
Click to expand...
Click to collapse
Yeah I tried apktool and I guess I recompiled it with Android Studio. All I changed was setting the requirement for com.sony.device lib to false.
I'll try my luck with the tool you've linked, thanks!
hx64 said:
I'm a bit busy these days so maybe I'll work on that a few weeks later.
Meanwhile, what I did is fairly simple and anyone can do it themselves. Once the app crashes, grab the crash log with `adb logcat --buffer=crash` and find the entry with the package name. There will be an attribute that points to a specific line of code which caused the crash, usually an explicit error `throw` action. You'll then need to decompile the .apk file and modify the corresponding file. I use an extension called apklab in VScode but you can do it with apktool too. You should be able to edit the source code (.smali or .java, depending on the tools you used) and locate the lines that throw errors (based on my experience it is usually the unimplemented methods in com.sonyerricsson.idd.api.Idd component that caused the errors so I just removed those `throw` statements in .java files or replace them with `return-void` statements in .smali files). The last step is to recompile and sign the package (using the same tool you used to decompile). You may need to test and repeat these steps a few more times to resolve all the error throws but the process is fairly straight forward and you can find a lot of tutorials online.
Good luck fiddling!
Click to expand...
Click to collapse
Welp, that was easy. Used VScode with the extension, swapped the lib flag to false and removed the component you mentioned. Now it works (although that bokeh setting still crashes it if selected, but whatever).
I've attached the patched .apk for your convenience. Big thanks again for pointing me towards those tools!
(I didn't touch anything else, though...so idk about analytics, but I firewall apps anyway so not like it can send anything)
SeventhRaven said:
Welp, that was easy. Used VScode with the extension, swapped the lib flag to false and removed the component you mentioned. Now it works (although that bokeh setting still crashes it if selected, but whatever).
I've attached the patched .apk for your convenience. Big thanks again for pointing me towards those tools!
Click to expand...
Click to collapse
Nice work!
Glad I could help xD
SeventhRaven said:
Welp, that was easy. Used VScode with the extension, swapped the lib flag to false and removed the component you mentioned. Now it works (although that bokeh setting still crashes it if selected, but whatever).
I've attached the patched .apk for your convenience. Big thanks again for pointing me towards those tools!
Click to expand...
Click to collapse
Any chance someone could do this for the Video Pro app (1.0.a.0.26)?
I took a shot at trying to mod the apk..
I successfully installed with the Manifest.xml library edit, but upon crashing here's my log:
Code:
04-27 16:54:12.702 8085 8148 E AndroidRuntime: FATAL EXCEPTION: IddManagerThread
04-27 16:54:12.702 8085 8148 E AndroidRuntime: Process: jp.co.sony.mc.videopro, PID: 8085
04-27 16:54:12.702 8085 8148 E AndroidRuntime: java.lang.RuntimeException: Not an implementation
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at com.sonyericsson.idd.api.Idd.addEvent(Idd.java:114)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at jp.co.sony.mc.videopro.idd.core.IddManager.addAppData(IddManager.kt:99)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at jp.co.sony.mc.videopro.idd.core.IddManager.handleMessage(IddManager.kt:88)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at jp.co.sony.mc.videopro.idd.core.IddManager.access$handleMessage(IddManager.kt:17)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at jp.co.sony.mc.videopro.idd.core.IddManager$Companion$init$1$1.handleMessage(IddManager.kt:50)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at android.os.Looper.loop(Looper.java:223)
04-27 16:54:12.702 8085 8148 E AndroidRuntime: at android.os.HandlerThread.run(HandlerThread.java:67)
And this is where I get lost. Swapping the throw code in com.sonyerricsson.idd.api.Idd doesn't seem to solve the crashes, and I'm not sure where to go next. I don't see any HandlerThread or loop smali files, and in jp.co.sony.mc.videopro.idd.core.IddManager, I'm not familiar with the code in the lines where the errors are defined.
SeventhRaven said:
Welp, that was easy. Used VScode with the extension, swapped the lib flag to false and removed the component you mentioned. Now it works (although that bokeh setting still crashes it if selected, but whatever).
I've attached the patched .apk for your convenience. Big thanks again for pointing me towards those tools!
(I didn't touch anything else, though...so idk about analytics, but I firewall apps anyway so not like it can send anything)
Click to expand...
Click to collapse
Just installed your patched version on the latest Pixel Experience GSI (v414/June security patch) on a Xperia 1 III and it worked perfectly including bokeh.
Any chance you'll be sharing patched versions of more recent releases of the app?
Thanks!
Patched version of the latest (1.4.A.0.20-2621460) attached.
Thanks for your work around this @hx64.
@delfuhd I also could not untangle the logcat so I ended up replacing all instances of 'throw p0' in com.sonyericsson.idd.api.Idd with 'return-void' and there doesn't seem to be an issue (yet).
Is the app asking for some Sony exclusive features? I mean, do we lose something like postprocessing or image management? thanks!
Not working
Double post.
The 70mm lens causes the app to crash in Auto mode in every 1.4 and 1.5 version I tested. The only one that seems to work is the older 1.3 version.
Still here is the latest patched 1.5 version that I tried. Thanks for the guide above!
cari66eam said:
The 70mm lens causes the app to crash in Auto mode in every 1.4 and 1.5 version I tested. The only one that seems to work is the older 1.3 version.
Still here is the latest patched 1.5 version that I tried. Thanks for the guide above!
Click to expand...
Click to collapse
Thank you so much for providing the patched version!!! I'm on lineageos 20, no gapps etc. and the 1.2 works great. Haven't tried 1.3, but 1.4 and 1.5 don't work for me...