[1] Awareness ...
I am aware that APKs are application bundles that can be
- searched for
- triaged and chosen from, then
- installed
based on "target" compatibility.
[2] Decision-point ...
I am also aware that their interaction/access is spelled out during the install prompting and, unless you "consent" to such, the install abandons.
That says that the User has a conscious, pre-install decision-point.
I acknowledge that some of the "required" access appear to be excessive, being
- unrelated to some of, and
- reach far beyond expected functionality for,
the stated nature of the Applications. I also acknowledge that too many people seem to blindly accept all those pre-conditions, rather than think hard and back away, as they should have, for some of those "overreach capabilities"! But that is fully in the User's sphere of control over their own actions.
Being philosophical, I have never understood the tendencies for people to treat their phones with any less Security-mindedness than their computer, especially since such "smart" phones, tend to be the repository of their owner's entire set of life-critical data (something which I still can't understand, and is why I will never have a smart phone until Government forces upon me for medical puposes), in some cases being the only such place where the information is stored! Excuse me for saying so, but what kind of insanity is that?
[3] Integration ...
The mechanism used for "integrating" the APK Apps appears to be working smoothly. From my now 4-year old memory (last usage of Android tablet), the various "Play Stores" (Google being only one such) seemed to keep track nicely of
- my profile,
- what I had as platform, and
- what I had as installed Apps.
Adding and purging of applications seemed straightforward and without complexity, having never encountered any glitches.
[4] Concerns ...
In the APK world, there is no attempt, that I am aware of, regarding regarding true (security-oriented) sandboxing. All efforts at "containment" of malware is left to the installed anti-virus software tools.
It seems to me that, for that "infrastructure" to be more secure, except for tools dealing with actual networking, most other Apps should have "Read-Only" capability in regards to anything which is system, except for the contents of the Apps installation directory.
Since Android does use the Linux Kernel, that is suggestive that privilege control would be identical to what is currently available in Distros of the likes of Debian/Ubuntu.
That is the reason why I believe an adaptation of that "App" infrastructure might be feasible.
After all, it doesn't look like the Android environment is going to face a decline any time soon.
[5] State of mind ...
I don't know which of the various "delivery" and "operational" models is either
- the best, or
- the most workable, or
- the most manageable.
I only know that what is simplest, in its ability to protect the User from himself, while allowing that User to proceed, if and when they deem it sufficiently necessary for themselves, is usually the approach which will gain the most traction by Users.
Now here's the kicker ...
While Users communicate their preference/support by purchasing hardware, which incentivizes developers on the Hardware side, in the FOSS world, it is much harder to "steer" or "focus" developers, where the only true incentive is developers seem to give much weight to is their own need to "make their mark", by either successfully "birthing" a new concept/technology/process which offers benefits previously not attainable, or receiving the well-deserved praise from peers recognizing the novelty or revolution offered by those new works.
The definition, or scope, of what a "Desktop End-User" is, seems to be subsumed in the more operational-oriented "Admin-User" or, given current trends, DevOps practitioner.
Unfortunately for "Old-School" End-Users, such as myself, that DevOps focus seems to be supplanting the needs/preferences/considerations of old-school Users, when it comes time to choosing "flavours" of behaviour, giving more weight to multi-user performance over End-User usability.
At least, that is the trend that I am observing as an "outsider" of the Linux development Community.
[6] Consideration of the APK infrastructure approach ...
Which led me to ask the question ... has anyone even attempted to consider/study the mechanisms/infrastruture supporting APK usage on Android to see if a similar mechanism/infrastructure supporting (call it) LPK usage
- would be technically possible,
- would be technically workable,
- would be functionally desirable, and
- would match APK ease of use?
If so, what did such an investigation reveal?
Has that investigation been completely sidestepped and avoided?
Would an attempt to create an LPK environment only lead to a simple duplication of Android, but under a different name? Or could the LPK environment be a more Debian/Ubuntu infrastructure?
I am of the opinion that a "joint effort" could accelerate the proving-in of such an approach/infrastucture as well as incorporate mechanism for the "transforming" of APKs for LPK-oriented infrastructure.
The potential attraction/motivation would be the massive base of APK Apps that could be "flipped" to native-mode LPK, thereby increasing the Linux User base by some serious numbers, potentially driving the long-deferred migration of Windows Users to Linux!
[7] Bottom line ...
If such an exercise/study has not been attempted, how can we ever know whether the Linux world is overlooking an opportunity ... or a black hole?
Without at least a preliminary study, there is no way to know whether current Snap/Flatpack/AppImage/Devian approaches are the best or not.
So ... has there been a comparative critique of the two? APK-based approach vs Snap/Debian ?
