S4 Mini issues

Question

S4 Mini issues

VolMi opened this issue 11 years ago · 83 comments

This could serve as a thread for issues that are specific for the S4 Mini for which an S-View Cover exists, as well. AFAIK, there are at least three different versions of this device (LTE/3G/Dual SIM).

I have the LTE version which is officially known as the GT-I9195 and on Cyanogenmod as serranoltexx. I started with CM10.2, but now I am on the CM11 nightlies.

It turns out that HallMonitor is really useful on the Mini, too. However, the on and off trigger seems to be firing less reliable than on the big S4. The apk in the master branch is mostly unfunctional, but @Wallace0 has refined the detection so that the hit rate is much better now. Currently I use the apk in the merge branch.

To come up with some real numbers, I opened and closed the cover 20 times, with these results:

	open	close
success	14 (70%)	7 (35%)
fail	6 (30%)	13 (65%)

The last change that introduced a further event refire after 500ms and that Wallace0 mentioned here did not affect the situation noticeably.

The hit rate is strongly dependent on the opening/closing speed: If i move the cover really calmly, everything is fine. Fast motion is especially difficult on close.

Answer 1 · 2013-12-10T15:29:48.000Z

Hi,

I investigated that stock kernel contains code for the magnetic switch included in the cover.

dmesg | grep flip

shows lines like this

<7>[12248.641932] [keys] flip_cover_work : 0
<7>[12248.641932] [keys] flip_cover_work : 1

maybe it's possible to get it working without the approx sensor. not sure how the kernel event is mapped to regular intents.

Answer 2 · 2013-12-10T15:43:26.000Z

Oh, nice find! I see that, too using CM11 and with HallMonitor disabled.

Answer 3 · 2013-12-10T15:59:27.000Z

Currently we are using the magnetic sensor value - we're picking it up from /sys/devices/virtual/sec/sec_key/hall_detect. There doesn't seem to be any intents associated with a state change in the value, so instead we use intents coming from the proximity sensor to trigger action, and then we check for the state of the magnetic sensor to be sure if the cover is closed or not. The 200ms delay which improved things on the S4 mini would simply have allowed for delays in the update to the hall_detect file to be accommodated - a problem that seems much more prevalent on the mini. The fact that it is still not working that great (and thanks @VolMi for the updated details) even with an additional 500ms delay means that probably something else is going on.

