Can you please take another screenshot so we also can see these blocks in white?
What is the purpose of the packagemanager extension in this case?
Did you try the activity starter to start Facebook?
Use logcat to find out if any error occurs
Taifun
Hello, check the settings of the mobile phone on battery and others so that I can set it to start manually, that helped me.
This is generally a good advice, see also dontkillmyapp.com
In this case however something happens on restart of the device, but only partially
Taifun
It's a shame that at the code level you can't do anything to avoid many of these things.
Hi
The white blocks are actually disabled and not in use.
The taifun package manager was originally used to launch an app but its disabled and not used, instead using package utilities to run app.
But both does not launch an app.
Will try out using activity starter.
I'm not sure if this is possible, when you reboot your phone, a lot of activities or functions are restricted. This could also be imposed for starting external apps.
This is generly done by the Android system to prevent overload after the phone starts.
Though I would recommend you to stil experiment with different methods and by also disabling device specific optimization if any (dontkillmyapp.com)
Here is an illustration of the kind of "parallel/concurrent" access that I want to be able to do - without collision between the user interface and the service.
Two timers: one running in the visible user interface and another in the itto service. Each is incrementing its own count as well as a shared count.
If there were no shared count interference - i.e., if each reads, increments, and writes the shared count without the other intervening with its identical operations, then the sum of the individual counts would be equal to the shared count...which it is initially. However, eventually, it is not.
Open the app, then press start. Open the app again and use the button to check the counts periodically.
I know this is only a toy - with no useful function - except to illustrate the kind of exclusive access I am speaking of.
itoo_sandbox_async.aia (879.7 KB)
-Randal
Hi
Okay thanks.
Will try and experiment other methods.
Hmm, I took a look into that. This is a race condition, which leads to inconsistent data outcomes.
Itoo's Service runs on a different process than that of the app, so they will always remain non-synced.
From what I understand, you need a mechanism where the write/read is done safely. Meaning when the data is being read/write, no other process should do the same. Thus avoiding data inconsistency.
This would require us to create a "lock" mechanism, similar to that offered by Java, where a particular block of code, even called by many different processes, execute in order-of-call.
Did I understand that correctly, what you were trying to convey me? Then please reply yes.
Also, if you are interested, you can sponsor a new extension for $15 (I'll try to solve this race condition issue)
Yes. Exactly!
This could be as simple (though potentially inefficient) as a semaphore - where each thread requests the "lock" asynchronously until it is acquired and release it when done.
Or it could be more sophisticated and, for example, queue access requests and grant them in order of request, granting each subsequent request when access is released.
If none exists in appinventor, then this could be a very useful extension.
I am a little surprised that I find little/no mention of this in the forum (maybe I missed it). It makes me wonder if, for some reason, such a lock was not needed or would not be useful or practical or maybe even not possible.
-Randal
You didnt miss it, in App Inventor, there wasant such a complexity to deal with before. App Inventor apps' blocks are single threaded, everything runs on a single thread.
Meaning internally the components may utilize multi threading capabilities, but with a block coder's perspective, there really isnt a way to multi thread on App Inventor.
Race conditions often occur when two different processes/threads try to read and change the same data on the same location. (This issue never arose in App Inventor).
(I am using the word "thread' and "process" inter-changeably here)
Hi
Did some experiments using Ullis Roboter AI2 App Launcher Extension
The extension has a block to check for permission: CanLaunchFromBackground
It seems to work.
It will run the app packages on restart/boot
Here is my blocks
(app packagename blanked out here in this image)
That's great if it works.
"Thinking out-loud" ...
It would seem that the basic test-and-set (semaphore) lock functionality could implemented using the:
int getAndSet(int newValue)
method from the AtomicInteger class
[(https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicInteger.html)
... which atomically sets to the given value and returns the old value.
public AtomicInteger()
Creates a new AtomicInteger with initial value 0.
see: (https://stackoverflow.com/questions/57832471/which-atomicinteger-methods-are-test-and-set-fetch-and-add-and-compare-and-swap)
Each process/thread wanting access calls getAndSet (1) until it returns a '0'...every subsequent call from a process/thread will be returned a '1'.
Then after performing the protected operation(s), the '1' is reset to a '0' by the process with access by calling getAndSet(0), making it (the '0') available to other process(es)/thread(s).
The '0' is the permission token. It only exists in one place - either in the integer object (as when it is first created) or in a process which obtained it by getAndSet(1), replacing the '0' with a '1' in the object.
In cases where a collision is unlikely and/or the processing to be protected is of short duration (I believe this is true in my use case), the getAndSet(1) maybe done repeatedly ("spin on the lock") since access would likely be granted quickly.
The extension could simply be an "AccessToken" with GetAccess and ReleaseAccess methods which would do the underlying getAndSet calls. Or it could possibly be incorporated into the itoo extension(?).
One problem I see is that a thread/process could not be allowed to die/crash/exit while in possession of the '0', thereby causing any other process/thread calling getAndSet(1) to "hang"... perhaps some sort of timeout could be implemented...
... just "thinking out loud"... "for what it's worth" (excuse the English idioms 
)
-Kind regards,
Randal
Hi, we cannot use any atomic object classes provided by Java, even though they are meant to solve the problem we see, it does not suit us.
This is because, in Android, a normal process cannot access any of the objects stored in service process and vice versa.
AtomicInteger or any atomic type must be stored in either of the process, but it cannot be accessed by another.
Also, this feature could be out of scope for Itoo, since it only deals with background/foreground operations.
We could try to add that feature to this extension, but it wouldnt really suit it's purpose well.
Ok. I can see that what I had in mind using AtomicInteger is not possible in the normal sense of its use...
Let me return to a request in my earlier post:
I want to understand the itoo broadcast mechanism. I'd like to send messages both ways: from foreground UI to the itoo registered service and from the service to the UI, both in the same app.
Can you point me to example code that might help me understand how this broadcast messaging works?
Thanks,
-Randal
Hi, one of the examples showcasing Broadcasting abilities is my music player guide:
Although please note that the version used in the above project is older than the present version. Though the working is almost same.
Or let me try to explain how you'll implement it.
Case1: Send a message from UI to background?
For that, you use the RegisterBroadcast block in the the background, along with arguments "name" and a "procedure". What happens when that particular broadcast "name" is triggered? It will call that "procedure" with one argument, i.e the message.
Then you'll use the Broadcast block, in the UI, along with the name and the message.
Case2: Send a message from background to UI
In the background, similarly, directly, use the Broadcast block, along with the name and the message.
In the UI, there is an event block called BroadcastEvent that triggers whenever a new message is received.
Itoo's 2nd AnniversaryWOW!!! Its been 2 years from the first launch of Itoo!!!
Itoo is a widely used, special, yet unique tool, that has been redistributed in various forms, hundreds of times!
I would like to heavily thank all of the project supporters, without their encouragement, this extension wouldn't have evolved this further!!
Really thanks to the donors and contributors as well!! This is an extra push, that keeps me motivated!!
And how can we forget the ones that take time to reply to Itoo related queries, lifting some of my weight of? Kudos to them as well!
This in turn, also encourages me to help others, especially students and learners, who can further push the imagination with my tools!!
Thanks, very much for your example and explanation (I might suggest that you add the explanation the next time you update the documentation 
Can both cases be used in the same app so that messages may go in both directions (to/from service)? Or is it one direction only: Case1 OR Case2 in a single app?
If bi-directional is possible, then must the message "names" be distinct/different or could they be the same?
-Randal
There shouldnt be a problem using the same message name for bi-directional communication.
If you send a message named X to Service, then the Service can also send back you a messaged named X, there shouldn't be any conflict.