First of all I want to applaud the integrity of the team working on OmniRom and for standing for software freedom. As the only GPL ROM on the phone, I believe it will reach a certain prominence once critical mass of functionality is achieved. I have some suggestions that I was hoping to get feedback for from the Devs here.
1- What is the possibility for devising an in-place upgrade system that works across future OS version upgrades for major changes in AOSP? (something akin the upgrade systems of current GNU/Linux systems)
2- Incorporating apps from the guardianproject (.info) a privacy and security oriented group that make secure messaging apps and TOR for Android. That will be our anwser to the so called secure chat of CM.
3- Cooperation with the largest FOSS software repo F-Droid and perhaps including it as a default app repo option for OmniRom.
4- Now this is a big one, but as a distro that prizes Software Freedom and the GPL above all else you are in a unique position to be a demo showcase for incorporating the major app frameworks being ported to Android like Qt and Gnome. Arranging with the devs from KDE and Gnome to make this a reality would be a major milestone for the FOSS movement's efforts to bring free software in an environment that is being increasingly closed off like what Google is doing with their absorption of features in proprietary apps and the treachery of the CM turncloaks.
Casual observer here. I don't think it's accurate to call it a GPL ROM given how many non-free drivers are required to get working WiFi and so on. OmniROM encourages GPL as a way of keeping the community honest but I don't think it's set in stone.
1. upgrades on Android don't happen in same way as GNu/Linux: it's always a fresh install. CM already does this, or you can use recovery mode.
2. good idea! more generally, system wide proxy settings which would allow all traffic to go through Tor. Tor is one part of remaining anonymous, the browser needs to be locked down for example. Guardian Project say that their companion browser, Or web, doesn't work on Android 4.4, and they might stop developing it. There are other Android techniques for anonymity e.g. xprivacy.
3. F-Droid builds and signs apps, it's hard to see room for cooperation. It will soon have ability to install apps silently if part of a ROM. They dropped their Android.mk; looks like time to bring it back, maybe with package name change option.
4. Qt was announced on day one at the BBQ!
Hi everyone,
I always thought that Nexus devices comes with a pure AOSP version with some little closed-source extras, like GApps (Google Mobile Services, Play Store, Gmail, YouTube, Maps...) or hardware drivers. And for a "librist" like me, it seems fine : OS and main userspace parts are opensourced, and Google services are closed-source. All was fine in my beautiful world.
But with some search, I discovered that every time that Google push an AOSP apps on the Play Store, it is actually a closed-clone of the AOSP one.
For example :
AOSP Keyboard is not Google Keyboard (=missing gesture)
Camera is not Google Camera (=missing Photosphere)
Launcher is not "Google Experience Launcher (GEL)" (=missing Google Now Integration, normal, but also transparency)
Music is not Play Music
Search is not Google Now
recently : Email (not Gmail)
etc.
I was not worried about "additionnal closed source services/app of Google in Android" as they are what they are : additionnal.
But the new politic of Google seems to be "we have our Touchwizz/Sense of our own, now".
The main problem is : as far as I can see on the GIT source and with Android Emulator, when Google begins to develop his "alternative closed source apps of an AOSP opensource apps", the AOSP apps seems to be abandonware.
You can compare the look of Google Search (and disable Google Now, to compare properly without Google closed services) and AOSP Search. AOSP Search seems to be from FroYo design... The same with Music player.
What's your point of this situation? Does Google try to make his own front-end interface to AOSP Android like Samsung Touchwiz or HTC Sense?
What devices comes with AOSP by default and not "Android by Google" now, if Nexus is no more the case?
BONUS : Jean-Baptiste Queru, head of AOSP, resigns from Google. I don't know what happens to replace him...
Note : I am French so, if my English is not easily-readable, please forgive me .
*bump*
Here is a point of view of an official Android developers from Google (source : arstechnica[DOT]com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/?comments=1&post=26199423)
There is a good discussion to be had about Microsoft using Android, and a lot of good reasons for them to not do so... which makes it especially unfortunate that instead this was turned into yet another article here of increasingly specious and misleading claims about the "open-sourceness" of Android and Google's hidden plan to Control Android And Then The World.
First, let's make a clear statement. If Android was to be in the same position as Windows is in the PC industry, we'd have a radically more open computing environment, where it is a lot easier for small players to compete against the dominant platform on a more level playing field. I don't think anyone can argue against this. When we were designing and implementing Android at Google, this was actually one of our goals -- to create a more level playing field for everyone -- and that design perspective hasn't significantly changed over the years.
So let’s start with the setup:
Quote:
Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.
Already we see the clear bias that the article is going to take. There is however another way to state this: Google provides a lot of value on top of Android, with an ecosystem that is difficult to compete with, of cloud-based applications and services that are useful to users and developers. This is at least as true a way to describe as the quoted statement from the article, and I will argue it more accurately states the situation.
The arguments start out soft, but still misleading:
Quote:
The first is the Android Open Source Platform (AOSP) codebase. This provides the basic bones of a smartphone operating system: it includes Android's version of the Linux kernel, the Dalvik virtual machine, and portions of the basic user interface (settings app, notification panel, lock screen).
AOSP is far more than the basic bones of a smartphone operating system. It is a complete smartphone operating system. The examples you provide for what it includes are very misleading -- what about the launcher, contacts app, dialer and phone app, calendar app, camera and gallery and on? The fact is, if you build AOSP today and put it on a phone, you will have a pretty fully functioning platform.
The thing you don’t have is stuff related to cloud services, and this is not an evil secret plan of Google, but a simple fact we have been clear about from the initial design of the platform: Android as an open-source platform simply can’t provide any cloud services, because those don’t run on the device where the platform code runs. This is a key point that seems to be completely missed. If you want to understand what Android is, how it is designed, and how the pieces fit together, you must understand this point.
One of the things that is interesting about platforms today vs. the traditional desktop is that these cloud services are becoming increasingly central to the core platform experience. This presents a special challenge to an open-source platform, which can’t really provide such cloud services as part of the standard platform implementation. In Android our solution to this is to design the platform so that cloud services can plug-in and integrated with it in various ways. These may be stand-alone apps like Google Play Music, they may be plug-in services like the calendar and contacts sync providers, they may be Google proprietary APIs on top of the platform like Google Play services.
Note, however, that in all of these cases the platform has been designed to provide an open, flexible, and rich enough API that these Google services can be delivered using the same standard SDK that other app developers use. This is part of the goal of creating a more level playing field for everyone. (There are some exception where things are very difficult to safely expose to developers, but they are rare -- the Play Store’s privileges for managing your apps is one, and even there we do provide in the platform side-loading APIs so that other app stores can be implemented.)
So, GMS is Google’s proprietary code implemented on top of Android for interacting with Google’s services. There is nothing nefarious about it being proprietary -- it is interacting with Google’s proprietary back-end services, so of course it is proprietary.
Thus this makes perfect sense:
Quote:
The split between AOSP and GMS is not constant, either. Google has slowly been migrating more and more functionality to GMS. For example, in the latest Nexus 5, the core phone user interface—the thing that you use to launch apps and show icons—has been rolled into the GMS Search app.
What has happened here? Google now has their own launcher that integrates with Google’s back-end services. And what is wrong with this? Why is this worse than Facebook or Yahoo doing their own proprietary launcher? It is bizarre to complain about this, especially when Google has open-sourced everything else in their launcher except the parts that are specific to their proprietary services!
And this is the same thing:
Quote:
Similarly, APIs have made the move. AOSP contains a location API, but GMS contains a newer, better one, with additional features. Google encourages developers to use the GMS API, and the AOSP Location API mostly dates back to Android 1.0, and hasn't seen any substantial changes since Android 1.5.
First, it s very misleading to act like the platform’s location manager has been unmaintained since Android 1.5. Important features like passive providers and criteria-based updates were added much later than that; but, even ignoring verifiable facts, the Google Play services location APIs didn’t appear until last year, so what you are actually implying with this is that Google basically didn’t do any significant improvements to location from 2009 to 2013. Probably not true.
The reason for the introduction of Google’s location API, however, is again because of back-end services. Location has become increasingly dependent on cloud services: for a while now network-based location, but increasingly more things. We went for a long time with parts of the platform’s LocationManager basically not implemented because it couldn’t be, with the need for some proprietary thing to be dropped in on top of it to have a fully functioning API. As time went on this became an increasingly bad situation because we don’t want our platform to be defining APIs that it can’t also provide an implementation of, to serve as the basis for everyone to share and a reference for how it should work. So, the decision was made that Google should take responsibility of further evolution of that API since that evolution is increasingly tied to cloud services.
Quote:
Each new release increases the level of integration with Google's own services, and Google is moving more and more new functionality to GMS, leaving AOSP a barebones husk.
This is such an exaggeration that it is really hard to know how to address. AOSP is a barebones husk? Please. AOSP is far richer and more powerful today than it was in 1.0, 1.5, 2.0, or 3.0. And most importantly, one of the things we have been doing over the years is providing increasingly rich facilities for any cloud services provider to plug in to the platform. For example, in the most recent 4.4 release we have our very extensive new storage framework API, which Google uses to provide their Google Drive services to any application, and allows any other cloud storage provider to do the same thing, operating on equal footing with Google.
Quote:
That's not a small category, either, since features such as in-app purchasing are in GMS.
This gets emphasized as a significant point, but, honestly, how would you propose that in-app purchasing not go through GMS? Some general platform API to allow the app to do an in-app purchase with whoever wants to be a “purchase provider?” I can’t imagine this being a solution that people will be happy with.
Quote:
Technically, however, a company with sufficient development resources could provide its own GMS replacement. The overhead would be not insignificant, especially as—to ensure optimal compatibility—the replacement would have to replicate not just correct functioning, but any bugs or quirks of the GMS implementation.
Of course, the vast vast vast majority of the work here is implementing the back-end services in the cloud, not the proprietary glue code that runs on the device. Failing to address this is deeply missing about what is going on.
Quote:
There are also lots of little awkward aspects of the GMS API; it includes such capabilities as "share with Google+" which few companies have any real counterpart to.
In other words you don’t have your own social network, so you can’t implement Google’s API for sharing to its social network? Okay, then just have the API do nothing? Or heck, share to Facebook?
Quote:
Another example: there is an API for handling turn-based multiplayer gaming. A company could implement this API and have its own server infrastructure for managing the gaming sessions, but obviously these gaming sessions would be completely separate from Google's gaming sessions, fragmenting the player base in a way that game developers are unlikely to be keen on.
Now this could be taken as just a good argument for why Microsoft wouldn’t get as much of a competitive advantage by using AOSP, since they would still be competing with Google’s cloud services. But then it is immediately followed by:
Quote:
As an added bonus, should the ultimate resolution of Google's long-running legal battle with Oracle be that APIs are, in fact, copyrightable, this kind of wholesale reimplementation of GMS would become legally actionable. Google could, if it chose to, shut it down through the courts.
Where in the world did this come from? Google is the one fighting against that. Microsoft actually filed an amicus brief supporting Oracle. Yet you write this almost as if this case would serve part of Google’s evil plan to control Android?
Quote:
The second option—AOSP with a few extra custom extras—has the upside of providing an opportunity for Microsoft to integrate its own services… It would certainly mean omitting any high-profile title using in-app purchasing, so, say, Plants vs. Zombies 2 or the latest iteration of Angry Birds would be out.
It’s strange to focus on in-app purchasing here. The issue is that you don’t have the Google Play store, so you need to get app developers to publish their apps on your own store. In fact providing a compatible in-app purchasing API and otherwise making it easy for them to publish their app without changing it is probably the lesser problem.
Quote:
Google has pushed very significant pieces of functionality into GMS, including messaging and the Chrome browser. The AOSP counterparts are buggy, feature deprived, and by at least some accounts, barely maintained. If a company wants to use AOSP without GMS, it has a lot of work to do if it wants to produce a high quality experience. The open source parts just aren't good enough.
Again the exaggerations. Chrome is available open-source as Chromium (of course without the integration with Google’s back-end services, but why in the world would Microsoft want those?). What parts of AOSP are “buggy” compared to Google’s stuff? In fact a lot of Google’s proprietary apps are built on top of the corresponding AOSP app -- that includes Google’s Launcher, Calendar, Email, and even Gmail now. Messaging has diverged from Hangouts, but Hangouts is deeply integrated into Google services, and there is a similar situation with Music. It would be nice if some of these apps were better maintained, but (a) there are lots of equivalent apps (often based off the AOSP version) that people have written which you could license and use, and (b) implementing these apps is pretty small potatoes compared to all the cloud services Google provides.
Quote:
For Microsoft, the effort required to build a GMS workalike on top of AOSP is going to be comparable to the effort required to build the Windows Phone shell and APIs on top of Windows.
Again, the vast majority of work here is providing the back-end cloud services. Not, as keeps being implied, the proprietary bits that Google has running on Android.
Quote:
Moreover, it still implicitly gives Google control over the platform. Various aspects of how Android is used are determined by the underlying APIs: sharing between applications, for example, is done in a particular Android way. Any platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose.
Okay this is just weird. Yes, the Android platform has a well-defined sharing facility, and if you want to have an Android-compatible platform you will want it to work the same way. Just like, I don’t know, Ubuntu has a C library and you probably don’t want to change that. How in the world is this different from every other open-source platform in the world? How is Google being all controlling here?
Quote:
The fourth option—use AOSP with an entirely new software stack on top—gives freedom and flexibility, but to what end? The kernel isn't the important bit.
Wait, what? The only way I can figure out how to interpret this is to suggest that they use Linux (the kernel) but nothing above it. That can’t be what you mean, right? I honestly have no idea what this is supposed to be saying, except that it again seems to be implying Google is being all nefarious.
Quote:
If Android were an open platform in the way that Firefox OS or Ubuntu for smartphones were an open platform, the forking suggestion would make more sense.
I’ll admit I am not super-familiar with these two, so I have a question: what are the things that they have that are not in AOSP?
And finally we have further blanket statements about how Google’s goal is to make Android increasingly closed, AOSP isn’t real open source, etc, etc. I’ll just leave with the final sentence:
Quote:
Suggestions that Microsoft scrap its own operating system in favor of such a fork simply betray a lack of understanding of the way Google has built the Android platform.
Actually, I don’t think you have an understanding of how Google has built Android. I have been actively involved in designing and implementing Android since early on, and it was very much designed to be an open-source platform. Part of that design was to allow Google (or anyone) to build integrated cloud-based services on top of it, and that aspect of Android design has gotten richer as the years go on. What you are concerned about is not a design problem in Android, but the richness of Google’s cloud-based services.
At least Android creates a much more equal playing field for others to compete with Google’s services than is provided by the proprietary platforms it is competing with. I also think a good argument can be made that Android’s strategy for addressing today’s need to integrate cloud services into the base platform is an entirely appropriate model for a “real” open-source platform to take.
Click to expand...
Click to collapse
Welcome!
Introduction
After three years of inactivity, of me (the developer) simply enjoying life and riding bikes, I'm proud to announce that JDroidLib is being resurrected!
Originally inspired by AndroidLib by @regaw_leinad, JDroidLib is a Java class library aimed to ease the development of Java applications designed to communicate with Android-powered devices.
The end goal was to make the library as easy and efficient to use as possible, and while the original library was easy to use, some fairly bad design choices were made on my part to make that happen.
After a turn of recent events, I've found myself to have somewhat more free time on my hands and decided to re-visit the project.
After looking through the (well-documented) source code of the original library, I decided that in order for an update to make sense, I'd have to completely re-write the library.
After a couple of hours of development and building the base, I had come up with a structure and code design that I was happy with and continued from there.
A few days after development began, I created a new repository on GitHub and thus, JDroidLibv2 was born!
The original version of JDroidLib was featured multiple times on the XDA platform and on other networks, as well.
Ok, great! But why should we care?
There are two very simple answers to this question!
If you're not a Java developer, or you have no interest in building Java applications that communicate with Android devices, such as flashing, rooting, or diagnostic tools, then you absolutely don't have to care! That's the beauty of it.
If, however, you are either of those, then you should give JDroidLib a closer look!
JDroidLib is designed to be efficient and easy to use.
Getting the library integrated in to your project is as easy as clicking a couple of times and calling it a day!
Now, I hear you ask: What's the upside to using your library?
Also a question that is very easy to answer.
Using JDroidLib, your application has next to no boilerplate code, meaning the footprint of your actual application is minimal and thanks to fast initialisation routines, your application will suffer minimal latency.
Thanks to both synchronous and asynchronous operations, your UI application will feel responsive to your users and your application less bloated.
JDroidLib includes shortcuts to commands that are often used and helper classes that cleanly sort and store data, so your application doesn't have to!
What design choices have you made?
JDroidLib is designed to be as easy to use as possible, while being efficient at what it does.
To implement these ideas and this design, JDroidLib uses a variety of designs that all work together to create an efficient library:
Factories to easily define the things you need
Singletons to prevent resource hogging and minimise the risks of memory leaks
Both synchronous and asynchronous methods so you can choose what's best for you!
Strongly typed
Provides features that otherwise prove useful in applications, such as tuples
Genericism
Ok, that's cool and all, but when will it be ready?
As it is, JDroidLibv2 is currently in an early beta. Its features are not yet fully implemented and a lot of things are missing.
All I can say for now, is it'll be ready when it's ready.
It could take weeks, or even months - depending on how much time I have.
I'm hoping the repository will be updated regularly!
End notes
If you're interested in the project, the link to the source code repository can be found below.
In later posts I will add current features, todos, and more relevant information!
Happy coding!
XDA:DevDB Information
JDroidLibv2, Tool/Utility for all devices (see above for details)
Contributors
Beatsleigher, Beatsleigher
Source Code: https://github.com/Beatsleigher/JDroidLibv2
Version Information
Status: Beta
Created 2017-10-06
Last Updated 2017-10-07
Reserved
Current Features
Automatic initialisation
Installation/downloading of platform-specific platform-tools packages
Start/stop ADB server
Get list of devices
Execute custom commands (sync and async!)
Connect to and disconnect from devices via TCP/IP
Manage device filesystems
Get root and busybox information
Get device battery information
Current Todos
Complete Device class
Build file manager
Get battery information
Get SU/busybox information
Get CPU/RAM information
Build buildprop manager
Add reboot methods
Finish JavaDocing everything
Add (complete) wiki to GitHub
Add homepage to GitHub (I've no more website)
Add feature requests from potential users?
Continue updating
Elements that are stroked are completed/ideas that have been scrapped.
Reserved
Useful Links
Source Code
https://github.com/Beatsleigher/JDroidLibv2
Issue Tracker
https://github.com/Beatsleigher/JDroidLibv2/issues
Wiki and Guides
https://github.com/Beatsleigher/JDroidLibv2/wiki
Release Downloads
https://github.com/Beatsleigher/JDroidLibv2/releases
Todo: Upload to Maven Central
Social Media (Updates)
Google+
Twitter (not as regular, though)
JDroidLibv2 has been released in an open beta!
https://github.com/Beatsleigher/JDroidLibv2/releases
Welcome!
Introduction
After three years of inactivity, of me (the developer) simply enjoying life and riding bikes, I'm proud to announce that JDroidLib is being resurrected!
Originally inspired by AndroidLib by @regaw_leinad, JDroidLib is a Java class library aimed to ease the development of Java applications designed to communicate with Android-powered devices.
The end goal was to make the library as easy and efficient to use as possible, and while the original library was easy to use, some fairly bad design choices were made on my part to make that happen.
After a turn of recent events, I've found myself to have somewhat more free time on my hands and decided to re-visit the project.
After looking through the (well-documented) source code of the original library, I decided that in order for an update to make sense, I'd have to completely re-write the library.
After a couple of hours of development and building the base, I had come up with a structure and code design that I was happy with and continued from there.
A few days after development began, I created a new repository on GitHub and thus, JDroidLibv2 was born!
The original version of JDroidLib was featured multiple times on the XDA platform and on other networks, as well.
Ok, great! But why should we care?
There are two very simple answers to this question!
If you're not a Java developer, or you have no interest in building Java applications that communicate with Android devices, such as flashing, rooting, or diagnostic tools, then you absolutely don't have to care! That's the beauty of it.
If, however, you are either of those, then you should give JDroidLib a closer look!
JDroidLib is designed to be efficient and easy to use.
Getting the library integrated in to your project is as easy as clicking a couple of times and calling it a day!
Now, I hear you ask: What's the upside to using your library?
Also a question that is very easy to answer.
Using JDroidLib, your application has next to no boilerplate code, meaning the footprint of your actual application is minimal and thanks to fast initialisation routines, your application will suffer minimal latency.
Thanks to both synchronous and asynchronous operations, your UI application will feel responsive to your users and your application less bloated.
JDroidLib includes shortcuts to commands that are often used and helper classes that cleanly sort and store data, so your application doesn't have to!
What design choices have you made?
JDroidLib is designed to be as easy to use as possible, while being efficient at what it does.
To implement these ideas and this design, JDroidLib uses a variety of designs that all work together to create an efficient library:
Factories to easily define the things you need
Singletons to prevent resource hogging and minimise the risks of memory leaks
Both synchronous and asynchronous methods so you can choose what's best for you!
Strongly typed
Provides features that otherwise prove useful in applications, such as tuples
Ok, that's cool and all, but when will it be ready?
As it is, JDroidLibv2 is currently in an early beta. Its features are not yet fully implemented and a lot of things are missing.
All I can say for now, is it'll be ready when it's ready.
It could take weeks, or even months - depending on how much time I have.
I'm hoping the repository will be updated regularly!
End notes
If you're interested in the project, the link to the source code repository can be found below.
In later posts I will add current features, todos, and more relevant information!
Happy coding!
XDA:DevDB Information
JDroidLibv2, Tool/Utility for all devices (see above for details)
Contributors
Beatsleigher, Beatsleigher
Source Code: https://github.com/Beatsleigher/JDroidLibv2
Version Information
Status: Beta
Current Beta Version: oct_17_beta
Created 2017-10-14
Last Updated 2017-10-13
Reserved
Current Features
Automatic initialisation
Installation/downloading of platform-specific platform-tools packages
Start/stop ADB server
Get list of devices
Execute custom commands (sync and async!)
Connect to and disconnect from devices via TCP/IP
Manage device filesystems
Get root and busybox information
Get device battery information
Current Todos
Complete Device class
Build file manager
Get battery information
Get SU/busybox information
Get CPU/RAM information
Build buildprop manager
Add reboot methods
Finish JavaDocing everything
Add (complete) wiki to GitHub
Add homepage to GitHub (I've no more website)
Add feature requests from potential users?
Continue updating
Elements that are stroked are completed/ideas that have been scrapped.
Reserved
Useful Links
Source Code
https://github.com/Beatsleigher/JDroidLibv2
Issue Tracker
https://github.com/Beatsleigher/JDroidLibv2/issues
Wiki and Guides
https://github.com/Beatsleigher/JDroidLibv2/wiki
Release Downloads
https://github.com/Beatsleigher/JDroidLibv2/releases
Todo: Upload to Maven Central
Social Media (Updates)
Google+
Twitter (not as regular, though)
JDroidLibv2 has been released in an open beta!
https://github.com/Beatsleigher/JDroidLibv2/releases
Sorry about the duplicate post, but I thought this was a more relevant place to post this information. Please let me know if I should remove it
I was told people here may be interested in a de-googled, free and open source assistant for Android since there is currently no alternative that fits this bill out there. I’ve been working on an assistant which is currently in a pre-alpha state, under the working title: Sapphire Assistant Framework.
At first install, the assistant will act as a drop in replacement for Google Assistant, running Assistant optimized apps, and voice commands without requiring Google services. (This feature is still a work in progress). It is designed to run on device without needing network services or root privileges, the goal is to have a useful and flexible mobile assistant under the full control of the user. Since everything is ran on device and the source code can be vetted, the user can be sure that their assistant isn’t gathering or transmitting any data where it doesn’t belong.
The roadmap for the project includes Mycroft compatibility, Termux and Tasker integration, as well as a tool set for power users that can be used for developing unique, customizable assistants tailored to their individual needs.
Again, though significant progress has been made and I’m preparing for the first Alpha release, it is not yet feature complete. However, I am happy to answer any questions about it and if you’re interested in tracking the status of the project you can find posts on Reddit, Message me on Matrix, or find the source code on Github.
I welcome any feedback and input, and look forward to hearing your thoughts and opinions on the project. I also welcome input from other developers as the better the design, the more we all benefit from it
+
I look forward to using it