Hello,
I'm trying to develop an Xposed module that will allow me to change the carrier text of the device on demand (in reality, this will happen when the music track is changed).
I'm already using a BroadcastReceiver to listen to track-changed events from various media players, but I want to change the carrier text of the device when I receive such an intent.
However, I wasn't able to find how to do it using Xposed, as it only allows me to hook methods before/after they execute (feel free to correct me if I'm wrong of course), which isn't exactly what I need.
I went through the source code of XBlastTools for changing the carrier text, but wasn't able to conclude much for my needs.
Please advise in setting up a method that will basically get a String and replace the carrier text with that given String (at any given time). Something like this:
Code:
public void setName(String name) {
// TODO implement
}
Normally, you'd put your BroadcastReceiver somewhere you can access the carrier TextView from. You'd then be able to edit it when you want normally. In this case it looks like there's an easier way, though.
Here's how I'd do it: register a BroadcastReceiver in CarrierText's constructor. In that receiver, get and save the text you want as a class variable. Then hook getCarrierTextForSimState and make it return that variable.
http://grepcode.com/file_/repositor...licy/impl/keyguard/CarrierText.java/?v=source
GermainZ said:
Normally, you'd put your BroadcastReceiver somewhere you can access the carrier TextView from. You'd then be able to edit it when you want normally. In this case it looks like there's an easier way, though.
Here's how I'd do it: register a BroadcastReceiver in CarrierText's constructor. In that receiver, get and save the text you want as a class variable. Then hook getCarrierTextForSimState and make it return that variable.
http://grepcode.com/file_/repositor...licy/impl/keyguard/CarrierText.java/?v=source
Click to expand...
Click to collapse
That's a good way of doing things if it weren't for the "on demand" requirement.
Basically, what I want to do is set the carrier text to a different one whenever the onReceive() of the BroadcastReceiver is called, so I can't just hook into getCarrierTextForSimState() and change that, because it probably won't be called whenever I need.
benthe said:
That's a good way of doing things if it weren't for the "on demand" requirement.
Basically, what I want to do is set the carrier text to a different one whenever the onReceive() of the BroadcastReceiver is called, so I can't just hook into getCarrierTextForSimState() and change that, because it probably won't be called whenever I need.
Click to expand...
Click to collapse
Then call the setText method from your receiver as well.
GermainZ said:
Then call the setText method from your receiver as well.
Click to expand...
Click to collapse
By the way, I think the class you linked to only affects the carrier name that appears on the lockscreen.
I'm not that interested in this carrier text to be honest, and basically want to set the carrier text whereever it may be the class you linked to is pulling it from.
The main idea behind my module is that I have a BT headset in my car that can only display the carrier name & bluetooth name of my phone, but I want it to display the currently playing track. So I want to change the bluetooth name of the phone to the artist of the currently playing song (almost works at this point, just have some crashes I need to deal with), and set the carrier name to the name of the song that's currently playing.
However, I didn't manage to do that later. I tried various methods, but no luck so far.
EDIT: I managed to get everything working for the most part (I didn't test it with the actual BT headset, but both the BT and carrier names change when changing tracks).
However, I'm getting 2 error messages constantly as soon as I start playback:
1. Unfortunately, the process android.process.acore has stopped.
2. Unfortunately, the process android.process.media has stopped.
Any ideas on how to fix those two? What's causing them seems to be the changing of the bluetooth name (although it does work, just shows me those two crash errors time after time). Here's the code for my bluetooth manager.
Disabling the "setName" call of the BluetoothAdapter fixes the crashes (but obviously doesn't change the BT name of the device, which defeats the purpose).
Also, replacing the said call with:
Code:
XposedHelpers.callMethod(mLocalAdapter, "setName", name);
fixes this, but I prefer to do things without using reflection and hooking if I can (which is possible in this case), so it seems like it's just a permission issue.
It might be because of a permission problem:
I put together a quick Android app to simulate changing the BT name in the same way, and it crashed without adding:
Code:
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
to the manifest file.
However, if I recall correctly, Xposed modules run in root mode, so they shouldn't need permissions to do whatever they please. Also, I tried adding the above permissions to my module, but it still crashes.
Any help on the matter would be most appreciated.
I just checked which class XBlastTools hooked and assumed that's it. If not, look for the right one or see the first part of post #2.
About the crashes: check your logcat.
Xposed modules do not run as root, they'll have the same permissions as the process they're in (the app you're hooking). You can hook anything, though (including Android system methods).
GermainZ said:
I just checked which class XBlastTools hooked and assumed that's it. If not, look for the right one or see the first part of post #2.
About the crashes: check your logcat.
Xposed modules do not run as root, they'll have the same permissions as the process they're in (the app you're hooking). You can hook anything, though (including Android system methods).
Click to expand...
Click to collapse
Thanks for the help.
I got the carrier name part working perfectly now (or so it seems at least, I'll have to check later in the actual car BT headset).
The only part that remains to make the module fully functional is the Bluetooth one. I checked my logcat, and like I said in my previous post - I think it's a permission issue, which is rather weird - as I set both permissions needed for Bluetooth for the module. Keep in mind that the part that's running the bluetooth code in the app isn't hooking anything, it runs on the module itself as far as I can tell. I'm calling it on the onReceive callback from the BroadcastReceiver (I don't think the app that send the broadcast has bluetooth permissions, but that shouldn't matter, should it?).
benthe said:
Thanks for the help.
I got the carrier name part working perfectly now (or so it seems at least, I'll have to check later in the actual car BT headset).
The only part that remains to make the module fully functional is the Bluetooth one. I checked my logcat, and like I said in my previous post - I think it's a permission issue, which is rather weird - as I set both permissions needed for Bluetooth for the module. Keep in mind that the part that's running the bluetooth code in the app isn't hooking anything, it runs on the module itself as far as I can tell. I'm calling it on the onReceive callback from the BroadcastReceiver (I don't think the app that send the broadcast has bluetooth permissions, but that shouldn't matter, should it?).
Click to expand...
Click to collapse
Remember that all hooked code does *not* run as your app so your app's permissions don't matter here. Hooked code runs as if it was in the hooked process.
Can't say much else without the actual error.
GermainZ said:
Remember that all hooked code does *not* run as your app so your app's permissions don't matter here. Hooked code runs as if it was in the hooked process.
Can't say much else without the actual error.
Click to expand...
Click to collapse
But this code does run on the module.
In my main class (that implements IXposedHookLoadPackage), I'm initializing a class (that derives from Object, and doesn't implement any interfaces), in which I register the BroadcastReceiver (on the context of the application, via AndroidAppHelper.currentApplication().getApplicationContext()), when the onReceive() method is called in the BroadcastReceiver I call the setName() method of the BluetoothAdapter.
If it doesn't run on the module application, on what application does it run on?
And here's the error:
E/AndroidRuntime( 5063): FATAL EXCEPTION: main
E/AndroidRuntime( 5063): Process: com.maxmpz.audioplayer, PID: 5063
E/AndroidRuntime( 5063): java.lang.RuntimeException: Error receiving broadcast Intent { act=com.maxmpz.audioplayer.TRACK_CHANGED flg=0x10 (has extras) } in com.bengr.MusicMetadataForLegacyDevices.Musi
[email protected]
E/AndroidRuntime( 5063): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:785)
E/AndroidRuntime( 5063): at android.os.Handler.handleCallback(Handler.java:733)
E/AndroidRuntime( 5063): at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime( 5063): at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 5063): at android.app.ActivityThread.main(ActivityThread.java:5144)
E/AndroidRuntime( 5063): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 5063): at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime( 5063): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795)
E/AndroidRuntime( 5063): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:611)
E/AndroidRuntime( 5063): at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
E/AndroidRuntime( 5063): at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime( 5063): Caused by: java.lang.SecurityException: Need BLUETOOTH ADMIN permission: Neither user 10128 nor current process has android.permission.BLUETOOTH_ADMIN.
E/AndroidRuntime( 5063): at android.os.Parcel.readException(Parcel.java:1465)
E/AndroidRuntime( 5063): at android.os.Parcel.readException(Parcel.java:1419)
E/AndroidRuntime( 5063): at android.bluetooth.IBluetooth$Stub$Proxy.setName(IBluetooth.java:783)
E/AndroidRuntime( 5063): at android.bluetooth.BluetoothAdapter.setName(BluetoothAdapter.java:660)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.BluetoothManager.setName(BluetoothManager.java:50)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener.updateRemoteFieldsFromLocalFields(MusicListener.java:150)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener.setTrackMetadata(MusicListener.java:144)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener.access$4(MusicListener.java:138)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener$1.onReceive(MusicListener.java:105)
E/AndroidRuntime( 5063): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:775)
E/AndroidRuntime( 5063): ... 10 more
W/ActivityManager( 935): Force finishing activity com.maxmpz.audioplayer/.PlayerUIActivity
W/ActivityManager( 935): Force finishing activity com.maxmpz.audioplayer/.PlayListActivity
D/LogFetchServiceManager( 6618): Received entry added
W/ActivityManager( 935): Activity pause timeout for ActivityRecord{42d72640 u0 com.maxmpz.audioplayer/.PlayerUIActivity t4 f}
I/Timeline( 1490): Timeline: Activity_idle id: [email protected] time:183794
I/Timeline( 935): Timeline: Activity_windows_visible id: ActivityRecord{42ca81c8 u0 com.teslacoilsw.launcher/com.android.launcher2.Launcher t1} time:184001
W/System.err( 5009): LOG: Warning Unknown dock level ignored.
Click to expand...
Click to collapse
Also, here's the project (together with the PowerAMP API project, as it depends on it, and the Android tester application I made to simulate changing the bluetooth name on a "regular" project): link, if that's of any help.
I can't check the project right now, but just to make sure I understand correctly, you're doing something like this:
1- You're hooking the class in which the carrier text is set and registering a BroadcastReceiver there.
2- From your app, you're sending a broadcast whenever you want (possibly with the text you want in the extras).
3- In the BroadcastReceiver's onReceive method, you're setting the carrier text to the value you just received.
If that's what you're doing, it seems fine to me. For the permissions issue, I suppose adding the required permission to your manifest will fix that.
GermainZ said:
I can't check the project right now, but just to make sure I understand correctly, you're doing something like this:
1- You're hooking the class in which the carrier text is set and registering a BroadcastReceiver there.
2- From your app, you're sending a broadcast whenever you want (possibly with the text you want in the extras).
3- In the BroadcastReceiver's onReceive method, you're setting the carrier text to the value you just received.
If that's what you're doing, it seems fine to me. For the permissions issue, I suppose adding the required permission to your manifest will fix that.
Click to expand...
Click to collapse
Not really. The carrier text has nothing to do with the issue anymore. Even if I removed all the code that has to do with the carrier text, and left the bluetooth part alone - the issue would persist.
What I'm doing is this:
1- Have a regular class (meaning it derives from Object directly, and doesn't implement any interfaces).
2- In the said class I set up a BroadcastReceiver (using the application context, which I got via AndroidAppHelper.currentApplication().getApplicationContext(), which is static and can be called from anywhere).
3- When the BroadcastReceiver's onReceive() is called (again, in the previously mentioned class), I call BluetoothAdapter.getDefaultAdapter().setText with the text I want to set as the phone's BT name.
4- Error messages pop-up, and the error I attached in my previous reply shows up on the logcat. (this step occurs when the onReceive is called, which calls the setText).
When I comment out the setText() call, no errors occur (but the BT name doesn't change, obviously).
It's important to note that I did add the needed permissions to my manifest:
AndroidManifest.xml:
Code:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.bengr.musicmetadateforlegacydevices"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="16"
android:targetSdkVersion="19" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<meta-data android:name="xposedmodule" android:value="true"/>
<meta-data android:name="xposedminversion" android:value="50"/>
<meta-data android:name="xposeddescription" android:value="Changes the device's carrier and bluetooth names to display the currently playing track."/>
</application>
</manifest>
So you're not using Xposed for anything anymore? Sorry but I'm a bit confused now.
GermainZ said:
So you're not using Xposed for anything anymore? Sorry but I'm a bit confused now.
Click to expand...
Click to collapse
For what I'm doing right now? Not really.
My module is composed of two parts - one for changing the BT name (which doesn't require private calls, and can be done via Android's public API), and one for changing the carrier name (which does require Xposed, as I'm doing some private calls etc).
The carrier name part of the module works perfectly right now.
However, the Bluetooth one doesn't; and crashes as mentioned before, and throws a permission error. However, on a side-project that's just a regular Android app, that also changes the BT name this works (keep in mind that in both the side-project and the Xposed module project I added both Android bluetooth permissions).
Related
Update 3/1: http://forum.xda-developers.com/showpost.php?p=11744801&postcount=118
Update 2/25: http://forum.xda-developers.com/showpost.php?p=11643634&postcount=103
Update: http://forum.xda-developers.com/showpost.php?p=10767062&postcount=59
Some progress has been made (quite a bit actually). Still not working though.
Old:
Anyone working on this currently? I've cobbled together some info from the N1 port and have the following:
Libraries pushed
Code:
/system/lib/libganril.so
/system/lib/libkineto.so
/system/lib/librilswitch.so
(Added this for posterity, but it didn't seem to solve any issues)
Code:
/system/lib/libhtc_ril.so
Edited build.prop
Removed
Code:
rild.libpath=/vendor/lib/libsec-ril.so
Added
Code:
rild.libpath=/system/lib/librilswitch.so
rilswitch.vendorlibpath=/vendor/lib/libsec-ril.so
rilswitch.ganlibpath=/system/lib/libganril.so
I compiled the kineto_gan module from the cm commit against the kernel source released and the module inserts properly (here: https://github.com/cyanogen/cm-kernel-exp/commit/9158026851f843c5af0239fe16fbd99f0ecc37b8#diff-0_
Using the APK linked in the N1 forum: MS-HTCVISION-KNT20-02.apk
With this done the phone boots fine and I can get service with t-mobile. The kineto_gan module appears to load without issue. However, when launching the Wifi calling app I immediately get a FC. Logcat shows
Code:
D/dalvikvm( 1256): Trying to load lib /data/data/com.android.kineto/lib/libkinet
o.so 0x40514538
W/dalvikvm( 1256): Exception Ljava/lang/UnsatisfiedLinkError; thrown while initi
alizing Lcom/android/kineto/kineto;
W/dalvikvm( 1256): Class init failed in newInstance call (Lcom/android/kineto/ki
neto;)
D/AndroidRuntime( 1256): Shutting down VM
W/dalvikvm( 1256): threadid=1: thread exiting with uncaught exception (group=0x4
0015560)
E/AndroidRuntime( 1256): FATAL EXCEPTION: main
E/AndroidRuntime( 1256): java.lang.ExceptionInInitializerError
E/AndroidRuntime( 1256): at java.lang.Class.newInstanceImpl(Native Method
)
E/AndroidRuntime( 1256): at java.lang.Class.newInstance(Class.java:1409)
E/AndroidRuntime( 1256): at android.app.Instrumentation.newActivity(Instr
umentation.java:1021)
E/AndroidRuntime( 1256): at android.app.ActivityThread.performLaunchActiv
ity(ActivityThread.java:1536)
E/AndroidRuntime( 1256): at android.app.ActivityThread.handleLaunchActivi
ty(ActivityThread.java:1638)
E/AndroidRuntime( 1256): at android.app.ActivityThread.access$1500(Activi
tyThread.java:117)
E/AndroidRuntime( 1256): at android.app.ActivityThread$H.handleMessage(Ac
tivityThread.java:928)
E/AndroidRuntime( 1256): at android.os.Handler.dispatchMessage(Handler.ja
va:99)
E/AndroidRuntime( 1256): at android.os.Looper.loop(Looper.java:123)
E/AndroidRuntime( 1256): at android.app.ActivityThread.main(ActivityThrea
d.java:3647)
E/AndroidRuntime( 1256): at java.lang.reflect.Method.invokeNative(Native
Method)
E/AndroidRuntime( 1256): at java.lang.reflect.Method.invoke(Method.java:5
07)
E/AndroidRuntime( 1256): at com.android.internal.os.ZygoteInit$MethodAndA
rgsCaller.run(ZygoteInit.java:839)
E/AndroidRuntime( 1256): at com.android.internal.os.ZygoteInit.main(Zygot
eInit.java:597)
E/AndroidRuntime( 1256): at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime( 1256): Caused by: java.lang.UnsatisfiedLinkError: Cannot load
library: reloc_library[1311]: 75 cannot locate '_ZN7android11AudioRecordC1Eij
ijijPFviPvS1_ES1_i'...
E/AndroidRuntime( 1256):
E/AndroidRuntime( 1256): at java.lang.Runtime.loadLibrary(Runtime.java:43
4)
E/AndroidRuntime( 1256): at java.lang.System.loadLibrary(System.java:554)
E/AndroidRuntime( 1256): at com.android.kineto.kineto.<clinit>(kineto.jav
a:1563)
E/AndroidRuntime( 1256): ... 15 more
D/dalvikvm( 107): GC_CONCURRENT freed 2050K, 43% free 6364K/11079K, external 50
89K/5896K, paused 2ms+6ms
Clearly we are running into an issue as shown here:
Code:
W/dalvikvm( 1256): Exception Ljava/lang/UnsatisfiedLinkError; thrown while initi
alizing Lcom/android/kineto/kineto;
Code:
E/AndroidRuntime( 1256): Caused by: java.lang.UnsatisfiedLinkError: Cannot load
library: reloc_library[1311]: 75 cannot locate '_ZN7android11AudioRecordC1Eij
ijijPFviPvS1_ES1_i'...
I am hoping someone can help shed some light on whether this is an issue with a missing library that I have overlooked (and was already present on the N1) or a general incompatibility with the NS / 2.3.
I am going to do some hunting with google later, but if anyone has any thoughts or can point me to someone with some more knowledge on porting this over (someone who worked with the N1 port possible?) that would be helpful.
Yes this would be a great addition!
Sent from my Nexus S using XDA App
It's a bit of work, and it's not T-Mobile UMA, but it does a decent job for me:
http://forum.xda-developers.com/showthread.php?t=877879
IDtheTarget said:
It's a bit of work, and it's not T-Mobile UMA, but it does a decent job for me:
http://forum.xda-developers.com/showthread.php?t=877879
Click to expand...
Click to collapse
I had this going on my N1 - not really why I am looking for this (although a working solution for some things). It's a nice idea, but it uses a different phone number.
AT&T had a very nice network extender for the few times a year I am in areas with poor to no coverage. T-Mobile does not. The UMA/GAN wifi calling appears to be their answer, but it's available only on a few, select phones. If this could get ported over that would be resolved.
From the videos of Kineto demoing the SW they were running it on a Vibrant, so the hardware should be fine (assuming we have a proper APK and libraries).
Once I get some time I plan on looking into this. With a quick glance at the error it appears to be a library issue...though I'm not certain until I tear apart the apk!
Sent from my Nexus S using XDA App
ritcereal said:
Does anyone have the apk? I am interested in getting this running given the poor reception I tend to find.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
Uploaded the APK and libraries taken from the N1 port.
I am leaning towards a missing library as well hopefully - I am going to dig into it tonight hopefully and see if I can get anywhere with it.
if anyone could get this app figured out, i would greatly appreciate the effort!
i have no cell coverage at my house. i have used uma for years, but just upgraded to the nexus s thinking it would have this app. now, i see it only works on the g2 and mt4. ugh...
b84cops said:
if anyone could get this app figured out, i would greatly appreciate the effort!
i have no cell coverage at my house. i have used uma for years, but just upgraded to the nexus s thinking it would have this app. now, i see it only works on the g2 and mt4. ugh...
Click to expand...
Click to collapse
agree on all parts.
looks like i will have to switch sims when i get home with nexus 1 until this can be resolved. sip calling does not work at all for me.
Thanks for tackling this krohnjw.
It's a little frustrating when people think that VOIP is the same thing.
Wifi Calling (UMA) effectively lets your phone act as if it were on its native network anywhere in the world, as long as you have a wifi signal. This is a godsend to those of us who travel internationally (or in places with poor reception).
Once this reaches N1 level stability, I'll probably switch over to the Nexus S.
Not looking great so far. Out of curiosity I fired it up in a few AVDs.
On the stock 2.2 AVD it loads fine and brings up the tutorial / connect prompt (clearly missing the needed libs for it to work though).
On the 2.3 AVD it FC with the same error >.> This leads me to believe that enough was changed in 2.3 with respect to AudioRecord that this may not work in its current incarnation.
I hope this isn't what we are running up against with changes from 2.2 - 2.3
The C++ libmedia library is not part of the public API. Some people use it, but this is highly discouraged because it might break on some devices and/or in a future Android release.
I developed an audio recording app, and trust me, audio support is very inconsistent across devices, it's very tricky, so IMO using libmedia directly is a bad idea.
Click to expand...
Click to collapse
In case anyone was wondering - pushing older versions of libmedia.so doesn't help anything It just results in a non booting device.
In this case wait for G2 to get Gingerbread? Hehe.
Anderdroid said:
In this case wait for G2 to get Gingerbread? Hehe.
Click to expand...
Click to collapse
I am guessing that will be awhile…
Unless someone else sees something I am missing I am quickly running out of ideas
Sent from my Nexus S using XDA App
krohnjw said:
I am guessing that will be awhile…
Unless someone else sees something I am missing I am quickly running out of ideas
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
well crap... i was really hoping for this to be able to work. hoping so much that i would actually pay for that app!
Once the G2 update to 2.3 drops it should hopefully get done if we can't use this apk with 2.3
Sent from my Nexus S using XDA App
Doesn't the Wifi Calling port require a custom kernel for the n1 to function? Additionally in krohnjw's zip file of the apk and other libraries we're missing the module '/system/lib/modules/kineto_gan.ko' from the n1 "bundle" that was last released. Has anyone been loading this module before launching the Wifi Calling application?
Other thought is that the htc ril that is bundled doesn't have similar functions, but not certain how I could find out.
Just some initial thoughts, going to keep looking into this!
Just thought I'd mention if it isn't known, the Vibrant froyo leaks also contain the WiFi calling.
Pulling apart the apk and the exceptions via logcat I found the offending call. Though I'm still trying to figure out what we need to replace. It is a library issue.
Code:
:try_start_a3
const-string v1, "kineto"
invoke-static {v1}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
:try_end_a8
.catch Ljava/lang/Exception; {:try_start_a3 .. :try_end_a8} :catch_a9
.line 60
:goto_a8
return-void
The part that stands out to me is invoke-static {v1} which would to me...translate into invote-static("kineto"), which of course it cannot find.
Though I'm confused by this as well, I'm not seeing any lib's that are included in the n1 port...I'm probably missing something.
ritcereal said:
Doesn't the Wifi Calling port require a custom kernel for the n1 to function? Additionally in krohnjw's zip file of the apk and other libraries we're missing the module '/system/lib/modules/kineto_gan.ko' from the n1 "bundle" that was last released. Has anyone been loading this module before launching the Wifi Calling application?
Other thought is that the htc ril that is bundled doesn't have similar functions, but not certain how I could find out.
Just some initial thoughts, going to keep looking into this!
Click to expand...
Click to collapse
That was the wrong zip or incomplete. I compiled a kernel with the kineto_gan module as statedvin the op. Works no problem (no errors in dmesg - success messages present) . Module loads successfully.
I'm running this kernel with the module loaded....doesn't make any difference. I can make it available if anyone would like to test.
Sent from my Nexus S using XDA App
Anderdroid said:
Just thought I'd mention if it isn't known, the Vibrant froyo leaks also contain the WiFi calling.
Click to expand...
Click to collapse
I just pulled that (and their version of libkineto.so) from the leaked image - same result, same error.
I'm curious, since wifi calling required libary files and all that jazz, wouldn't it be easier to just route the wifi calling apk through the SIP protocol already in place? That way you can avoid all the kernel and library "mess".
(not too knowledgeable on SIP and/or wifi calling).
I've switched to the Moto X from Windows Phone 8, and after spending a few weeks de-bloating the damn thing I'm pretty happy with it.
However, there are two features I am sorely missing:
1. On my HTC 8X, whenever I had received a text message and I picked up the phone, the screen would automatically turn on. I know that stock the Moto X came with active notifications which is kind of the same, but I removed it because it meant I had to unlock the screen and then enter my PIN, as opposed to just entering my pin. Does Android have any built-in functionality to automatically turn on the display when a new text message comes in?
2. Similar to the previous point, when I got a new text message on Windows Phone 8, the sender and the first few words of the message would be briefly displayed across the top of the screen. Android doesn't seem to have that, but what would be really useful is if I could access my notifications drawer while the phone was still locked, so I could see who had emailed or messaged me, and then take the appropriate action. Is there a way to enable something similar to this?
1. No, you got rid of it.
2. It shows the preview of the text in active display, and in the notification window. The notification window isn't available on the lock screen when you have PIN lock enabled, due to privacy restrictions.
Sent from my XT1058 using XDA Premium 4 mobile app
Under active display options there is a checkbox for more privacy. Have you tried with that unchecked?
Sent from my XT1060 using Tapatalk
He got rid of AD...
Sent from my XT1058 using XDA Premium 4 mobile app
PityOnU said:
I've switched to the Moto X from Windows Phone 8, and after spending a few weeks de-bloating the damn thing I'm pretty happy with it.
However, there are two features I am sorely missing:
1. On my HTC 8X, whenever I had received a text message and I picked up the phone, the screen would automatically turn on. I know that stock the Moto X came with active notifications which is kind of the same, but I removed it because it meant I had to unlock the screen and then enter my PIN, as opposed to just entering my pin. Does Android have any built-in functionality to automatically turn on the display when a new text message comes in?
2. Similar to the previous point, when I got a new text message on Windows Phone 8, the sender and the first few words of the message would be briefly displayed across the top of the screen. Android doesn't seem to have that, but what would be really useful is if I could access my notifications drawer while the phone was still locked, so I could see who had emailed or messaged me, and then take the appropriate action. Is there a way to enable something similar to this?
Click to expand...
Click to collapse
I'd advise installing Go SMS, it gives an option to turn on the screen for an incoming message, and uncheck messaging/go sms under Active Display.
GandalfTehGray said:
I'd advise installing Go SMS, it gives an option to turn on the screen for an incoming message, and uncheck messaging/go sms under Active Display.
Click to expand...
Click to collapse
you can try the dynamicnotifications app from the play store. it has more features than active display but i havent tested it on the moto x.
It seems like the features you desire may be best supplied by active display. I've really been enjoying that feature on my Moto-X.
On my previous phone, I used handcent as a text app, and it has a setting that allows new incoming texts to display in a pop up window. I eventually shut that feature off, as texts would pop up when the phone was in my pocket, and then the screen was active, and all sorts of undesirable screen press issues would happen.
To the OP, I came from an iPhone which worked the same way. I had a nexus 5 first which was a complete PITA, the moto x is better. Turn the Active Display back on!!
sent from my VZW 32GB moto maker X on 4.4
The latest update to "active notificatioins" should address your concern
Motorola just published an update to the "active notifications" app that addressed your concern specifically. Many commands now work without touching the phone. additionally, if you are using the "pin" unlock function, which your post indicates you are, you can even speak your pin to access the remaining functions. As I understand the update, the only actions that now require a pin are ones that show your personal information. but being able to speak your pin is a nice feature when driving if your car stereo does not have bluetooth authentication.
Wow, thanks for all the great suggestions, guys! I never expected this thread to get this much attention.
After using the phone for the past week or so, I find that I am in agreement with the majority of you that I should keep Active Display on my phone. I am amazed that a feature as basic as this had not already been built into the functionality of the base Android OS.
Would anyone happen to know the .apk's needed to get Active Display back up and running on my Moto X? I have backups of all the system apps, but am not sure which files I should restore. I know that "AonInt.apk" is part of, but not the whole, story.
stevetsimmons.com said:
Motorola just published an update to the "active notifications" app that addressed your concern specifically. Many commands now work without touching the phone. additionally, if you are using the "pin" unlock function, which your post indicates you are, you can even speak your pin to access the remaining functions. As I understand the update, the only actions that now require a pin are ones that show your personal information. but being able to speak your pin is a nice feature when driving if your car stereo does not have bluetooth authentication.
Click to expand...
Click to collapse
That's Touchless Control, not Active Notifications.
PityOnU said:
Wow, thanks for all the great suggestions, guys! I never expected this thread to get this much attention.
After using the phone for the past week or so, I find that I am in agreement with the majority of you that I should keep Active Display on my phone. I am amazed that a feature as basic as this had not already been built into the functionality of the base Android OS.
Would anyone happen to know the .apk's needed to get Active Display back up and running on my Moto X? I have backups of all the system apps, but am not sure which files I should restore. I know that "AonInt.apk" is part of, but not the whole, story.
Click to expand...
Click to collapse
You got rid of the app completely? You know you could have just disabled Active Notifications from the settings menu, right?
freak4dell said:
You got rid of the app completely? You know you could have just disabled Active Notifications from the settings menu, right?
Click to expand...
Click to collapse
Right, but I wanted it removed completely, so I wiped it out. Mobile devices have limited resources, and I want to conserve mine as much as possible.
In any case, I've found that
Code:
AonInt.apk
&
Code:
AonInt.odex
are the system service that runs in the background for catching notifications, and
Code:
Aon.apk
and
Code:
Aon.odex
are the actual functional parts of the notification screen.
It's still suffering from an error and force quitting, though. Here is the dump from DDMS:
Code:
12-23 18:26:40.726: E/qdexternal(283): writeHPDOption: state file '/sys/devices/virtual/graphics/fb-1/hpd' not found : ret-1 err str: No such file or directory
12-23 18:26:40.888: E/AndroidRuntime(12891): FATAL EXCEPTION: main
12-23 18:26:40.888: E/AndroidRuntime(12891): Process: com.motorola.aon, PID: 12891
12-23 18:26:40.888: E/AndroidRuntime(12891): java.lang.RuntimeException: Unable to create service com.motorola.aon.pd.AonServiceBreath: java.lang.SecurityException: Not allowed to bind to service Intent { act=com.motorola.aon.env.INTERFACE pkg=com.motorola.aon.env }
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2590)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.access$1700(ActivityThread.java:139)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1493)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.os.Handler.dispatchMessage(Handler.java:102)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.os.Looper.loop(Looper.java:137)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.main(ActivityThread.java:5083)
12-23 18:26:40.888: E/AndroidRuntime(12891): at java.lang.reflect.Method.invokeNative(Native Method)
12-23 18:26:40.888: E/AndroidRuntime(12891): at java.lang.reflect.Method.invoke(Method.java:515)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:777)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:593)
12-23 18:26:40.888: E/AndroidRuntime(12891): at dalvik.system.NativeStart.main(Native Method)
12-23 18:26:40.888: E/AndroidRuntime(12891): Caused by: java.lang.SecurityException: Not allowed to bind to service Intent { act=com.motorola.aon.env.INTERFACE pkg=com.motorola.aon.env }
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1701)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ContextImpl.bindService(ContextImpl.java:1665)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.content.ContextWrapper.bindService(ContextWrapper.java:517)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.motorola.aon.AonService.requestRebind(AonService.java:407)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.motorola.aon.AonService.onCreate(AonService.java:443)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.motorola.aon.pd.AonServiceBreath.onCreate(AonServiceBreath.java:183)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2580)
12-23 18:26:40.888: E/AndroidRuntime(12891): ... 10 more
Any ideas what I am still missing? I think it's a provider of some sort from Motorola specific security settings, but I'm not certain. I'll have to dig around some more...
I'm not sure if this helps, but Motorola posted all of their special features to the play store. Also regarding the unlock, you can create a trusted bluetooth device that will disable your pin. Basically if your phone is in range of said device (car, headset, whatever), you don't need to enter a pin.
PityOnU said:
Right, but I wanted it removed completely, so I wiped it out. Mobile devices have limited resources, and I want to conserve mine as much as possible.
In any case, I've found that
Code:
AonInt.apk
&
Code:
AonInt.odex
are the system service that runs in the background for catching notifications, and
Code:
Aon.apk
and
Code:
Aon.odex
are the actual functional parts of the notification screen.
It's still suffering from an error and force quitting, though. Here is the dump from DDMS:
Code:
12-23 18:26:40.726: E/qdexternal(283): writeHPDOption: state file '/sys/devices/virtual/graphics/fb-1/hpd' not found : ret-1 err str: No such file or directory
12-23 18:26:40.888: E/AndroidRuntime(12891): FATAL EXCEPTION: main
12-23 18:26:40.888: E/AndroidRuntime(12891): Process: com.motorola.aon, PID: 12891
12-23 18:26:40.888: E/AndroidRuntime(12891): java.lang.RuntimeException: Unable to create service com.motorola.aon.pd.AonServiceBreath: java.lang.SecurityException: Not allowed to bind to service Intent { act=com.motorola.aon.env.INTERFACE pkg=com.motorola.aon.env }
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2590)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.access$1700(ActivityThread.java:139)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1493)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.os.Handler.dispatchMessage(Handler.java:102)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.os.Looper.loop(Looper.java:137)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.main(ActivityThread.java:5083)
12-23 18:26:40.888: E/AndroidRuntime(12891): at java.lang.reflect.Method.invokeNative(Native Method)
12-23 18:26:40.888: E/AndroidRuntime(12891): at java.lang.reflect.Method.invoke(Method.java:515)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:777)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:593)
12-23 18:26:40.888: E/AndroidRuntime(12891): at dalvik.system.NativeStart.main(Native Method)
12-23 18:26:40.888: E/AndroidRuntime(12891): Caused by: java.lang.SecurityException: Not allowed to bind to service Intent { act=com.motorola.aon.env.INTERFACE pkg=com.motorola.aon.env }
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1701)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ContextImpl.bindService(ContextImpl.java:1665)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.content.ContextWrapper.bindService(ContextWrapper.java:517)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.motorola.aon.AonService.requestRebind(AonService.java:407)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.motorola.aon.AonService.onCreate(AonService.java:443)
12-23 18:26:40.888: E/AndroidRuntime(12891): at com.motorola.aon.pd.AonServiceBreath.onCreate(AonServiceBreath.java:183)
12-23 18:26:40.888: E/AndroidRuntime(12891): at android.app.ActivityThread.handleCreateService(ActivityThread.java:2580)
12-23 18:26:40.888: E/AndroidRuntime(12891): ... 10 more
Any ideas what I am still missing? I think it's a provider of some sort from Motorola specific security settings, but I'm not certain. I'll have to dig around some more...
Click to expand...
Click to collapse
I'm trying to load in a static XSharedPreferences instance in a separate class via
Code:
private static XSharedPreferences prefs = new XSharedPreferences(BuildConfig.PACKAGE_NAME);
Everything compiles, but at runtime I'm given:
Code:
09-27 08:59:26.929 24976-24976/com.versobit.kmark.xhangouts E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: com.versobit.kmark.xhangouts, PID: 24976
java.lang.NoClassDefFoundError: de.robv.android.xposed.XSharedPreferences
at com.versobit.kmark.xhangouts.XApp.<clinit>(XApp.java:33)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1208)
at android.app.Instrumentation.newApplication(Instrumentation.java:990)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:509)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4446)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at android.app.ActivityThread.handleBindApplication(Native Method)
at android.app.ActivityThread.access$1500(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1265)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5146)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:732)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:566)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at dalvik.system.NativeStart.main(Native Method)
Been at this for four or five hours and I'm out of ideas. I'm correctly providing the BridgeApi file in my gradle build. I've even tried loading in the jar manually and using reflection, but that doesn't seem to work properly. The class will load but nothing is read.
Are you trying to import that in a non Xposed class? AFAIK, it'll only work for classes loaded by Xposed.
GermainZ said:
Are you trying to import that in a non Xposed class? AFAIK, it'll only work for classes loaded by Xposed.
Click to expand...
Click to collapse
Yep. That's unfortunate. I was under the false impression that Xposed injected itself into every class loader context. It does modify the system classpath but that doesn't seem to have any effect on Dalvik apps. Here's my long-winded solution.
Thanks for the help.
Kevin M said:
Yep. That's unfortunate. I was under the false impression that Xposed injected itself into every class loader context. It does modify the system classpath but that doesn't seem to have any effect on Dalvik apps. Here's my long-winded solution.
Thanks for the help.
Click to expand...
Click to collapse
For what's it's worth, pretty much all modules use MAKE_WORLD_READABLE. IIRC, XSharedPreferences also has a helper to set that if it isn't already.
Edit: also, XSharedPreferences isn't very different from SharedPreferences. From memory, the only differences are a few extra helpers and read only support.
GermainZ said:
For what's it's worth, pretty much all modules use MAKE_WORLD_READABLE. IIRC, XSharedPreferences also has a helper to set that if it isn't already.
Click to expand...
Click to collapse
I found the usage of WORLD_READABLE common while looking around for ideas, but didn't notice the helper function somehow, after pouring over the source. Now that I'm looking at it again my concern is that the XSharedPreferences instance is running with the same permissions as my module, which certainly doesn't have the permissions required to chmod files owned by other users when running in the hooked process.
Kevin M said:
I found the usage of WORLD_READABLE common while looking around for ideas, but didn't notice the helper function somehow, after pouring over the source. Now that I'm looking at it again my concern is that the XSharedPreferences instance is running with the same permissions as my module, which certainly doesn't have the permissions required to chmod files owned by other users when running in the hooked process.
Click to expand...
Click to collapse
Wouldn't you be able to get (or create) an instance of SharedPreferences and edit what you want in that case, though?
Or get a Context and use that if it's not a preference file you're interested in.
GermainZ said:
Wouldn't you be able to get (or create) an instance of SharedPreferences and edit what you want in that case, though?
Or get a Context and use that if it's not a preference file you're interested in.
Click to expand...
Click to collapse
Unless I have a Context to my own application when my hook is running I don't see that working. The only time a Context to my app would even be alive would be when the PreferenceActivity was loaded. When my hook is running it's running inside the other application's process so I can't just spawn a SharedPreference to what is now a foreign resource.
Kevin M said:
Unless I have a Context to my own application when my hook is running I don't see that working. The only time a Context to my app would even be alive would be when the PreferenceActivity was loaded. When my hook is running it's running inside the other application's process so I can't just spawn a SharedPreference to what is now a foreign resource.
Click to expand...
Click to collapse
Ah, I misunderstood what you wanted. Basically I'd do something like this:
If I'm trying to access the hooked app's files, get a Context from the hooked app.
If I'm trying to access my own app's files, get a Context from the hooked app then use IPC (e.g. a BroadcastReceiver for my app, and use Context.sendBroadcast() from the hooked app).
I think you want the second but that's what you're doing currently if I'm not mistaken.
GermainZ said:
Ah, I misunderstood what you wanted. Basically I'd do something like this:
If I'm trying to access the hooked app's files, get a Context from the hooked app.
If I'm trying to access my own app's files, get a Context from the hooked app then use IPC (e.g. a BroadcastReceiver for my app, and use Context.sendBroadcast() from the hooked app).
I think you want the second but that's what you're doing currently if I'm not mistaken.
Click to expand...
Click to collapse
Yep, just used a ContentProvider/Resolver instead. :good:
com.android.server.*
I know that these classes have to be hooked in handleLoadPackage for lpparam.packageName == "android", but sometimes there are several processes ("system:ui" for example) that contain this package and hooks fail even from handleLoadPackage.
Now I'm using this code, is it correct?
Code:
if (lpparam.packageName.equals("android") && lpparam.processName.equals("android")) { ... }
Resource hooks
They are just not working. Well, most of them. Using fwd or DrawableLoader doesn't matter. No errors shown in log. It's not just a problem with some packages. Status bar icons, action bar icons, etc, etc - I can't replace 90% of them, exact same hooks were working on Kit Kat.
For example, png drawable is used only in manifest and in actionbar ( actionbar.setIcon(iconResId) ). With a hook this icon is replaced in launcher, but not in actionbar.
Code:
Starting Xposed binary version 60, compiled for SDK 21
Phone: HTC One (HTC), Android version 5.0.2 (SDK 21)
ROM: LRX22G release-keys
Build fingerprint: htc/htc_europe/m7:5.0.2/LRX22G/482424.2:user/release-keys
Platform: armeabi-v7a, 32-bit binary, system server: yes
SELinux enabled: yes, enforcing: no
Mikanoshi said:
Resource hooks
They are just not working. Well, most of them. Using fwd or DrawableLoader doesn't matter. No errors shown in log. It's not just a problem with some packages. Status bar icons, action bar icons, etc, etc - I can't replace 90% of them, exact same hooks were working on Kit Kat.
For example, png drawable is used only in manifest and in actionbar ( actionbar.setIcon(iconResId) ). With a hook this icon is replaced in launcher, but not in actionbar.
Click to expand...
Click to collapse
Noticed that as well. Some resources can be replaced, others it's like they're just silently ignored. I'm guessing maybe the ART optimizations are the culprit?
There's a thread about it here. I'm sure @rovo89 will chime in when he's had time to take a look. As a workaround, you could always find the method that's setting the original drawable and replace it there; that seems to work for me in most cases.
Mikanoshi said:
com.android.server.*
I know that these classes have to be hooked in handleLoadPackage for lpparam.packageName == "android", but sometimes there are several processes ("system:ui" for example) that contain this package and hooks fail even from handleLoadPackage.
Now I'm using this code, is it correct?
Code:
if (lpparam.packageName.equals("android") && lpparam.processName.equals("android")) { ... }
Click to expand...
Click to collapse
So you're saying that there are situations with lpparam.packageName == "android" and lpparam.processName <> "android"? That would explain a couple of other issues. If you could find out a good way to reproduce this, it could be quite helpful.
Depending on the situation, I will have to see how to handle it. Checking for package name "android" is a pretty common pattern to ensure you're in the system server (which I even recommend myself!), so ideally it should stay correct even without the additional checks you suggested.
rovo89 said:
So you're saying that there are situations with lpparam.packageName == "android" and lpparam.processName <> "android"? That would explain a couple of other issues. If you could find out a good way to reproduce this, it could be quite helpful.
Depending on the situation, I will have to see how to handle it. Checking for package name "android" is a pretty common pattern to ensure you're in the system server (which I even recommend myself!), so ideally it should stay correct even without the additional checks you suggested.
Click to expand...
Click to collapse
I've seen only "system:ui" process name, it tries to search for classes in XposedBridge.jar only and of course fails.
Occurrences are very inconsistent, I install modules from Eclipse and then soft reboot like 50 times a day, and this bug happens 2 or 3 times. Not a big problem though, it just clutters Xposed log
I also have a lot of problems with installing apk via adb, it either throws an excpetion and doesn't install
Code:
ActivityManager: java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String) (tried Java_android_os_SystemProperties_native_1get and Java_android_os_SystemProperties_native_1get__Ljava_lang_String_2)
ActivityManager: at android.os.SystemProperties.native_get(Native Method)
ActivityManager: at android.os.SystemProperties.get(SystemProperties.java:52)
ActivityManager: at com.htc.customization.HtcCustomizationManager.<init>(HtcCustomizationManager.java:65)
ActivityManager: at com.htc.customization.HtcCustomizationManager.<clinit>(HtcCustomizationManager.java:60)
ActivityManager: at android.os.Environment$UserEnvironment.getCustomizationReader(Environment.java:523)
ActivityManager: at android.os.Environment$UserEnvironment.isDynamicSwitchSupported(Environment.java:534)
ActivityManager: at android.os.Environment$UserEnvironment.<init>(Environment.java:222)
ActivityManager: at android.os.Environment.initForCurrentUser(Environment.java:142)
ActivityManager: at android.os.Environment.<clinit>(Environment.java:136)
ActivityManager: at android.os.Environment.getLegacyExternalStorageDirectory(Environment.java:726)
ActivityManager: at android.os.Debug.<clinit>(Debug.java:96)
ActivityManager: at android.ddm.DdmHandleHello.handleHELO(DdmHandleHello.java:164)
ActivityManager: at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:91)
ActivityManager: at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
ActivityManager: java.lang.UnsatisfiedLinkError: android.os.Debug
ActivityManager: at android.ddm.DdmHandleHello.handleFEAT(DdmHandleHello.java:176)
ActivityManager: at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:93)
ActivityManager: at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
ActivityManager: java.lang.UnsatisfiedLinkError: android.os.Debug
ActivityManager: at android.ddm.DdmHandleProfiling.handleMPRQ(DdmHandleProfiling.java:215)
ActivityManager: at android.ddm.DdmHandleProfiling.handleChunk(DdmHandleProfiling.java:106)
ActivityManager: at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
or installs but fails to launch until (soft) reboot:
Code:
I/ActivityManager(15637): Process name.mikanoshi.icecontrol (pid 27200) has died
I/ActivityManager(15637): Start proc name.mikanoshi.icecontrol for activity name.mikanoshi.icecontrol/.Settings: pid=27233 uid=10343 gids={50343, 9997} abi=armeabi-v7a
I/art(27233): Late-enabling -Xcheck:jni
W/art(27233): Failed to find OatDexFile for DexFile /data/app/name.mikanoshi.icecontrol-2/base.apk ( canonical path /data/app/name.mikanoshi.icecontrol-2/base.apk) with checksum 0x7991961b in OatFile /data/dalvik-cache/arm/[email protected]@[email protected]@classes.dex
D/Process(15637): killProcessQuiet, pid=27233
No idea if Lollipop or Xposed problem
rovo89 said:
So you're saying that there are situations with lpparam.packageName == "android" and lpparam.processName <> "android"? That would explain a couple of other issues. If you could find out a good way to reproduce this, it could be quite helpful.
Depending on the situation, I will have to see how to handle it. Checking for package name "android" is a pretty common pattern to ensure you're in the system server (which I even recommend myself!), so ideally it should stay correct even without the additional checks you suggested.
Click to expand...
Click to collapse
Yes, I can confirm this seems to be the case. Haven't got a chance to debug which process comes with packageName == "android" apart from "android" process itself, but when that happens, classLoader cannot find classes that are typically available within "android" package, which is logical. The other process that has packageName "android" is something else with no access to those classes.
Oh, and rarely soft reboot after module activation ends like this
Code:
E/Xposed(10834): Error -32 while adding app service user.xposed.app
E/Xposed(10822): Zygote service is not running, Xposed cannot work without it
I would like to concentrate on the bigger issues first. Yours can probably be solved by another reboot.
So after some research, grepping the AOSP code and so on, it seems that the "system:ui" process is only used by the PackageManagerService. Maybe more will follow in the future. For some reason, the process seems to be called "android:ui" though once it has been started. It's running with UID 1000, but in the system_app SELinux context.
I would like to understand some more things about this before making a decision. It seems that there can now indeed be processes with package name "android" that aren't the system_server. Without breaking existing modules, I think I could only block handleLoadPackage() for these. Maybe it would also make sense to add a new handleLoadSystemServer() method. That would avoid the need for checks, especially if only system services are hooked. For backward-compatiblity, handleLoadPackage() could still be called for package "android", but modules would produce error messaages if they don't check the process name. Or there could be a compatiblity break at this point, requiring all modules that hook system services to adopt the new API.
I don't mind checks Almost every module that hooks system classes requires an update for 5.0 anyway.
Huge issues for me now are broken resource hooks and problems with installing apks (sometimes it takes 3-5 tries to install and then soft reboot just to test interface changes).
Most likely, this is the reason why the ChooserActivity runs in the "android:ui" process now:
https://github.com/android/platform...40#diff-30afe08a44bf548c7cc9116a473f8bdfL2798
It used to declare multiprocess=true, which meant that the activity was started in the caller's process. Now it's started in a separate process, where ":ui" is relative to the package name, not the applications's default process name (that would be "system").
There are also other activities with similar attributes defined, even in KitKat. If someone has a bit of time at their hands, they could try to check whether handleLoadPackage() is also called for package == "android" and process != "android" on KitKat ROMs for those other activities. It wouldn't be as noticable as it is on Lollipop because the system services that most modules hook there were available with the boot class path.
Anyway, now we know that there are legitimate usages of the "android" package for other things than the system_server. These usages are very limited though. The activities use the boot classloader, so hooking methods from initZygote() would (still) work for them. What if I set the packageName for these apps to "system" instead? So modules checking for "android" as package name could be sure it's the system_server then. Modules which need to do something for the android:ui process could simply check for "system" as package name. Any complaints?
Good solution... Ship it
But I believe majority of actively developed modules are already fixed for this specific case.
rovo89 said:
Most likely, this is the reason why the ChooserActivity runs in the "android:ui" process now:
https://github.com/android/platform...40#diff-30afe08a44bf548c7cc9116a473f8bdfL2798
It used to declare multiprocess=true, which meant that the activity was started in the caller's process. Now it's started in a separate process, where ":ui" is relative to the package name, not the applications's default process name (that would be "system").
There are also other activities with similar attributes defined, even in KitKat. If someone has a bit of time at their hands, they could try to check whether handleLoadPackage() is also called for package == "android" and process != "android" on KitKat ROMs for those other activities. It wouldn't be as noticable as it is on Lollipop because the system services that most modules hook there were available with the boot class path.
Anyway, now we know that there are legitimate usages of the "android" package for other things than the system_server. These usages are very limited though. The activities use the boot classloader, so hooking methods from initZygote() would (still) work for them. What if I set the packageName for these apps to "system" instead? So modules checking for "android" as package name could be sure it's the system_server then. Modules which need to do something for the android:ui process could simply check for "system" as package name. Any complaints?
Click to expand...
Click to collapse
Great idea, no complaints here.
Whike fixing this, maybe you can try to look why appInfo is null for "android" package.
pyler said:
Whike fixing this, maybe you can try to look why appInfo is null for "android" package.
Click to expand...
Click to collapse
That's very simple to answer: https://github.com/rovo89/XposedBri...de/robv/android/xposed/XposedBridge.java#L245
There's simply no ApplicationInfo object (yet), it's constructed later when the PackageManagerService is running. I could construct a fake object, but there are hardly any fields that could be filled with proper values.
atleast flags field could be filled, or not? just do copy of real object for android, which any normal app can get.
since we talk about this, is this doable or Xposed starts too soon for these values?
rovo89 said:
What if I set the packageName for these apps to "system" instead?
Click to expand...
Click to collapse
Old modules which use "android" are incompatible...
To be compatible i have then to check "system" and "android" - this is not better than check for package& process name
system is for *:ui processes and we mostly care about android only.
pyler said:
system is for *:ui processes and we mostly care about android only.
Click to expand...
Click to collapse
Who is "we" and whats the source of "mostly"
I have to say that i'm using "android" for <21 and so it seems i have to use different package names depending on Xposed version
pyler said:
atleast flags field could be filled, or not? just do copy of real object for android, which any normal app can get.
since we talk about this, is this doable or Xposed starts too soon for these values?
Click to expand...
Click to collapse
"real object for android" => you mean the one that I said doesn't exist at the time the system_server is starting up, as the PackageManagerService is not running yet?
No idea about your other suggestion, I'm currently looking mainly into crashes etc., API extensions have to wait...
defim said:
I have to say that i'm using "android" for <21 and so it seems i have to use different package names depending on Xposed version
Click to expand...
Click to collapse
I was talking about "other things than the system_server", i.e. the process for ChooserActivity etc. This process is hardly used, I'm not even sure if it existed in previous versions. Only for this process, the package name is faked to be "system". The system_server, which is way more widely used, will keep package name "android". So I don't expect a single module to break.
If no update for older modules is needed its great :good:
can i use it on samsung device running cm 12
can i use it on samsung device running cm 12
Hello,
I've succeeded to hook method that gives me the accelerometer events.
so now all the application which use the accelerometer are generating events.
I wanted to send all those events from the hooking method to a service using intents that will aggregate them
and write them into a sqlite db (the db is not relevant for now, only the service).
The problem is that i can't start the intentService from the hook method.
Things that i tried already:
-- getting the Context from the activity on load by hooking the onStart in the Activity.class (succeeded getting the context but not starting the Service with an intent)
-- using the same context as above but start a broadcast receiver with implicit intent (define intent-filter in the manifest), and from the
broadcast to start the service (not worked either, the broadcast never got the sent message)
is there some guide or tutorial that can show me how to start a service or broadcast receiver from the hook method?
thanks ahead...
- make sure your service is defined in the manifest
- instead of IntentService, consider using standard service to which you can bind using context.bindService together with ServiceConnection object (see developer.android.com). You can use messenger approach for data exchange. This would be more efficient in your case.
As an example, I am using that approach in the following scenario:
I need to process screenshot taken during screen off in DisplayPowerController using my application context as I need to write image file within my module's filesDir
- I have a service within my module that receives image data and writes them to a file.
- I am binding to this service using bindService from within DisplayPowerController. It sends image data in chunks.
See this commit for more info:
https://github.com/GravityBox/GravityBox/commit/ad09553eaf0c669c4dcb8233a6b9706d1d939761
Call from other app context
First thanks for your answer,
Just to make it clear lets say i don't have any application,
i want to make some monitoring module on my phone which record all the Accelerometer events
request by different apps installed on my phone.
So there is general hook that tracking all the Accelerometer events, but when from those apps
or hook (the apps not mine but some apps i downloaded from the google play store), i want to
start a service or broadcast using their app context (taken from the activity or something).
The broadcast or service will not start (i think something with sandbox or that the apps and the service are not under the same context)
**that what i understood, maybe it's just some mistake in my code**
For example that some test i made:
Main Hook class:
public class TestHook implements IXposedHookLoadPackage{
@override
public void handleLoadPackage(LoadPackageParam lpparam) throws Throwable {
XposedBridge.hookAllMethods(Activity.class,"onStart", new XC_MethodHook()
{
@override
protected void beforeHookedMethod(MethodHookParam param)
throws Throwable {
Context context = (Context)param.thisObject;
if(context != null){
XposedBridge.log("sending brod...");
context.sendBroadcast(new Intent("com.example.logging"));
} else {
XposedBridge.log("not sending");
}
}
});
}
}
The receiver:
public class BrodTest extends BroadcastReceiver{
@override
public void onReceive(Context context, Intent intent) {
// TODO Auto-generated method stub
Toast.makeText(context, "Got BroadCast", Toast.LENGTH_LONG).show();
}
}
and the manifest:
<manifest xmlns:android=
package="com.example.testproject"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="14"
android:targetSdkVersion="19" />
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<receiver android:name=".BrodTest">
<intent-filter>
<action android:name="com.example.logging"/>
</intent-filter>
</receiver>
<!--Declaration of the Xposed framework -->
<meta-data
android:name="xposedmodule"
android:value="true" />
<meta-data
android:name="xposedminversion"
android:value="30+" />
<meta-data android:name="xposeddescription"
android:value="Recording Sensors and Transmission events"/>
</application>
</manifest>
just tried to make some hook that will send to broadcast and show Toast message...
Thanks again...
I don't see anything wrong with the code. It should work.
Do you get a log message that the broadcast was sent?
Exported receiver?
Receiver log
The log shows me the sending message to the receiver so i know i have the context correctly,
and i at first put my broadcast exported to false, but than i thought about permissions problem
so i deleted the exported attribute for being exported=true by default..
bottom line, i see the logs messages but not the toast that the receiver should show me...
if there is any other suggestions i be grateful,
thx
Try creating a different receiver with a different class name. Try using fully qualified class name. Also make sure to change intent action string for a new one. Use something more standard like "testproject.intent.action.LOGGING".
Maybe something got messed up while you were changing receiver properties.
This info from doc is interesting:
android:name
Once you publish your application, you*should not change this name*(unless you've setandroid:exported="false").
Click to expand...
Click to collapse
Regarding "exported" attribute. Safely omit it as it defaults to true automatically when you have intent-filter defined.
And maybe also try Log.d() instead of toast and check logcat.
Log.d
about the Log.d you suggested, when i run even with debug mode from eclipse and install the new module
its require me to restart the phone first, how can i debug like normal application?
when i restart the phone the adb is closed and i loose the debugging ability?
thanks anyway i will try it out...
Use adb logcat from command line.