[jitsi-dev] [PATCH] Jitsi-Android implement exit functionality and service bound global icon


#1

Hi,

This patch adds the exit option to the menu and implements global Jitsi
icon that is bound to the OSGi service.

Changes required to achieve this functionality:

1. AndroidManifest.xml - sets the CallContactActivity as singleTask so it
won't open multiple times.

2. AndroidResourceServiceImpl - will catch the exception about URLFactory
already set. It's reported by the logger, but can be ignored. This could be
fixed by finding a way how to know that the factory has been already set.
Suggestions are welcome.
Another change is that it now uses OSGiService as an Android context,
because the Jitsi activity which was used before may be not always
available while the service is.

3. MainMenuActivity - handles exit menu item by shutting down the OSGi
service.

4. AndroidLoginRenderer - is using OSGiService notification ID to post
notifications. As a result we use only one service bound notification icon.
Another change is to finish the Jitsi activity once the CallContactActivity
is displayed.

5. Jitsi activity - remove getter for package name, as it's no longer used
by resources service.

6. OSGiService - when OSGi finishes the initialization and the start
service method is called it installs global notification icon.

7. OSGiServiceActivator - on stop it calls stopForeground instead of
stopSelf()

exitFunctionality.txt (15.2 KB)

···

--
Regards,
Pawel


#2

Oh I've forgot to mention that when the OSGi service is being shutdown
there is a notice about leaking listener(at least on my device). But I've
investigated that case and it's unregistered a moment later in
ConnectivityManagerListenerImpl.stop.

03-14 12:24:56.573: ERROR/ActivityThread(6853): Service
org.jitsi.service.osgi.OSGiService has leaked IntentReceiver
net.java.sip.communicator.impl.sysactivity.ConnectivityManagerListenerImpl@42a4f150that
was originally registered here. Are you missing a call to
unregisterReceiver()?
        android.app.IntentReceiverLeaked: Service
org.jitsi.service.osgi.OSGiService has leaked IntentReceiver
net.java.sip.communicator.impl.sysactivity.ConnectivityManagerListenerImpl@42a4f150that
was originally registered here. Are you missing a call to
unregisterReceiver()?
        at
android.app.LoadedApk$ReceiverDispatcher.<init>(LoadedApk.java:795)
        at android.app.LoadedApk.getReceiverDispatcher(LoadedApk.java:596)
        at
android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1316)
        at android.app.ContextImpl.registerReceiver(ContextImpl.java:1296)
        at android.app.ContextImpl.registerReceiver(ContextImpl.java:1290)
        at
android.content.ContextWrapper.registerReceiver(ContextWrapper.java:423)
        at
net.java.sip.communicator.impl.sysactivity.ConnectivityManagerListenerImpl.start(ConnectivityManagerListenerImpl.java:62)
        at
net.java.sip.communicator.impl.sysactivity.SystemActivityNotificationsServiceImpl.start(SystemActivityNotificationsServiceImpl.java:144)
        at
net.java.sip.communicator.impl.sysactivity.SysActivityActivator.start(SysActivityActivator.java:59)
        at
org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:294)
        at
org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged(FrameworkImpl.java:446)
        at
org.jitsi.impl.osgi.framework.startlevel.FrameworkStartLevelImpl$Command.run(FrameworkStartLevelImpl.java:127)
        at
org.jitsi.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:110)
        at
org.jitsi.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:16)
        at
org.jitsi.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:219)

Hi,

This patch adds the exit option to the menu and implements global Jitsi

icon that is bound to the OSGi service.

Changes required to achieve this functionality:

1. AndroidManifest.xml - sets the CallContactActivity as singleTask so it

won't open multiple times.

2. AndroidResourceServiceImpl - will catch the exception about URLFactory

already set. It's reported by the logger, but can be ignored. This could be
fixed by finding a way how to know that the factory has been already set.
Suggestions are welcome.

Another change is that it now uses OSGiService as an Android context,

because the Jitsi activity which was used before may be not always
available while the service is.

3. MainMenuActivity - handles exit menu item by shutting down the OSGi

service.

4. AndroidLoginRenderer - is using OSGiService notification ID to post