I'm a little busy this week, but I'll have a look as soon as I get the chance to see what else we should try to improve it. (though not owning an S4 mini doesn't help!).

Answer 4 · 2013-12-10T16:13:26.000Z

Yep, I found that same event in the logcat during my initial research. As you said, I couldn't find any intents related to it. There must be some udev event (or something) associated with the hall effect sensor firing, because it shows up in the log, but I was unable to figure out how you subscribe to that. But that would most definitely make the triggering more reliable, if we figured out how to do it.

I'm back now from my crazy travel week, so I'll be able to do some more coding.

On Tuesday, December 10, 2013 at 10:59 AM, Wallace0 wrote:

Currently we are using the magnetic sensor value - we're picking it up from /sys/devices/virtual/sec/sec_key/hall_detect. There doesn't seem to be any intents associated with a state change in the value, so instead we use intents coming from the proximity sensor to trigger action, and then we check for the state of the magnetic sensor to be sure if the cover is closed or not. The 200ms delay which improved things on the S4 mini would simply have allowed for delays in the update to the hall_detect file to be accommodated - a problem that seems much more prevalent on the mini. The fact that it is still not working that great (and thanks @VolMi (https://github.com/VolMi) for the updated details) even with an additional 500ms delay means that probably something else is going on.
I'm a little busy this week, but I'll have a look as soon as I get the chance to see what else we should try to improve it. (though not owning an S4 mini doesn't help!).

—
Reply to this email directly or view it on GitHub (#12 (comment)).

Answer 5 · 2013-12-10T16:40:06.000Z

I hope I am not only producing noise due to very superficial knowledge...

Did you already find

#ifdef CONFIG_SENSORS_HALL
        int gpio_flip_cover;
        int irq_flip_cover;
        bool flip_cover;
        struct delayed_work flip_cover_dwork;
#endif

in gpio_keys.c?

It looks like it should be possible to find a related event/intent in the source code itself for more savvy people.

edit:
if you search for all those #ifdef CONFIG_SENSORS_HALL in that file it really looks like all the magic is in there.

Answer 6 · 2013-12-11T15:15:08.000Z

if i'm not mistaken then function hall_detect_show generates the output of /sys/devices/virtual/sec/sec_key/hall_detect.

Answer 7 · 2013-12-12T05:27:43.000Z

I think you're right about that, @habeIchVergessen (also nice to meet you!). The question is, what else happens on a sensor event besides that output being generated, and how do we hook into it? I have a feeling NDK will be required. Maybe grepping around for hall_detect_show can elucidate.

Answer 8 · 2013-12-12T08:02:17.000Z

kernel sided SW_FLIP is similar to SW_HEADPHONE_INSERT defined in input.h. android sided it's redefined in InputManagerService.java and implemented in WiredAccessoryManager.java. for me it doesn't look like NDK. but i know that my development experiences are very low with android.

this could be the hook IntentFilter(Intent.ACTION_USER_SWITCHED).

Answer 9 · 2013-12-12T16:42:42.000Z

We're getting closer... I'm fairly sure ACTION_USER_SWITCHED is not it, that's "switch logged-in user" as opposed to "user pushed hardware switch". One thing I can't figure out is how you actually get an instance of InputManagerService?

Answer 10 · 2013-12-14T08:48:34.000Z

deodex from stock

package com.android.server.input;

import ...;

public class InputManagerService extends IInputManager.Stub
  implements Watchdog.Monitor, DisplayManagerService.InputManagerFuncs
{
  ...
  public static final int SW_FLIP = 21;
  public static final int SW_FLIP_BIT = 2097152;
  public static final int SW_GLOVE = 22;
  public static final int SW_GLOVE_BIT = 4194304;
  ...
}

as assumed getSwitchState reads the magnetic switch

package com.android.server.wm;

import ...;

public class WindowManagerService extends IWindowManager.Stub
  implements DisplayManager.DisplayListener, WindowManagerPolicy.WindowManagerFuncs
, Watchdog.Monitor, DisplayManagerService.WindowManagerFuncs
{
  ...
  public int getCoverState()
  {
    int i = -1;
    try
    {
      int j = this.mInputManager.getSwitchState(-1, -256, 21);
      if (j > 0)
        i = 1;
      do
        return i;
      while (j != 0);
      return 0;
    }
    catch (Exception localException)
    {
      Log.e("WindowManager", "getCoverState(). Can't get cover state!");
    }
    return i;
  }
  ...
}

several files contain an IntentFilter "com.samsung.cover.OPEN". but i can't find any implementation that fires such Intent.

kernel sided /dev/input/event10 handles Volume-, Home-Button and HallSensor.

hexdump -n 16 -C /dev/input/event10

Answer 11 · 2014-03-26T14:51:01.000Z

Hi, I have been doing my own research in the SGS5 kernel source trying to spot any useful information concerning the cover open/close event and then I stumbled upon this discussion.
As correctly mentioned earlier, the driver produces uevents, but the stock android code just ignores them, since the hall sensor is not something default for android phones.
Since all the kernel->userspace event translation/forwarding is done through the InputManagerService, there is no clean way to consume the events.
It seems our only option is to patch InputManagerService so that it produces the correct intents and at least send a PR to CM11, so that we can get it to work there.

Answer 12 · 2014-03-26T17:54:10.000Z

Indeed patching InputManagerService seems like the way to go.

On Wednesday, March 26, 2014 at 10:51 AM, Dimitris Kazakos wrote:

Hi, I have been doing my own research in the SGS5 kernel source trying to spot any useful information concerning the cover open/close event and then I stumbled upon this discussion.
As correctly mentioned earlier, the driver produces uevents, but the stock android code just ignores them, since the hall sensor is not something default for android phones.
Since all the kernel->userspace event translation/forwarding is done through the InputManagerService, there is no clean way to consume the events.
It seems our only option is to patch InputManagerService so that it produces the correct intents and at least send a PR to CM11, so that we can get it to work there.

—
Reply to this email directly or view it on GitHub (#12 (comment)).

Answer 13 · 2014-07-19T15:31:14.000Z

Please check http://review.cyanogenmod.org/#/c/68621/

Answer 14 · 2014-08-08T22:22:04.000Z

I have the 3g version whit cmyanogenmod 11 and I can't use the touch functions on the window from the cover. Please someone help me

Answer 15 · 2014-08-09T11:05:40.000Z

connect your device to pc and run following commands in adb:

echo module_on_master > /sys/class/sec/tsp/cmd && cat /sys/class/sec/tsp/cmd_result
echo clear_cover_mode,3 > /sys/class/sec/tsp/cmd && cat /sys/class/sec/tsp/cmd_result

test touch events with closed cover.

if it works then you have to patch line 205 of Functions.java.

Answer 16 · 2014-08-21T08:03:31.000Z

@kumajaya I am working on a refactor of HallMonitor to be able use integrated system action and/or HallMonitor services.

Answer 17 · 2014-08-23T01:30:13.000Z

tanks for your help habeIchVergessen but i dont really know about this stuff so i dont know too well how to do that.

Answer 18 · 2014-08-26T10:26:23.000Z

next nightly should include flip cover changes

Answer 19 · 2014-08-27T07:48:48.000Z

My version already support it, but not committed now. I will try for this week-end.

Answer 20 · 2014-08-27T12:31:24.000Z

CM-Team made the required changes in android_framework_base.
they added an intent ACTION_LID_STATE_CHANGED ("android.intent.action.LID_STATE_CHANGED") which signals cover open/close events.
~~still not working yet (20140826-Nightly).~~

Answer 21 · 2014-09-03T23:35:10.000Z

Please try my 2.0.0 beta
manusfreedom@fc74f93
I have not tested on last CM 11 (need to update my phone).

Answer 22 · 2014-09-04T00:18:01.000Z

Hi @manusfreedom , downloaded your 2.0 beta version, I'm unable to install it successfully. Tried on a clean install, also tried manually copying the apk to /system/app, however, it sill FC's

Answer 23 · 2014-09-04T08:40:00.000Z

only flash via recovery works.
screen doesn't turn on since CM-Team has added "partial smart cover support" (nightly 2014-08-27).
you have to use WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON.

Answer 24 · 2014-09-04T09:16:14.000Z

Install theough recovery use system app feature, so normally no need of WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON because we wake up all the system like the power button. I think they don't send the LID_OPEN event. So, for now continue to use real hall service.

Answer 25 · 2014-09-04T09:49:19.000Z

tried to install both apk's, but always failed.

LID-OPEN event works properly (see framework test). cm's changeset explicitly enables turn screen on while cover is closed, when the current window use FLAG_TURN_SCREEN_ON. otherwise they don't turn on the screen.

Answer 26 · 2014-09-04T11:03:34.000Z

I am on 20140903-Nightly and their LID system does not always work (and only for close).

Answer 27 · 2014-09-04T12:27:46.000Z

i'm using 2014-08-07-Nigthtly and it works properly. did you tested my "framework test"?
maybe an cross talk with your native code. the apk (installed from zip) only shows up, when cover was opened and screen off when closed. i have to reboot to get access to ui back.

Answer 28 · 2014-09-04T12:42:44.000Z

@habeIchVergessen i have to reboot to get access to ui back (or kill process)=> It’s a bug to keep a single instance, try last version commited.

Answer 29 · 2014-09-04T13:13:38.000Z

as mentioned before: installation failed!
and yes kill would be an option but requires access to ui!

HallMonitor/cm_certs/zip/common/HallMonitor.apk
sha256: 0a38cd1e262f1875d0d17528a2343df5a8f6aa0723b5c3146d8f560dce6e0535

Answer 30 · 2014-09-04T15:00:45.000Z

I think it's a misunderstood, I speak about Hallmonitor ui (configuration activity) or OS ui (launcher after HallMonitor)?
Because the problem with the Cyanogen, they have their own smart cover screen and Hallmonitor seem conflict with it (and it is normal, Cyanogen must provide a settings to disable their).
I have no conflict using Hallmonitor and his RealHall service on 20140903-Nightly. Without RealHall service, it does not work at all.
And yes you can't use https://github.com/manusfreedom/HallMonitor/tree/master/download/CM_SystemApp without put it in /system/app (and must be copied to 2 times (overwrite each time) with root access or installed through recovery).
I compiled a version without system signature and both system parameters in AndroidManifest: https://github.com/manusfreedom/HallMonitor/tree/master/download/debug

Answer 31 · 2014-09-04T16:25:49.000Z

I speak about any kind of ui. i can see only the hallMonitor layout. all hardware buttons are disabled (back and home).

after updating to 20140903-nightly i can confirm that lid works properly.

starting debug version causes exception:

09-04 18:59:43.506 683-1015/system_process I/ActivityManager﹕ START u0 {flg=0x14810000 cmp=org.durka.hallmonitor/.Configuration} from pid 7235
09-04 18:59:43.516 7235-7235/org.durka.hallmonitor E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: org.durka.hallmonitor, PID: 7235
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.durka.hallmonitor/org.durka.hallmonitor.Configuration}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2212)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2271)
at android.app.ActivityThread.access$800(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1205)
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:796)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:612)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at org.durka.hallmonitor.CoreStateManager.(CoreStateManager.java:134)
at org.durka.hallmonitor.CoreApp.getStateManager(CoreApp.java:86)
at org.durka.hallmonitor.Configuration.onCreate(Configuration.java:40)
at android.app.Activity.performCreate(Activity.java:5231)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2169)
            at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2271)
            at android.app.ActivityThread.access$800(ActivityThread.java:144)
            at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1205)
            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:796)
            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:612)
            at dalvik.system.NativeStart.main(Native Method)

