Android and Singleton pattern

In the past year or so, I've been assigned to work on multiple pretty complex Android projects. Also in the past year, I have developed my own Android projects, while learning how to avoid Android development issues, here are some of the conclusions.

Due to fact that Android does not allow direct communication between activities/broadcast receivers/services, which I would refer, as Model Access Limitation (MAL), causes most development teams, to develop their application, based mainly on the Singleton pattern. There is no discussion as for how to declare these Singletons or if one declaration way is better then another, I just think this design pattern is used widely, in the most ignorant way possible and I'll elaborate.

What is a Singleton? 

• Some developer say that a Singleton is a class type, that would have a single instance of that class type existing in the entire JVM. (This is somewhat reasonable)
  To achieve this developers have too many ways and theories on how to instantiate a Singleton: Enum, LazyLoader, double sync, and other.
• Some developer ask it to be impenetrable, that anything anyone would do, would not, by any chance create two instances of the same Singleton type. 
• In the case of Android, developers (without saying it out laud) turn to the Singleton to overcome the Android MAL, because a Singleton provides access to data from everywhere in the code  (NOT necessarily a good thing!) , and gives the impression that it is encapsulated. (It is!) 

Let me picture it for you: 

If someone would like to abuse the Singleton he can, and the fact that something can be accessed from everywhere in the code, together with Android MAL, can turn into something really really ugly, and believe me I've seen more then one, very UGLY "Singleton"s!

Which now brings us to the actual fact, it is not that we would want to have a single instance in the JVM, but more of a:

"Single instance that would be shared and used by other objects and threads in the JVM"

After assimilating this(hopefully you have), and taking the previous facts about Singletons into consideration, I've concluded:

(mean while it is my own conclusion which serves me so very well for the past years)

 "ONLY Real* Singletons will be used as Singletons in an Android projects!!"

I say Real, because there are developers, that don't understand when something is really a Singleton, and when another pattern is available and even preferable, they turn to the quickest, dirtiest, most comfortable way they find first, to overcome a Android MAL, and what can you do, Singleton just pops first to mind.

I've developed an entire framework 'Cyborg', based on this, it is not that I don't use Singletons, I have very few REAL Singletons, but I have many Single(Instance)ton, which are managed by a single-instance manager, that can only be instantiated once as well. (unless of course you would like to abuse it)

Once I've develop the infrastructure to manage Single-Instances, I've learned and adopted a very nice rule while developing, and using 3rd party libraries:

Don't abuse it... Use it!

To conclude, I think the Singleton pattern is an amazing one, but you don't eat with a shovel, nor dig with a spoon...