notifications. As a result we use only one service bound notification icon.
Another change is to finish the Jitsi activity once the CallContactActivity
is displayed.

5. Jitsi activity - remove getter for package name, as it's no longer

used by resources service.

6. OSGiService - when OSGi finishes the initialization and the start

service method is called it installs global notification icon.

7. OSGiServiceActivator - on stop it calls stopForeground instead of

stopSelf()

···

2013/3/14 Paweł Domas <paweldomas@gmail.com>

--
Regards,
Pawel

--
Regards,
Pawel


#3

Hi Pawel,

This patch doesn't seem to work for me. I've applied and committed all patches in the order they were sent to the list, but I'm experiencing some conflicts when applying this one. Could you please update from svn and try to see if you've missed something in between the patches?

Thanks!
Yana

···

On Mar 14, 2013, at 12:46 PM, Paweł Domas <paweldomas@gmail.com> wrote:

Hi,

This patch adds the exit option to the menu and implements global Jitsi icon that is bound to the OSGi service.

Changes required to achieve this functionality:

1. AndroidManifest.xml - sets the CallContactActivity as singleTask so it won't open multiple times.

2. AndroidResourceServiceImpl - will catch the exception about URLFactory already set. It's reported by the logger, but can be ignored. This could be fixed by finding a way how to know that the factory has been already set. Suggestions are welcome.
Another change is that it now uses OSGiService as an Android context, because the Jitsi activity which was used before may be not always available while the service is.

3. MainMenuActivity - handles exit menu item by shutting down the OSGi service.

4. AndroidLoginRenderer - is using OSGiService notification ID to post notifications. As a result we use only one service bound notification icon. Another change is to finish the Jitsi activity once the CallContactActivity is displayed.

5. Jitsi activity - remove getter for package name, as it's no longer used by resources service.

6. OSGiService - when OSGi finishes the initialization and the start service method is called it installs global notification icon.

7. OSGiServiceActivator - on stop it calls stopForeground instead of stopSelf()

--
Regards,
Pawel
<exitFunctionality.txt>


#4

Hi Yana,

Here's the fixed version of that patch.

Hi Pawel,

This patch doesn't seem to work for me. I've applied and committed all

patches in the order they were sent to the list, but I'm experiencing some
conflicts when applying this one. Could you please update from svn and try
to see if you've missed something in between the patches?

Thanks!
Yana

> Hi,
>
> This patch adds the exit option to the menu and implements global Jitsi

icon that is bound to the OSGi service.

>
> Changes required to achieve this functionality:
>
> 1. AndroidManifest.xml - sets the CallContactActivity as singleTask so

it won't open multiple times.

>
> 2. AndroidResourceServiceImpl - will catch the exception about

URLFactory already set. It's reported by the logger, but can be ignored.
This could be fixed by finding a way how to know that the factory has been
already set. Suggestions are welcome.

> Another change is that it now uses OSGiService as an Android context,

because the Jitsi activity which was used before may be not always
available while the service is.

>
> 3. MainMenuActivity - handles exit menu item by shutting down the OSGi

service.

>
> 4. AndroidLoginRenderer - is using OSGiService notification ID to post

notifications. As a result we use only one service bound notification icon.
Another change is to finish the Jitsi activity once the CallContactActivity
is displayed.

>
> 5. Jitsi activity - remove getter for package name, as it's no longer

used by resources service.

>
> 6. OSGiService - when OSGi finishes the initialization and the start

service method is called it installs global notification icon.

>
> 7. OSGiServiceActivator - on stop it calls stopForeground instead of

stopSelf()

exitFunctionality.txt (16.5 KB)

···

2013/3/20 Yana Stamcheva <yana@jitsi.org>

On Mar 14, 2013, at 12:46 PM, Paweł Domas <paweldomas@gmail.com> wrote:
>
> --
> Regards,
> Pawel
> <exitFunctionality.txt>

--
Regards,
Pawel


#5

Hi Pawel,

Thanks, it works.

Could you please explain in more detail why we need to call stopForegroundService() instead of stopSelf()? Here are the docs for the two methods:

stopForeground(): Remove this service from foreground state, allowing it to be killed if more memory is needed.
stopSelf(): Stop the service, if it was previously started.