Answer 32 · 2014-09-04T17:16:48.000Z

Same thing for me, unable to get it working even if Use internal service is checked and RealHall aswell it only show a black screen and when i open the cover i see 0.5 sec of the hall monitor screen and my phone says that InputDevices has a root permission, it's weird that it work properly for you

edit: now hall monitor don't show in app drawer after installation via recovery and copy/pasting 2 times in system/app

edit2: managed to show it again by DL the debug version and copy/paste it in system/app and install it manually, but it's still not working

Answer 33 · 2014-09-04T21:29:43.000Z

I found why it work with me, because of my kernel (alucard24 on xda). Cyanogen modified too much thing. I will release a patch tomorrow to fix black screen and you are right about using the flag, but it is not very smart from them because a real wake up like power button is overrided by the cover, it's a bad thing.

Answer 34 · 2014-09-05T06:22:31.000Z

i'm unable to find that kernel for the s4 mini i9195 device, i find only for the original s4

Answer 35 · 2014-09-05T08:31:26.000Z

KEYCODE_HEADSETHOOK just works for pickup. hangup doesn't work in CM-build (pm'ed arco68).

Answer 36 · 2014-09-05T09:03:34.000Z

I am on S4 original.

Answer 37 · 2014-09-05T15:43:15.000Z

