Related
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).
Lollipop: module crashes ART with "JNI ERROR: local reference table overflow"
@rovo89
I'm testing my BubbleUPnP module with the Lollipop alpha.
Among other things it hooks AudioTrack and in particular the write() method to capture audio.
write() is called repeatedly by processes playing audio. After a few calls, ART crashes with "JNI ERROR(app bug) : local reference table overflow" as shown in the attached logcat. Googling this error returns quite a bit of info and points to missing DeleteLocalRef() calls for local variables.
Below the JNI_ERROR in the attached logcat , there's a very long stack trace with repeated calls but I'm not sure how to interpret it (does it point to some form of infinite recursion, possibly causing the crash?). The same module works fine on KitKat Xposed.
If you are interested with a modified BubbleUPnP module (the repository one doesn't work) to reproduce this crash and instructions, let me know.
I found the culprit, which is...:
XposedBridge.invokeOriginalMethod()
It seems that beside calling the original method, it also calls the hooks on that method, leading to infinite recursion (it did not do that prior Lollipop).
I've tested an alternate implementation for calling the original method (without the hooks), and that works.
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
I recorded 4 separate videos today using the Google Camera. When I went to play them back the first 20 or so seconds were just a still image with audio then it went into a normal video. My Google Camera app is set to 1080p quality. On every media player the video won't let you skip to any point and just resets back to 0:00 if you try to fast forward.
I've seen this with incomplete downloaded videos but I dont know why this is happening when I record a video.
Nexus 6, 7.1.2 (NitrogenOS), FKernel, and latest Google Camera app.
Just tried a few other camera apps, including OpenCamera, and every video has the first about 17 seconds with a still image. It's happening with every camera app. Going to try a different kernel then a clean rom install later on. Kernel settings were changed to Performance for these tests.
How do I diagnose why my videos are recording with a still picture with audio for the first multiple seconds?
xNotta said:
...
How do I diagnose why my videos are recording with a still picture with audio for the first multiple seconds?
Click to expand...
Click to collapse
I'd start with a logcat.
If you haven't, clear the cache on the camera app and cache and dalvik in recovery.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
I'd start with a logcat.
If you haven't, clear the cache on the camera app and cache and dalvik in recovery.
Click to expand...
Click to collapse
I used [Root]alogcat to save my logcat and attached it here.
What I did: Opened the stock camera (already in video mode) pressed record, waited 1minute 1 second, stopped, saved logcat.
I tried it again using Android Device Monitor from the sdk and filtered by level: warn and the word camera.
I found this but no idea how to make sense of it.
Code:
01-16 20:59:18.326: W/Camera2-Parameters(748): initialize: Camera 0: Unknown preview format: 24
01-16 20:59:18.326: W/Camera2-Parameters(748): initialize: Camera 0: Unknown preview format: 25
01-16 20:59:21.258: W/View(5520): requestLayout() improperly called by com.android.camera.widget.FilmstripView{6b9ef5f V.ED..... ......ID 0,0-2392,1440 #7f0e0023 app:id/filmstrip_view} during layout: running second layout pass
01-16 20:59:23.050: E/mm-camera-intf(748): mm_camera_poll_thread_del_poll_fd: invalid handler 84992 (0)
01-16 20:59:23.051: E/mm-camera-img(764): faceproc_save_album: cannot open file name: /data/camera/fdAlbum
01-16 20:59:23.119: E/mm-camera-intf(748): mm_camera_poll_thread_del_poll_fd: invalid handler 85504 (0)
01-16 20:59:23.154: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 84737
01-16 20:59:23.154: E/QCamera3Channel(748): virtual int32_t qcamera::QCamera3PicChannel::stop(): Attempt to stop inactive channel
01-16 20:59:23.161: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 85250
01-16 20:59:23.161: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 84224
01-16 21:00:25.440: E/mm-camera-intf(748): mm_camera_poll_thread_del_poll_fd: invalid handler 86528 (0)
01-16 21:00:25.442: E/mm-camera-img(764): faceproc_save_album: cannot open file name: /data/camera/fdAlbum
01-16 21:00:25.445: E/mm-camera-intf(748): mm_camera_poll_thread_del_poll_fd: invalid handler 87552 (0)
01-16 21:00:25.492: E/mm-camera-intf(748): mm_camera_poll_thread_del_poll_fd: invalid handler 87040 (0)
01-16 21:00:25.509: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 86273
01-16 21:00:25.510: E/QCamera3Channel(748): virtual int32_t qcamera::QCamera3PicChannel::stop(): Attempt to stop inactive channel
01-16 21:00:25.513: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 87299
01-16 21:00:25.517: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 86786
01-16 21:00:25.517: E/QCamera3Channel(748): virtual qcamera::QCamera3Channel::~QCamera3Channel(): deleting channel 85760
01-16 21:00:25.530: E/BufferItemConsumer(756): [StageFright-CameraSource] Failed to release buffer: Unknown error -1 (1)
01-16 21:00:25.531: E/BufferItemConsumer(756): [StageFright-CameraSource] Failed to release buffer: Unknown error -1 (1)
01-16 21:00:25.531: E/BufferItemConsumer(756): [StageFright-CameraSource] Failed to release buffer: Unknown error -1 (1)
01-16 21:00:35.732: W/View(5520): requestLayout() improperly called by com.android.camera.widget.FilmstripView{6b9ef5f V.ED..... ......ID 0,0-1440,2451 #7f0e0023 app:id/filmstrip_view} during layout: running second layout pass
What version camera app are you using? The google camera, right? The version starts with a 4 or a 5?
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
What version camera app are you using? The google camera, right? The version starts with a 4 or a 5?
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Click to expand...
Click to collapse
It is Google Camera 4.2.035.141213305 (the last version before it went Arm64). But this video issue is occurring with all camera apps; including the stock rom camera and 3rd party apps.
This has to be a rom issue or a hardware issue. When I get 4-6 hours straight free, I'm going to go back to locked stock then to lineageos 14.1. I really hate how long it takes for me to switch roms.
Any idea outside of having to switch roms?
I think I have the same issue. It began like a week (or two?) ago. I'm running the latest LineageOS and Franco kernel. I have a feeling the kernel is the cause since we have the same. Do you have the latest r75 version?
If I play the recorded video with MX player it plays it in slowmotion.
Video recording is fine just after I reboot.
I found this post in the Franco thread https://forum.xda-developers.com/ne...-kernel-r1-t2987173/post75106251#post75106251
xNotta said:
It is Google Camera 4.2.035.141213305 (the last version before it went Arm64). But this video issue is occurring with all camera apps; including the stock rom camera and 3rd party apps.
This has to be a rom issue or a hardware issue. When I get 4-6 hours straight free, I'm going to go back to locked stock then to lineageos 14.1. I really hate how long it takes for me to switch roms.
Any idea outside of having to switch roms?
Click to expand...
Click to collapse
There is definitely a problem in your log. The errors looked like trying to run camera 3 on a shamu, that's why I asked.
Outside off what I suggested in the first post, only other suggestion is to boot to safe mode. This would reset your setting though. I would try after a nandroid and then you can get back to where you were.
As the above poster commented, if you are using Franco or any third party kernel, post your log in that thread.
If you reflash, do a nandroid so you can get back to where you are easily, then give Beltz a try. Only because I can guarantee the the same camera app you are using is working for me and everyone else.
Do a clean flash (system, cache, dalvik and data - not user data). Use these gapps. This will be a minimal set-up to start. Don't bother doing a big set-up, just get through as a new phone and see if your camera video works then. If not, I'd say it's hardware.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
I downgraded Franco's kernel back to r73. I remember that I had no problems with that version.
So far so good.
IntenseColor said:
I downgraded Franco's kernel back to r73. I remember that I had no problems with that version.
So far so good.
Click to expand...
Click to collapse
I was using francos r75 and having the video recording issue.
Just flashed ElementalX and tried video recording and the issue is gone.
The only thing I did was disabled fkernel app superuser permission in magisk then flashed ElementalX. Tested recording again and it's fixed.
Franco kernel r75 might have been the issue.
I didn't think a kernel could even effect something like video recording to this extent.
Further testing tomorrow but so far every video recording app is working with the ElementalX kernel.
I will try to report my issue to @franciscofranco but it's unlikely they will listen to me in the thread, everyone always gets rude when you bring up a problem.
(Sorry for the typos, I'm trying out Gboard keyboard)
Same issue here on Franco r74. Unfortunately ElementalX does not block some of the bad system wakelocks.
I got both the 9T (for my mom) and the Pro for myself, coming from a Pixel 2.
Because mom's phone arrived quickly, I couldn't help but start using it. After setting it up with all apps, I noticed that Google Assistant wouldn't work and it would randomly show a crash screen for it.
The Pro arrived and I decided to take a slower approach on setting it up. Google Assistant was working fine UNTIL I connected my Pixel Buds to it, and realised that it was the root cause for the issue.
I'm pasting the error report bellow and I was wondering if anyone can help me. I like my Pixel Buds but I'm a heavy Assistant user, so should I not find a solution for this, I'll have to switch headphones.
Thank you!
java.lang.RuntimeException: Unchecked exception happened while running task: call-onReceive
at com.google.android.apps.gsa.shared.util.c.a.ch.run(SourceFile:4)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:201)
at android.app.ActivityThread.main(ActivityThread.java:6882)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)
Caused by: java.util.UnknownFormatConversionException: Conversion = 'End of String'
at java.util.Formatter$FormatSpecifierParser.peek(Formatter.java:2641)
at java.util.Formatter$FormatSpecifierParser.<init>(Formatter.java:2602)
at java.util.Formatter.parse(Formatter.java:2557)
at java.util.Formatter.format(Formatter.java:2504)
at java.util.Formatter.format(Formatter.java:2458)
at java.lang.String.format(String.java:2842)
at com.google.android.apps.gsa.staticplugins.bisto.core.b.a(SourceFile:56)
at com.google.android.apps.gsa.staticplugins.bisto.f.b.a(SourceFile:78)
at com.google.android.apps.gsa.staticplugins.bisto.f.au.run(Unknown Source:19)
at com.google.android.apps.gsa.shared.util.c.a.ci.a(SourceFile:2)
at com.google.android.apps.gsa.shared.util.c.a.ch.run(SourceFile:5)
... 7 more
Use the built-in Feedback app to submit the error directly to Xiaomi.