I've also read that the stopForeground() would cancel the persistent notifications, so maybe this is what you had in mind, but then shouldn't we call both methods. Please elaborate some more on that decision :slight_smile:

Cheers,
Yana

···

On Mar 21, 2013, at 2:52 PM, Paweł Domas <paweldomas@gmail.com> wrote:

Hi Yana,

Here's the fixed version of that patch.

2013/3/20 Yana Stamcheva <yana@jitsi.org>
>
> Hi Pawel,
>
> This patch doesn't seem to work for me. I've applied and committed all patches in the order they were sent to the list, but I'm experiencing some conflicts when applying this one. Could you please update from svn and try to see if you've missed something in between the patches?
>
> Thanks!
> Yana
>
> On Mar 14, 2013, at 12:46 PM, Paweł Domas <paweldomas@gmail.com> wrote:
>
> > Hi,
> >
> > This patch adds the exit option to the menu and implements global Jitsi icon that is bound to the OSGi service.
> >
> > Changes required to achieve this functionality:
> >
> > 1. AndroidManifest.xml - sets the CallContactActivity as singleTask so it won't open multiple times.
> >
> > 2. AndroidResourceServiceImpl - will catch the exception about URLFactory already set. It's reported by the logger, but can be ignored. This could be fixed by finding a way how to know that the factory has been already set. Suggestions are welcome.
> > Another change is that it now uses OSGiService as an Android context, because the Jitsi activity which was used before may be not always available while the service is.
> >
> > 3. MainMenuActivity - handles exit menu item by shutting down the OSGi service.
> >
> > 4. AndroidLoginRenderer - is using OSGiService notification ID to post notifications. As a result we use only one service bound notification icon. Another change is to finish the Jitsi activity once the CallContactActivity is displayed.
> >
> > 5. Jitsi activity - remove getter for package name, as it's no longer used by resources service.
> >
> > 6. OSGiService - when OSGi finishes the initialization and the start service method is called it installs global notification icon.
> >
> > 7. OSGiServiceActivator - on stop it calls stopForeground instead of stopSelf()
> >
> > --
> > Regards,
> > Pawel
> > <exitFunctionality.txt>
>

--
Regards,
Pawel
<exitFunctionality.txt>


#6

I am not an expert of Android( yet :slight_smile: ), but here's how I understand it
from reading all the guides on the net :wink:

First of all in our app model we are dependent from the OSGiService,
because all our service providers are being run there. When the service
runs in foreground it will not be killed by the system as often as it
happens with normal service run mode. We want our providers to stay
connected and notify our app when the call there is incoming call or
message. So we want to run it in the backround all the time. That's why it
runs in foreground.

When service runs in foreground mode it have to provide the notification
icon so that user will know that something is running in background and
eventually be able to stop it. This also fits our needs, we want to have
such icon.

Our service enters foreground mode after all our bundles are started. It's
required to call stopForeground to realease this mode and if there will be
no Activities opened the service will be shutdown.

Why no need to call stopSelf() ? Because the same function has action on
"Exit" menu item. It starts service shutdown intent:

case R.id.menu_exit:
            // Shutdown the OSGi service
            stopService(new Intent(this, OSGiService.class));
            finish();
            return true;

If user will reopen jitsi from "recent apps" the service will start again
and popup the notification icon, because it binds it everytime it finishes
initializing all bundles.

Hi Pawel,

Thanks, it works.

Could you please explain in more detail why we need to call

stopForegroundService() instead of stopSelf()? Here are the docs for the
two methods:

stopForeground(): Remove this service from foreground state, allowing it

to be killed if more memory is needed.

stopSelf(): Stop the service, if it was previously started.

I've also read that the stopForeground() would cancel the persistent

notifications, so maybe this is what you had in mind, but then shouldn't we
call both methods. Please elaborate some more on that decision :slight_smile:

Cheers,
Yana

> Hi Yana,
>
> Here's the fixed version of that patch.
>
> >
> > Hi Pawel,
> >
> > This patch doesn't seem to work for me. I've applied and committed

all patches in the order they were sent to the list, but I'm experiencing
some conflicts when applying this one. Could you please update from svn and
try to see if you've missed something in between the patches?

