Removes Permission?

I had already sent you a project (aia) via PM with the same problem: TaifunAlarmManager and SideBar.

It is obviously not due to the AI2 build server, but to the development environment under which the extension was compiled. Because the problem also arises with my MyFonts extension and Ulli's MediaNotification. But @Ulrich_Bien then compiled in his environment and the problem no longer occurs.

Maybe @ewpatton can say more about (the reason for) this issue.
I compiled MyFonts with Evan's Extension Template. But Taifun doesn't use it, as he told me.

I have uploaded the two projects (aia files) that produce the manifests shown above. The _LS version works correctly, but the _LS_TW does not work. Upon further inspection of the text manifests we find that the notification description is missing in the_LS_TW version. The only difference between the two projects is the addition of the Taifun Wi-Fi extension to the Designer.

One comment mentions differences in the build environment. I'm using the latest updated public versions of Chrome on a Windows 10 machine. I haven't made any changes to the default settings of the App Inventor IDE. I originally signed up with App Inventor years ago (don't know how many), but only used it for a few hours until several days ago to develop this app.

[example projects containing paid extension removed by Taifun]

There is nothing proprietary about these projects – in fact they were developed mostly using freely available examples from Taifun and Ulli.

In case anybody is interested in what I'm doing: this app flashes LED Wi-Fi addressable light bulbs when an Android phone receives certain notifications; for example a phone call, text message, Skype call… I am deaf so unless I'm sitting next to my phone, of course I don't hear it ring, and I may not feel it vibrate. The bulbs I use are LifX LED Wi-Fi addressable bulbs (in the US I buy ones that cost about $10 each). LifX has a public LAN API that allows you to send UDP commands over the network to have the bulbs do things. Deriving the UDP commands leads to a string of bytes (developing the strings is another story. You have to follow the LifX documentation). You need to use the public (available in Google Play) LifX app to add the bulbs to your network. You can look at your router DHCP table to find the IP address assigned to the bulbs.


I don't understand the context of your statement to my statement (if there is one at all).

OOh… I just reread your comment more carefully and I now understand you're talking about the environment the extension was compiled under. As Rosanne Rosanna-Danna would say: "Never mind". :grin:

By development environment I thought you were referring to the browser I was using and the operating system I'm working from. Were you referring to something different?

Since AI2 is hosted online, I don't believe I have control of anything other than which browser I use and which operating system I'm working under. The device I use should not matter since the manifest is created before I install to my device. I think I read that AI2 targets android versions above 4 or so. My device runs Android 11, but again that should not matter because the manifest is created and app compiled before it knows the version of Android on my device.


As you can easily see, my post is addressed at Taifun and Evan.
There is nothing you can do to solve / fix the problem.

I removed the uploaded projects from your thread...
as mentioned earlier, you should have sent them by PM...
see also my terms and conditions for paid extensions...

@ewpatton might want to take a look...

I'm using the default development environment


Are you talking about the standard MIT environment from github? Is there maybe any other?

Thanks, which is the same as I use. I thought there was another one.

I will put it on the list. I'm not sure though how quickly we will be able to turn this around.

Edit: I've confirmed the behavior locally.
Edit 2: I believe I have a fix for the issue.

Thanks. I am hoping it will not be too hard to isolate the culprit. I uploaded two projects. The first compiles and includes the service definition within the manifest. The second is identical to the first except that it adds the Wi-Fi extension, doesn't use it all, just adds it. When it compiles it leaves the service definition out of the manifest. Hopefully it will be not much work to find out why this happens.

On another note, this is a problem faced by all Android app developers. Android is going nuts trying to conserve battery. It ends a process, even service, after a while. My app with the notification service might run for a couple hours or the better part of a day before Android kills it and it stops notifying me. If I rerun the app, the service restarts, and notifications work again.

Is there a way to instruct Android to not kill a service or process? It seems to be getting worse as Android progresses up in versions, 8, 9, 10, 11, … I know services have been abused in the past, but just tell the user he is wasting battery and been with it.

This isn't something that App Inventor has control over. You're welcome to complain to Google, but I'd wouldn't waste the energy...

I've submitted a potential fix here

We will aim to get it into the next release.

I received a hint via email from Ulli (@Ulrich_Bien) regarding the problem and how he solved it:


Only the position of the source files is a bit out of date. The suggested directory


should NOT be used! Instead, it is better to set up your own source structure that corresponds to the Java package nomenclature. Like the Google sources, this structure starts in the folder


For me it looks like this:

I didn't test (compile) it myself with it. But as I said, he compiled my extension and the problem no longer occurs (along with his new MediaNotification).

The issue is due to how we processed the JSON content that describes the extensions. When a key wasn't found, that error terminated the extension processing early. As features have been added, we've added new keys to support those functions (e.g., services), but extensions compiled prior to the introduction of those features lack the corresponding keys since they weren't part of the build system at that time. So when you have these two extension in the project, the first (older) one doesn't have the key, the exception is thrown, and the newer extension, which does have the key, is never processed (this results in the service entry being dropped). By recompiling the extension with a newer version of the build system, the missing keys are added and so the process behaves as expected. The fix above makes it so that we don't prematurely exit the loop processing the extension information and resolves the issue even in the situation where the extension is older.

1 Like

Thank you for the detailed explanation.

Does this mean that any extensions compiled before this point will not work with extensions that contain services?

As a result, these (old) extensions would have to be recompiled to ensure that no problems arise.

Only until the next release goes out with the fix in the buildserver. There may also be an ordering effect since the extensions are processed linearly. It might be possible to have it so the newer extensions load before the older extensions so the error doesn't prevent processing the newer extension.

1 Like

Thank you, good to know.
Now I've finally got it. :wink:

meanwhile I recompiled the extension, which fixes the issue for @canalrun
the new version of the wifi extension is available for download here
thank you @ewpatton