i'll try to find a custom kernel for the s4 mini and tell if it works or not

Answer 38 · 2014-09-05T17:25:05.000Z

HEADSETHOOK works for cm like this

pickup: sendKeyMediaHook(false);
hangup: sendKeyMediaHook(true);

private void sendKeyMediaHook(boolean longPress) {
Intent intent = new Intent(Intent.ACTION_MEDIA_BUTTON);
KeyEvent keyEvent = new KeyEvent(KeyEvent.ACTION_UP,
KeyEvent.KEYCODE_HEADSETHOOK);

if (longPress)
keyEvent = KeyEvent.changeFlags(keyEvent, keyEvent.getFlags() |
KeyEvent.FLAG_LONG_PRESS);

intent.putExtra(Intent.EXTRA_KEY_EVENT, keyEvent);
sendOrderedBroadcast(intent, null);
}

Answer 39 · 2014-09-06T00:43:20.000Z

@habeIchVergessen It works to end a call but not to reject it. So I search a way to reject incomming call.
I don't find why preview camera is rotated in the bad way.
I uploaded new code but not the compiled version.

Answer 40 · 2014-09-06T09:57:55.000Z

we need to set the repeatCount too

if (longPress)
keyEvent = KeyEvent.changeTimeRepeat(keyEvent, System.currentTimeMillis(), 1,
keyEvent.getFlags() | KeyEvent.FLAG_LONG_PRESS);

Answer 41 · 2014-09-06T11:19:48.000Z

@habeIchVergessen I tested and it works well. I fixed camera.
I will push a bug fix release to day.
I don't know why but I don't receive always the incomming call state.

Answer 42 · 2014-09-06T14:01:39.000Z

Please try last release

Answer 43 · 2014-09-06T14:15:06.000Z

After a flash of the zip in the recovery, the app does not show in the drawer, do i have to install the debug version ?

edit: when i try to install the debug version, it fails

edit2 : after a reboot to recovery then install 2 times then wipe cache and recovery it shows up but still do the same, black screen when i close the cover even if the realHall box is checked

Answer 44 · 2014-09-06T16:59:46.000Z