> >
> > Thanks!
> > Yana
> >
> >
> > > Hi,
> > >
> > > This patch adds the exit option to the menu and implements global

Jitsi icon that is bound to the OSGi service.

> > >
> > > Changes required to achieve this functionality:
> > >
> > > 1. AndroidManifest.xml - sets the CallContactActivity as singleTask

so it won't open multiple times.

> > >
> > > 2. AndroidResourceServiceImpl - will catch the exception about

URLFactory already set. It's reported by the logger, but can be ignored.
This could be fixed by finding a way how to know that the factory has been
already set. Suggestions are welcome.

> > > Another change is that it now uses OSGiService as an Android

context, because the Jitsi activity which was used before may be not always
available while the service is.

> > >
> > > 3. MainMenuActivity - handles exit menu item by shutting down the

OSGi service.

> > >
> > > 4. AndroidLoginRenderer - is using OSGiService notification ID to

post notifications. As a result we use only one service bound notification
icon. Another change is to finish the Jitsi activity once the
CallContactActivity is displayed.

> > >
> > > 5. Jitsi activity - remove getter for package name, as it's no

longer used by resources service.

> > >
> > > 6. OSGiService - when OSGi finishes the initialization and the

start service method is called it installs global notification icon.

> > >
> > > 7. OSGiServiceActivator - on stop it calls stopForeground instead

of stopSelf()

···

2013/3/21 Yana Stamcheva <yana@jitsi.org>

On Mar 21, 2013, at 2:52 PM, Paweł Domas <paweldomas@gmail.com> wrote:
> 2013/3/20 Yana Stamcheva <yana@jitsi.org>
> > On Mar 14, 2013, at 12:46 PM, Paweł Domas <paweldomas@gmail.com> wrote:
> > >
> > > --
> > > Regards,
> > > Pawel
> > > <exitFunctionality.txt>
> >
>
> --
> Regards,
> Pawel
> <exitFunctionality.txt>

--
Regards,
Pawel


#7

I am not an expert of Android( yet :slight_smile: ), but here's how I understand it from reading all the guides on the net :wink:

First of all in our app model we are dependent from the OSGiService, because all our service providers are being run there. When the service runs in foreground it will not be killed by the system as often as it happens with normal service run mode. We want our providers to stay connected and notify our app when the call there is incoming call or message. So we want to run it in the backround all the time. That's why it runs in foreground.

Right, that was also my understanding.

When service runs in foreground mode it have to provide the notification icon so that user will know that something is running in background and eventually be able to stop it. This also fits our needs, we want to have such icon.

Right.

Our service enters foreground mode after all our bundles are started. It's required to call stopForeground to realease this mode and if there will be no Activities opened the service will be shutdown.

Why no need to call stopSelf() ? Because the same function has action on "Exit" menu item. It starts service shutdown intent:

case R.id.menu_exit:
            // Shutdown the OSGi service
            stopService(new Intent(this, OSGiService.class));
            finish();
            return true;

If user will reopen jitsi from "recent apps" the service will start again and popup the notification icon, because it binds it everytime it finishes initializing all bundles.

Ok. Thanks for explaining!

I've just made some tests with this new patch and here are the issues I'm experiencing:

* Exception related to the ResourceManagementService

W/System.err( 3262): java.lang.Error: Factory already set
W/System.err( 3262): at java.net.URL.setURLStreamHandlerFactory(URL.java:114)
W/System.err( 3262): at org.jitsi.impl.androidresources.AndroidResourceServiceImpl.<init>(AndroidResourceServiceImpl.java:119)
W/System.err( 3262): at org.jitsi.impl.androidresources.AndroidResourceManagementActivator.start(AndroidResourceManagementActivator.java:49)
W/System.err( 3262): at org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:294)
W/System.err( 3262): at org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged(FrameworkImpl.java:446)
W/System.err( 3262): at org.jitsi.impl.osgi.framework.startlevel.FrameworkStartLevelImpl$Command.run(FrameworkStartLevelImpl.java:127)
W/System.err( 3262): at org.jitsi.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:110)
W/System.err( 3262): at org.jitsi.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:16)
W/System.err( 3262): at org.jitsi.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:219)
D/dalvikvm( 3262): GC_CONCURRENT freed 1573K, 26% free 13088K/17671K, paused 24ms+3ms, total 79ms

