Good news for the open source crowd.
Google's Android developers head to the blog today to let us know it has migrated the AOSP issue tracking system to use its own Issue Tracker software.
Issue Tracker is the tool Google uses internally while building and maintaining all the various stuff it does. It's also the public facing bug tracker for many of its other products, including the Android O Developer Preview. The new system looks and feels very much like Google Groups, and Google says this makes it easier for everyone to be on the same page when it comes to finding and killing bugs.
We are hoping to facilitate a better collaboration between our developers and our Android product teams by using a tool we use internally at Google to track bugs and feature requests during product development.
Issue Tracker also uses standard Google terms of service, so be sure to read what you are agreeing to the first time you use the service.
For most end users this has zero impact. But know that the people developing Android and fixing the inevitable bugs should now be able to better communicate. Everything works better when everyone involved knows what's up.
We don't need copy/pasted articles here, with no credits or source. That's called plagiarism. :good:
Thread Closed.
Related
As an app developer, I find b.android.com (Android Issues) to be very valuable even though it isn't really maintained and is quite limited in its capabilities.
The good news is that there are indications that they are good to start maintaining it,e.g.:
http://groups.google.com/forum/?fromgroups#!topic/android-contrib/H1jjtoKjucI
The bad news is that they are making changes to its scope which will make the issues database pretty much useless for app developers.
I'm not surprised to see them close issues that dealt with Google apps or consumer facing issues in general - it was never meant for that and wasn't working. Google is now directing consumers to their product support services, and I think they are simultaneously really working to improve those consumer support services.
I'm much more concerned that they are planning to limit it to AOSP. I think that is in line with its original purpose, and many may applaud this move - but it makes it useless for me as an app developer. Quite simply - I need to know about issues on all Android devices, not just AOSP.
So, I think this could be an opportunity for XDA to expand their developer services. I actually think that the issue database could work much better at XDA then it has at Google. The Android issue tracker was always desperately in need of the kind of care and maintenance that XDA developers could give it. It also needed an appearance of impartiality and separateness from Google - there has always been a certain combativeness and anger on the issue tracker that wasn't productive. Finally, I think it could benefit from being more code and discussion friendly. Issues call for solutions, and the limitations of the current issue tracker meant that while the issue was listed at b.android.com, we had to go to stackoverflow for the discussion and the solution.
This is a long shot, but I since the demise of Google Reader (which this app supported) the developer has decided to no longer continue the development of this app. A tragedy; I think we as a community should try and sway him to continue it instead, adding new back ends, both Feedly and TOR (TheOldReader) support would be great. I would love to continue using this app, as it is probably the best RSS reader I have encountered on Android. It is my hope that we can either convince him to continue the project or allow someone else to (any volunteers ?).
Flow Reader gives you an easy way to be on par with your RSS/Google Reader feeds on the go. It was built to provide a minimalist and seamless experience for offline browsing, while delivering additional features not found in similar apps.
Some of the main features include:
- A sleek and fast user interface;
- Offline item content and state caching;
- Multiple simultaneous downloads for fast content synchronization;
- Content filters that automatically mark as read the items you're not interested in;
- Sort items by state (latest/unread/starred) or author;
- Smart algorithms that remove ads and other undesirable content from items;
- No ads.
Click to expand...
Click to collapse
The Developer posted this statement in the most recent app update:
As you sure know by now, Google has discontinued the Reader service, so this app is no longer functional.
Although I am very happy with the (unexpected) success of this app, I've decided to no longer update Flow Reader. This is due to several reasons: a) I built this app "for fun" and to my very specific RSS reading needs. Although I very happy to see that a lot of other people enjoyed it, I was in no way ready for attention it received (due to multiple technical and logistic reasons); b)This app was essentially just a prototype turned into a final product. The Code is very messy right now and it's becoming harder and harder to make any further changes, let alone any major ones (like background updates). c) The app is *very* tied to Google Reader backend, which means that giving proper support to another service would require a very significant amount of effort.
I am very thankful to all my users (especially the ones who donated and gave feedback!), but I hope you can understand the reasons behind this decision - continuing to work on this app would require a major rewrite and too much time trying to (once again) and make the pieces all fit with "spit and glue".
If you are interested in any future app I might develop, you can be notified about it by sending me an e-mail using the button below. You will know beforehand of any project I might be working on (and maybe even receive an alpha/beta version of it?).
Thank you again - and hopefully this won't be the end
The Developer
Click to expand...
Click to collapse
Those who have used the app please voice your support to continue the project as I have emailed the developer the link to this thread.
(Flow Reader dev here)
Right, here's what's going on:
Personally, I'm not very happy with any of the current readers on the Play Store, so the idea of building the next iteration of Flow Reader is one that I really enjoy. Unfortunately, I simply don't have the time that I would need to keep developing it any further. I now have a full time job and not much patience to keep working on the app on my spare time.
The thing is, I have several unique ideas that I believe would greatly improve the experience of Flow Reader. Actually, some of these already graduated from just ideas, as some prototyping is already done and working. I also think there is a decent amount of money that could be made from them, so I'm not very willing to just leave them out in the open.
The fact is, though, it is very unlikely that I'll ever finish this new version of the app that I'm building. I can see two options right now:
OPTION 1 - The cooperation route:
- I will pair with another developer (or a small group of developers). Bear in mind that the code is reasonably complex, so i'd rather work with someone that feels confortable around code.
- The code of Flow Reader will remain closed, but shared with the people that want to be part of this project;
- I will take care of the things that I believe to be my greatest strength: UIX and prototyping. But I will always be open to suggestions on these areas.
- The profit of the app will be split 25% (for me) and 75% (for the other developer(s)).
OPTION 2 - The free route:
- I open up the code of Flow Reader under the condition that it will forever remain open-source and free (under an attribution, no derivatives and no commercial use licence).
- I will no longer will have any direct input or cooperation on the app.
Also, I honestly think it would be better to start the app from scratch. The code is a complete mess right now so trying to build more features upon it would just be less efficient. Still, some techniques and code used in Flow Reader could be reused to save some time.
Choices
I have been a user of Flow Reader for some time and was really sad when it stopped working and that the dev stated that there was no longer going to be updates to continue after the demise of Google Reader.
That said, I totally agree that it should be continued into the post-Google Reader era of RSS news. I originally created a post on Reddit in which I stated that for the continuality of Flow one idea would be to open source the code on a git site to allow others to progress his work further.
Understandably this poses the risk of Flow Reader loosing it's (work)Flow. All that time and effort the dev put in to creating a stunning, and above all easily functional, UIX could well be lost. On the other hand the simplicity of this RSS reader coupled with its parallel article downloading feature would live on and enrich many an Android RSS fans.
So here I am on XDA, stating my opinions for the two options presented.
For the Closed Sourced Approach:
The idea of sharing the workload will mean that whoever is chosen to work on Flow Reader will most likely have a great deal of knowledge to input in to this project. It also means that the UIX will not change without considerable thought first. This I applaud.
The fact that the developer says that the proceeds of the app will be divvied up indicates to a paid app, further indicating to (hopefully) a group of developers with the incentive to push great work "out the door".
For the Open Sourced Approach:
The hands of many a developer could make this app into something even better than it already is....
...or it could ruin it with out the guidance of the one who had the vision in the beginning.
Usually in the open source community when there is a bug and/or a missing feature, if someone with the appropriate know how can fix it, it shall be done.
A question, then, to WildMoves. Would those who have donated need to pay again once it arrives back on the play store? That is if you are going to make it a paid for only app?
Either way, with the way that Flow Reader handles feeds I honestly have never, and believe never shall, discover one better. To which I would like to say that no matter which direction the dev goes, I will support and give as much feedback as I can.
Again, great work mate and keep on coding,
Skinna a.k.a Skinnx86
Skinna said:
I originally created a post on Reddit in which I stated that for the continuality of Flow one idea would be to open source the code on a git site to allow others to progress his work further.
Click to expand...
Click to collapse
Yes, when I posted my answer I was still trying to develop the next iteration of Flow Reader. I built a prototype to test several ideas before I came to the realization that I couldn't build the full app the way I wanted to in a feasible amount of time and still... well... live. :\ So I am now receptive to offset most of the workload to a developer or group of developers (hence the 25/75 profit split).
Skinna said:
A question, then, to WildMoves. Would those who have donated need to pay again once it arrives back on the play store? That is if you are going to make it a paid for only app?
Click to expand...
Click to collapse
I have the email addresses of everyone who donated, so I could probably create a mailing list to deliver full versions of the (paid) app outside the Play Store. Assuming that I would have the approval from the other developers, it would be a good sign of gratitude to those who donated, IMO.
Reasonable Thoughts
Well a man has to live. To spend your free time developing and building something you would expect some payback of some sort. But thank you for remembering us early adaptors. I know I for one will be thankful, I can but imagine others will be too.
As much as I was appreciative of the beta's being sent to us, but in case you did not hear, Facebook updated some peoples app out side of the play store. Now Google have banned out-of-market beta testing. I believe that sending an apk to install initially will work and should update through the play store correctly.
Hello,
I'm Marc Aurel and I'm working with some other developers on the Volla Phone with a custom Android without Google Apps and Play Services. In addition to privacy protection the focus is a new simplified user experience beyond the app centered paradigm of current mobile operating systems.
We'll soon publish our code to invite developers to join the project or just have a look, what we are doing. We want to invite developers to our 2nd community days from 6 to 7 of June with a hackathon. You can find the announcement of the event with a live stream right here in our blog post. https:// volla.online /blog/files/community-days-2020.html
As a developer I will have some questions and I'm happy to answer some questions. I work on the launcher of the Volla OS, implemented with Qt, by the way. So I may can help or exchange experiences with developers working with this technology.
Very nice to see a phone that ships without any Google stuff out of the box. As many users switch to open source operating systems to avoid bloatware and manufacturer stuff sniffing their privacy this is a great project!
I hope the announced hackathon will result in many good ideas and approaches to improve the OSs compatible with the phone (as it also will support Ubuntu touch).
I'm looking forward to hear the results!
SHA_NDY said:
Very nice to see a phone that ships without any Google stuff out of the box. As many users switch to open source operating systems to avoid bloatware and manufacturer stuff sniffing their privacy this is a great project!
I hope the announced hackathon will result in many good ideas and approaches to improve the OSs compatible with the phone (as it also will support Ubuntu touch).
I'm looking forward to hear the results!
Click to expand...
Click to collapse
Thanks you for your motivating replay. We'll soon publish our source code of the Android based Volla OS after we have already published our source code for the Ubuntu Touch port in GitHub..
Beyond a discussion on measures to improve data protection, for which short presentations are welcome, we would like to explore ways to improve the user experience in the hackathon. One challenge will be the implementation of a system-wide sidebar that can be displayed with a border gesture. I'll post screenshots as soon I have the rights to post links.
Here the announcement for the community day:
https://volla.online/blog/files/community-days-2020.html
We have prepared an event page, that will be updated soon. You find it on volla.online/vcd2020 for Volla Community Days 2020. We hope to have participants of the Android developer community for our hackathon.
This may be stupid, but I couldn't find any resources regarding this. We have custom recoveries for android devices but why isn't there custom bootloaders like there is for PCs ? Like in the PC space we have the likes of reFind and gnu grub.
Thanks
There are some instances of alternate bootloader projects. Just that they are not popular,
[Bootloader] LK for Xperia T
LK for Xperia T LT30p Only - Unlocked Bootloader Required WARNING 1: This modification makes changes to the devices partition table. I (lilstevie) am not responsible for any damage to your device or data loss that may occur. WARNING 2: ICS...
forum.xda-developers.com
EFIDroid
EFIDroid is a easy to use, powerful 2ndstage-bootloader based on EDKII(UEFI). It can be installed one-click with the EFIDroidManager app. You can add/remove/edit multiboot ROM's. There's no special support needed by ROM's or RecoveryTools(no...
forum.xda-developers.com
The developer of EFIdroid stopped developing in 2019.
efidroid on Android 9 and 10 devices ? · Issue #152 · efidroid/projectmanagement
Hi, I just want to know if efidroid supports devices with 6 GB RAM and 64/128 GB Storage devices running Android 9 and Android 10 ? thanks.
github.com
Not to mention you would need OEM's to cooperate....
Thanks @karandpr for that github comment a lot of info there. Thanks @galaxys too. So a quick summary would be that the reason is that for the bootloader to work smoothly there has to be support from the kernel too, which the OEMs should do and probably would not. But I didn't think about the support in the kernel was an issue. That does seem to be a lot of work and I see the reason now.
al_l_en said:
Thanks @karandpr for that github comment a lot of info there. Thanks @galaxys too. So a quick summary would be that the reason is that for the bootloader to work smoothly there has to be support from the kernel too, which the OEMs should do and probably would not. But I didn't think about the support in the kernel was an issue. That does seem to be a lot of work and I see the reason now.
Click to expand...
Click to collapse
I don't think Google intends to open up android anymore. They want restrictions like iOS but pretend to be open source for the "goodwill". What's the use of AOSP if you cant effectively install it on a device or your important apps don't work?
I believe PinePhones are the ones that can have truly open-source compatible hardware. The specs are underwhelming but the community is really good.
You can get spares easily and the battery is removable.
Only thing is they are mostly out of stock.
karandpr said:
I don't think Google intends to open up android anymore. They want restrictions like iOS but pretend to be open source for the "goodwill". What's the use of AOSP if you cant effectively install it on a device or your important apps don't work?
I believe PinePhones are the ones that can have truly open-source compatible hardware. The specs are underwhelming but the community is really good.
You can get spares easily and the battery is removable.
Only thing is they are mostly out of stock.
Click to expand...
Click to collapse
Yeah those are great but the problem is that they are not usable for "normies" which will prevent mass adoption and hence cannot have a sustainable business model.
But I think google is not the only one to blame, like couldn't the OEMs actually provide bootloaders that can boot signed os images. Or is there any technical or security difficuties in doing that.
al_l_en said:
Yeah those are great but the problem is that they are not usable for "normies" which will prevent mass adoption and hence cannot have a sustainable business model.
But I think google is not the only one to blame, like couldn't the OEMs actually provide bootloaders that can boot signed os images. Or is there any technical or security difficuties in doing that.
Click to expand...
Click to collapse
Normies are afraid to change the default browser, so bootloader is really out of their leagues.
Phone tinkering is a hobby, not a necessity. Phone tinkering itself is not a sustainable model.
Google is to blame primarily. Because they have a stringent list of requirements for devices to pass CTS. You can read the bootloader requirement and judge yourself.
Android 11 Compatibility Definition | Android Open Source Project
source.android.com
Without passing CTS, devices cannot use Google apps, they cannot get push notifications and they cannot pass SafetyNet checks used by most banking apps.
At the end of the day do I want to spend 100s of hours to bring a feature to an android phone which will probably be used by 10 users and deprecated by the time I finish doing it?
or do I want to buy a phone which will allow me to tinker freely in a community and ecosystem which allows modification?
For our tinkering pleasures, Pinephone is the way to go for now. They have support from Manjaro, Debian and KDE. Which is a big thing IMO.
Or else there you can roll your thing in RaspberryPi?
While going through related details I found an article about google probably switching to hardware based safetynet checks which could be ending google play compatibility on custom roms.
It really seems like google is using security as an excuse to make sure that there are no competitors in their business space.
Maybe this is because I have been only doing web development and only started learning app dev, but the reasons google use for CTS like for enforcing DRM, is also handled on websites while allowing openness and being neutral (or maybe the web is not as secure as something like this, so forgive me if I am wrong). Android could really take pages off the web ecosystem for being a neutral platform.
I really appreciate the patience for hearing out and also the references(and the rabbit holes that it was followed by) really taught me a lot about general android architecture.
al_l_en said:
While going through related details I found an article about google probably switching to hardware based safetynet checks which could be ending google play compatibility on custom roms.
It really seems like google is using security as an excuse to make sure that there are no competitors in their business space.
Maybe this is because I have been only doing web development and only started learning app dev, but the reasons google use for CTS like for enforcing DRM, is also handled on websites while allowing openness and being neutral (or maybe the web is not as secure as something like this, so forgive me if I am wrong). Android could really take pages off the web ecosystem for being a neutral platform.
I really appreciate the patience for hearing out and also the references(and the rabbit holes that it was followed by) really taught me a lot about general android architecture.
Click to expand...
Click to collapse
Theoretically, Google can end GPlay compatibility on Custom ROMs anytime they wish. It's just that lot of App Developers don't use SafetyNet the way it is intended and Google doesn't roll out its strict check. They do it once in a while.
They don't have any competitors in their business space. It's a very well-thought monopoly.
CTS restricts Google Play API access to vendor operating systems. So vendors like Samsung, OnePlus and others have to play by their rules. IIRC, the cost of Play API is around 15$ per device but it is subsidized for large quantities.
End users don't really care about Play API. But App Developers do.
Without Play services, there is no easy way to integrate push notifications, ads, maps, analytics, metrics, and so on. Rolling your own thing will take years to develop and won't work as seamlessly as the play service counterparts.
I don't think Google will ever cede their monetary interests for open collaboration.
karandpr said:
I don't think Google will ever cede their monetary interests for open collaboration.
Click to expand...
Click to collapse
Yeah that's for sure. The only way this monopoly can break is when an opensource alternative to google play services and other apis exist and while doing that it must be compatible with the existing google apis. And that is probably not going to happen in a long time. Although microg does solve this to some extent, but still it is a second citizen.
Some of the functionality is already there, like most of the google apps like docs and drive could replaced by nextcloud and then maps could be replaced by osmand. If some company, preferably an OEM, comes and integrates all of these into a package maybe there's hope. I think /e/ os tries to do this to some extent.
You might find this resource useful. As they have gone over a comprehensive set of bootloader software and tried to outline their primary features in detail. Hopefully, you’ll be able to determine the best one for your use case. https://www.ubuntupit.com/best-linux-bootloader-for-home-and-embedded-systems/
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