same here: install debug version fails

Answer 45 · 2014-09-06T17:51:26.000Z

To use it with CM11 default kernel :

disable all internal services and himself
enable OS cover management in option (submenu of Enable)

Please provide feedback.
If anyone could provide me log of install errors, I will try to fix it.

Answer 46 · 2014-09-06T19:33:33.000Z

Still don't work for me, only a black screen, for installation, i need to wipe cache and dalvik after installation for the app to show in the drawer, but nothing pop up when i close the cover, the screen just goes black

Answer 47 · 2014-09-06T20:37:14.000Z

@draner: did you disable "proximity check before wakeup"? it's located in display menu.

@manusfreedom: install log

Answer 48 · 2014-09-06T21:20:12.000Z

yes it's disable

Answer 49 · 2014-09-07T10:15:36.000Z

Please see last readme and last version.
Debug can be installed but you must clean everything.

Answer 50 · 2014-09-07T10:23:33.000Z

I'll test it ASAP and give you some feedback after a clean installation

Answer 51 · 2014-09-07T12:59:10.000Z

Installation works fine after a clean install but still nothing on the screen when i close the cover
I'm thinking about something, can we just revert the commit with partial support of the cover because he all messed up ?

edit: interesting fact is that when i check use internal services then realHall, i can wake up the phone using power button, but not when these two are not checked

Answer 52 · 2014-09-07T15:01:28.000Z

No rollback possible, if you must rollback something is cyanogen.

Answer 53 · 2014-09-07T17:15:25.000Z

install works now. config starts.
just a black screen on closing cover. sometimes hallmonitor shows up on open.
do you use FLAG_TURN_SCREEN_ON?

Answer 54 · 2014-09-07T17:19:01.000Z

In DefaultActivity.java/onCreate:
// Keep screen on during display
this.getWindow().addFlags(
WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);

Edit: I just see my error... I will fix it

Answer 55 · 2014-09-07T19:11:06.000Z

I uploaded a fix version.
I hope, it will fix all, because I will not be able to work on Hall Monitor like last days during next weeks.

Answer 56 · 2014-09-07T19:39:00.000Z

i just tested, now, when the cover is closed, the screen blinks, i installed the debug version, maybe i should have installed system app ?

Answer 57 · 2014-09-07T20:18:11.000Z

Please provide me logs.

Answer 58 · 2014-09-07T20:28:45.000Z

i don't know how to make logs :)

Answer 59 · 2014-09-07T21:08:49.000Z