* Another exception related to the UtilActivator

W/System.err( 3731): 21:43:23.551 SEVERE: [1] util.UtilActivator.uncaughtException().92 An uncaught exception occurred in thread=Thread[main,5,main] and message was: Unable to add window -- token android.os.BinderProxy@42b14a68 is not valid; is your activity running?
W/System.err( 3731): android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@42b14a68 is not valid; is your activity running?
W/System.err( 3731): at android.view.ViewRootImpl.setView(ViewRootImpl.java:585)
W/System.err( 3731): at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:326)
W/System.err( 3731): at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:224)
W/System.err( 3731): at android.view.WindowManagerImpl$CompatModeWrapper.addView(WindowManagerImpl.java:149)
W/System.err( 3731): at android.view.Window$LocalWindowManager.addView(Window.java:547)
W/System.err( 3731): at android.app.Dialog.show(Dialog.java:277)
W/System.err( 3731): at android.app.AlertDialog$Builder.show(AlertDialog.java:932)
W/System.err( 3731): at org.jitsi.android.gui.util.AndroidUtils$1.run(AndroidUtils.java:45)
W/System.err( 3731): at android.os.Handler.handleCallback(Handler.java:615)
W/System.err( 3731): at android.os.Handler.dispatchMessage(Handler.java:92)
W/System.err( 3731): at android.os.Looper.loop(Looper.java:137)
W/System.err( 3731): at android.app.ActivityThread.main(ActivityThread.java:4745)
W/System.err( 3731): at java.lang.reflect.Method.invokeNative(Native Method)
W/System.err( 3731): at java.lang.reflect.Method.invoke(Method.java:511)
W/System.err( 3731): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
W/System.err( 3731): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
W/System.err( 3731): at dalvik.system.NativeStart.main(Native Method)

* When the application is started I try to open the menu (in order to choose the Exit option), but the menu doesn't open and I get a "Jitsi isn't responding. Do you want to close it?" error. When I click "Ok" it stays open and I can now open the menu!

The error I get here is the following:

E/ActivityManager( 249): ANR in org.jitsi (org.jitsi/.android.gui.call.CallContactActivity)
E/ActivityManager( 249): Reason: keyDispatchingTimedOut
E/ActivityManager( 249): Load: 1.87 / 1.6 / 1.42
E/ActivityManager( 249): CPU usage from 7192ms to 2109ms ago with 99% awake:

Do you experience any of these when you apply the patch on a clean svn checkout?

Cheers,
Yana

···

On Mar 21, 2013, at 8:49 PM, Paweł Domas <paweldomas@gmail.com> wrote:

2013/3/21 Yana Stamcheva <yana@jitsi.org>
>
> Hi Pawel,
>
> Thanks, it works.
>
> Could you please explain in more detail why we need to call stopForegroundService() instead of stopSelf()? Here are the docs for the two methods:
>
> stopForeground(): Remove this service from foreground state, allowing it to be killed if more memory is needed.
> stopSelf(): Stop the service, if it was previously started.
>
> I've also read that the stopForeground() would cancel the persistent notifications, so maybe this is what you had in mind, but then shouldn't we call both methods. Please elaborate some more on that decision :slight_smile:
>
> Cheers,
> Yana
>
> On Mar 21, 2013, at 2:52 PM, Paweł Domas <paweldomas@gmail.com> wrote:
>
> > Hi Yana,
> >
> > Here's the fixed version of that patch.
> >
> > 2013/3/20 Yana Stamcheva <yana@jitsi.org>
> > >
> > > Hi Pawel,
> > >
> > > This patch doesn't seem to work for me. I've applied and committed all patches in the order they were sent to the list, but I'm experiencing some conflicts when applying this one. Could you please update from svn and try to see if you've missed something in between the patches?
> > >
> > > Thanks!
> > > Yana
> > >
> > > On Mar 14, 2013, at 12:46 PM, Paweł Domas <paweldomas@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > This patch adds the exit option to the menu and implements global Jitsi icon that is bound to the OSGi service.
> > > >
> > > > Changes required to achieve this functionality:
> > > >
> > > > 1. AndroidManifest.xml - sets the CallContactActivity as singleTask so it won't open multiple times.
> > > >
> > > > 2. AndroidResourceServiceImpl - will catch the exception about URLFactory already set. It's reported by the logger, but can be ignored. This could be fixed by finding a way how to know that the factory has been already set. Suggestions are welcome.
> > > > Another change is that it now uses OSGiService as an Android context, because the Jitsi activity which was used before may be not always available while the service is.
> > > >
> > > > 3. MainMenuActivity - handles exit menu item by shutting down the OSGi service.
> > > >
> > > > 4. AndroidLoginRenderer - is using OSGiService notification ID to post notifications. As a result we use only one service bound notification icon. Another change is to finish the Jitsi activity once the CallContactActivity is displayed.
> > > >
> > > > 5. Jitsi activity - remove getter for package name, as it's no longer used by resources service.
> > > >
> > > > 6. OSGiService - when OSGi finishes the initialization and the start service method is called it installs global notification icon.
> > > >
> > > > 7. OSGiServiceActivator - on stop it calls stopForeground instead of stopSelf()
> > > >
> > > > --
> > > > Regards,
> > > > Pawel
> > > > <exitFunctionality.txt>
> > >
> >
> > --
> > Regards,
> > Pawel
> > <exitFunctionality.txt>

--
Regards,
Pawel


#8

I've just made some tests with this new patch and here are the issues I'm

experiencing:

* Exception related to the ResourceManagementService

> W/System.err( 3262): java.lang.Error: Factory already set
> W/System.err( 3262): at

java.net.URL.setURLStreamHandlerFactory(URL.java:114)

> W/System.err( 3262): at

org.jitsi.impl.androidresources.AndroidResourceServiceImpl.<init>(AndroidResourceServiceImpl.java:119)

> W/System.err( 3262): at

org.jitsi.impl.androidresources.AndroidResourceManagementActivator.start(AndroidResourceManagementActivator.java:49)

> W/System.err( 3262): at

org.jitsi.impl.osgi.framework.BundleImpl.start(BundleImpl.java:294)

> W/System.err( 3262): at

org.jitsi.impl.osgi.framework.launch.FrameworkImpl.startLevelChanged(FrameworkImpl.java:446)

> W/System.err( 3262): at

org.jitsi.impl.osgi.framework.startlevel.FrameworkStartLevelImpl$Command.run(FrameworkStartLevelImpl.java:127)

> W/System.err( 3262): at

org.jitsi.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:110)

> W/System.err( 3262): at

org.jitsi.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:16)

> W/System.err( 3262): at

org.jitsi.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:219)

> D/dalvikvm( 3262): GC_CONCURRENT freed 1573K, 26% free 13088K/17671K,

paused 24ms+3ms, total 79ms

>

This one can be ignored for now, but I'm planning to remove the URL factory
for resources, as this may cause problems.

The idea was to add URL factory for protocol "jitsi.resource" which will be
able to open streams for the resources returned with path that starts with
this protocol. The paths are returned by resources service for sound and
images. In Jitsi-Android URLs from paths are used for notification
sounds(incoming call, message etc.).

In desktop java custom protocol handling can be done by registering URL
handler:


It doesn't work that way on Android. Also in desktop Java providing custom
URL factory may block other protocols like file:\\ and http:\\. However
I've tested current URL Factory on my device and it wasn't blocking, but I
can't be sure if it won't happen on other OS versions.

I also wrote about it when submitting a patch:

"2. AndroidResourceServiceImpl - will catch the exception about URLFactory
already set. It's reported by the logger, but can be ignored. This could be
fixed by finding a way how to know that the factory has been already set.
Suggestions are welcome."

I'll try static flag that will mark factory created between service
restarts and prevent the exception, but I will keep looking for another
solution.

* Another exception related to the UtilActivator

> W/System.err( 3731): 21:43:23.551 SEVERE: [1]

util.UtilActivator.uncaughtException().92 An uncaught exception occurred in
thread=Thread[main,5,main] and message was: Unable to add window -- token
android.os.BinderProxy@42b14a68 is not valid; is your activity running?

> W/System.err( 3731): android.view.WindowManager$BadTokenException:

Unable to add window -- token android.os.BinderProxy@42b14a68 is not valid;
is your activity running?

> W/System.err( 3731): at

android.view.ViewRootImpl.setView(ViewRootImpl.java:585)

> W/System.err( 3731): at

android.view.WindowManagerImpl.addView(WindowManagerImpl.java:326)

> W/System.err( 3731): at

android.view.WindowManagerImpl.addView(WindowManagerImpl.java:224)

> W/System.err( 3731): at

android.view.WindowManagerImpl$CompatModeWrapper.addView(WindowManagerImpl.java:149)

> W/System.err( 3731): at

android.view.Window$LocalWindowManager.addView(Window.java:547)

> W/System.err( 3731): at android.app.Dialog.show(Dialog.java:277)
> W/System.err( 3731): at

android.app.AlertDialog$Builder.show(AlertDialog.java:932)

> W/System.err( 3731): at

org.jitsi.android.gui.util.AndroidUtils$1.run(AndroidUtils.java:45)

> W/System.err( 3731): at

android.os.Handler.handleCallback(Handler.java:615)

> W/System.err( 3731): at

android.os.Handler.dispatchMessage(Handler.java:92)

> W/System.err( 3731): at android.os.Looper.loop(Looper.java:137)
> W/System.err( 3731): at

android.app.ActivityThread.main(ActivityThread.java:4745)

> W/System.err( 3731): at java.lang.reflect.Method.invokeNative(Native

Method)

> W/System.err( 3731): at

java.lang.reflect.Method.invoke(Method.java:511)

> W/System.err( 3731): at

com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)

> W/System.err( 3731): at

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)

> W/System.err( 3731): at dalvik.system.NativeStart.main(Native Method)

This one is because we use context from Jitsi Activity for showing alerts
that come from services. That is wrong because it may be closed. The stack
trace here is incomplete as it comes from executing this code on main
thread:

AndroidUtils:35:

public static void showAlertDialog( Context context,
                                        final int titleId,
                                        final int messageId)
    {
        final Activity mainActivity = (Activity) context;

        mainActivity.runOnUiThread(new Runnable()
        {
            public void run()
            {
                new AlertDialog.Builder(mainActivity)
                    .setIcon(R.drawable.icon)
                    .setTitle(titleId)
                    .setMessage(messageId)
                    .setNeutralButton(R.string.service_gui_CLOSE, null)
                    .show();
            }
        });
    }

Error and alert notifications are(and were before the patch) not displayed
correctly. When we use Jitsi Activity as a context they are often shown
behind the current activity and we can see them by going back to Jitsi
Activity which makes no sense.

I thought about few options:
1. Try to use OSGiService as an alert context. I use it for getting
Resources in AndroidResourcesService starting from this patch and we
generally should use OSGiService context as it will be always available.
2. Get current top Activity, but I'm not sure how to do this and I've been
googling for solution and as a result I've found the third option:
3. Create new activity for each alert, but theme it so that it will look
like an "alert". This way it will always be on top. We can use OSGiService
as a context for starting alert activities.

* When the application is started I try to open the menu (in order to

choose the Exit option), but the menu doesn't open and I get a "Jitsi isn't
responding. Do you want to close it?" error. When I click "Ok" it stays
open and I can now open the menu!

The error I get here is the following:

> E/ActivityManager( 249): ANR in org.jitsi

(org.jitsi/.android.gui.call.CallContactActivity)

> E/ActivityManager( 249): Reason: keyDispatchingTimedOut
> E/ActivityManager( 249): Load: 1.87 / 1.6 / 1.42
> E/ActivityManager( 249): CPU usage from 7192ms to 2109ms ago with 99%

awake:

Do you experience any of these when you apply the patch on a clean svn

checkout?

Cheers,
Yana

There should be an exception that occured on main thread. It may be a bit
earlier in the log. I can not reproduce it. Maybe it's the one from alert,
so fixing alerts will probably fix this also.

···

2013/3/21 Yana Stamcheva <yana@jitsi.org>

--
Regards,
Pawel