I commit a fix to try in the debug version. So, retry please. (it's my last commit for today)

Answer 60 · 2014-09-08T08:12:47.000Z

output of org.durka.hallmonitor only. no other exceptions occurred.

Answer 61 · 2014-09-15T14:58:34.000Z

I did a code review of smartcover by CyanogenMod.
Their is no way to replace the integrated smartcover support:

they completely manage wakeup/sleep with smartcover (sleep time fixed at 8sec) => no timer from our side possible
we can't manage to launch our hallmonitor display to the right time (just after the integrated smartcover)
with smartcover close, the power button doesn't work everytime (without hallmonitor installed)

So, CM11 nightly build completely broke all possible support or customization until they give a way to disable it (you can do it partially if you recompile cyanogenmod).

CM Smartcover code:
https://github.com/CyanogenMod/android_frameworks_base/tree/cm-11.0/packages/Keyguard/src/com/android/keyguard

Answer 62 · 2014-09-15T17:39:55.000Z

i'm using nightly 2014-09-03 and it works properly with HallMonitor (Framework Test)

power button responses all times. power on is lazy sometimes (up to several seconds)
sleep time (customizable via app)

and my commit on your fork works too (stops blinking; sleep time no tested).

Answer 63 · 2014-09-15T17:44:18.000Z

@manusfreedom Bleh, well, that's good news and bad news. Good news, they implemented it; bad news, they did it in an in-extensible way. But it's only a nightly build, maybe they will put in some extension hooks later. I wonder if we can talk to the CM devs about that? Anyway, thanks for looking into their implementation.

On Monday, September 15, 2014 at 10:58 AM, manusfreedom wrote:

I did a code review of smartcover by CyanogenMod.
Their is no way to replace the integrated smartcover support:
they completely manage wakeup/sleep with smartcover (sleep time fixed at 8sec) => no timer from our side possible
we can't manage to launch our hallmonitor display to the right time (just after the integrated smartcover)
with smartcover close, the power button doesn't work everytime (without hallmonitor installed)

So, CM11 nightly build completely broke all possible support or customization until they give a way to disable it (you can do it partially if you recompile cyanogenmod).
CM Smartcover code:
https://github.com/CyanogenMod/android_frameworks_base/tree/cm-11.0/packages/Keyguard/src/com/android/keyguard

—
Reply to this email directly or view it on GitHub (#12 (comment)).

Answer 64 · 2014-09-15T21:37:30.000Z

@habeIchVergessen How could you say that your commit is a fix. Why we need to keep our activity on if screen off is received?! And power button responses all times is not true I use CM without Hallmonitor and only stock CM, it works when it want and less than 50%!!

Answer 65 · 2014-09-16T17:58:35.000Z

what happens when cover will be closed?

os sends LID_STATE_CHANGED intent
HallMonitor receives LID_STATE_CHANGED and starts default activity
os turns off display (current window doesn't have FLAG_TURN_SCREEN_ON) and sends ACTION_SCREEN_OFF
HallMonitor comes up and shows window with FLAG_TURN_SCREEN_ON; os turns screen on and sends ACTION_SCREEN_ON
HallMonitor receives ACTION_SCREEN_OFF and finish itself
os sees a window without the FLAG_TURN_SCREEN_ON and turns screen off and sends ACTION_SCREEN_OFF

i guess it is so or something like this.
in the end user can see a blinking app. my changes in CoreReceiver.java stop this behaviour.

changes in HMAppWidgetManager.java clean up a configuration issue which results in a finish call of HallMonitor.

and yes power on works for my setup properly.
S4 mini (GT-I9591)
CyanogenMod 11 Nightly 2014-09-03

Answer 66 · 2014-09-16T18:11:06.000Z

if someone can upload an apk version of the latest changes i can test it and tell what happens for me, i'm on the latest nightly build, apparently they made changes for the cover in callui but i don't see anything changing, just a line on the patchnote about that

Answer 67 · 2014-09-16T20:31:20.000Z

manusfreedom version (incl. my bugfixes) - !!! testing only !!!

my project clone

Answer 68 · 2014-09-16T21:10:27.000Z

The manusfreedom version (first link) works perfectly for me

Answer 69 · 2014-09-16T21:52:45.000Z

no power on issues? blinking app? phone control works too?

Answer 70 · 2014-09-17T11:02:47.000Z

no issues for me ATM, phone control works and everything looks fine

Answer 71 · 2014-09-17T11:49:28.000Z

@draner: can you pickup/hangup calls with cover closed?

@manusfreedom: never get debug output like this "Hall.CS.enableCoverTouch"

Answer 72 · 2014-09-17T11:59:41.000Z

@habeIchVergessen did you enable root?

Answer 73 · 2014-09-17T12:04:58.000Z

this morning i rejected a call using the cover and it works

Answer 74 · 2014-09-17T13:11:46.000Z

@manusfreedom: yes i did (superuser log told me). used an older apk than draner. a fu..... recompile solved it (don't ask me).
got new error on dpm.lockNow(); (CoreService.java; patched source and apk uploaded).

Answer 75 · 2014-09-18T10:40:26.000Z

New version to day or tomorrow.

Answer 76 · 2014-09-18T22:32:53.000Z

New release: https://github.com/manusfreedom/HallMonitor/releases/tag/2.0.1

Answer 77 · 2014-09-20T08:50:16.000Z

New release: https://github.com/manusfreedom/HallMonitor/releases/tag/2.0.2

Answer 78 · 2014-09-20T09:15:36.000Z

Just tested that new version, it seems that it works but it don't want to diplay the date and i have a blue bar at the bottom where the torch icon is

Answer 79 · 2014-09-20T09:52:13.000Z

@draner On/Off default/alternative layout.

Answer 80 · 2014-09-20T10:31:53.000Z

it now diplay the date fine, but it tells me we are on august 22th, do you know why ?

Answer 81 · 2014-09-20T14:43:45.000Z

I will fix it, I found why.

Answer 82 · 2014-09-20T23:35:05.000Z

Fix in 2.0.2.1: https://github.com/manusfreedom/HallMonitor/releases/tag/2.0.2.1
Removed color in alternate display

Answer 83 · 2014-10-30T21:38:54.000Z

do you know when/if the CM11 (I got the Oct snapshot) will allow hall monitor to work again?