Database Info

Feature request for Android market: filter by Build.DEVICE: need your help

Hi pals
As many apps developers here on XDA what I develop and publish on Android market is device-specific.
(Free and Commercial)
Those apps
- require certain hardware features (like an Audio codec, Super AMOLED screen & driver), often related to additional Kernel features.
- can only support a limited set of devices but also Kernel versions.
And like everyone I'm really annoyed by 1-star comment.
"pure crap, doesn't work on my beloved phone"
Of course, it's not the majority, but its always increasing with the popularity.
It's annoying when its free apps, but when you decide to sell apps and try to give the best service, it becomes really bad.
And people disappointed is really not what you hope when you share your creation.
This is why I'll appreciate some backup from you by leaving a comment on this thread named
Missing filter by Build.DEVICE and ability to contact customers from comments
I propose the idea of filter by Build.DEVICE because it's useful for my app. You need additional filters too right ?
By custom ROM? By Kernel version? Explain you needs
− in this thread on official Market forum of course - writing your comment here is nice too.
We are all used to an unprecedented level of user support here on forums, by the hackers themselves or the community of users. This is really something special.
Its maybe a bit bold to say that, but I'm sure Android Market has a lot to learn from communities like ours in order to improve its consumer satisfaction... so lets show them how to
PS: sorry for inviting people to another page (Google's one) at the occasion.
This is, I guess the best way to be heard by them: by posting on their dedicated tool for requesting features (they'll read)

supercurio said:
I propose the idea of filter by Build.DEVICE because it's useful for my app. You need additional filters too right ?
By custom ROM? By Kernel version? Explain you needs
Click to expand...
Click to collapse
Filtering by ROM / kernel is way too specific, but by device is great. I support this proposal.

this would be an incredibly useful feature for developers on XDA. since many hobbyist developers put an app that only works on the device they're developing it for, it would make sense to be able to whitelist or blacklist certain phones so they can be restricted to certain phones.
for instance, I'm sure the developer of RealHDMI (the Droid X HDMI mirroring app) would have loved this feature when people with EVO's were trying to install and were (not shockingly) unable to use it and giving the developer negative feeback. for a community such as this, I can't help but see how this could be an amazing addition to the marketplace.

I don't think its realistic. Google may well come round to a warning message (after accepting permissions perhaps?) saying 'your device is not supported'. This would help in situations such as the Android 2.1 Galaxy S's inability to play ball with Skype, and various games that don't support or fully support some chipsets, as well as your own, very real, problem.
Filtering per device will only pave the way for more fragmentation jibes and claims by Apple/Microsoft that Google are inflating number of apps available. We have to remember Google's priorities: PR > OEMs > Developers > Consumers > Facebook. They *need* to stop any fragmentation claims and *need* to boost app numbers in line with App Store, all to prevent counter PR.

HazzBazz said:
I don't think its realistic. Google may well come round to a warning message (after accepting permissions perhaps?) saying 'your device is not supported'. This would help in situations such as the Android 2.1 Galaxy S's inability to play ball with Skype, and various games that don't support or fully support some chipsets, as well as your own, very real, problem.
Filtering per device will only pave the way for more fragmentation jibes and claims by Apple/Microsoft that Google are inflating number of apps available. We have to remember Google's priorities: PR > OEMs > Developers > Consumers > Facebook. They *need* to stop any fragmentation claims and *need* to boost app numbers in line with App Store, all to prevent counter PR.
Click to expand...
Click to collapse
Its not by ignoring facts and developer needs that you prevent fragmentation.

[APP]daPlot

I'm developing an android interface for a J2ME app I've written.
It is a 2d/3d plotter for implicit/explicit/parametric/polar/differential equations.
It has many advanced capabilities (not all of them are accessible from GUI, but all of them are in the code):
user defined functions, matrices, complex numbers, step-by-step resolution for 1st and 2nd degree systems...
It's still in "very alpha" state, but I think it is mature enough for some early testing.
You can find the code at:
https://github.com/miniBill/mePlot
And the apk at:
http://minibill.users.anapnea.net/file/daPlot.apk
And a web page that uses the same backend at:
http://minibill.users.anapnea.net/webplot.php
And an example of what it can do at (takes a while to load):
http://minibill.users.anapnea.net/webplot.pl?fun=sinx+siny+sinz&size=1000
It requires not permission whatsoever (not even reading/writing SD), so it should be safe even in case I made mistakes.
The final license is not defined yet.
The license for the current state is:
you can distribute it verbatim, as long as it is still in pre-release state (which means, until I have released the final version)
you cannot distribute modified versions
you can modify it, and use modified versions on your devices
you can continue to use the pre-release version forever (you cannot distribute it though)
you must attribute the program to me
Bonus:
if you find a bug I didn't already found, or give me a good idea, you get one free license for version 1.0
if you find a serious bug I didn't already found, or give me a great idea, you get one lifetime license
I might consider to eventually release it under GPL, and I will surely release a free version [which will probably be a "lite" version].
Oh, and anyway I'll almost surely keep the source code visible and let people modify it. Maybe I could just require people to buy the program before using it, but then they will be able to share code... I'm open to ideas.
Basically, I want to profit from it, but still allow users to modify it.
I hope someone will test it

[APP] FlowReader - Save this awesome RSS reader

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.

Mission Impossible: Hardening Android for Security and Privacy

Executive Summary
The future is here, and ahead of schedule. Come join us, the weather's nice.
This blog post describes the installation and configuration of a prototype of a secure, full-featured, Android telecommunications device with full Tor support, individual application firewalling, true cell network baseband isolation, and optional ZRTP encrypted voice and video support (ZRTP does run over UDP which is not yet possible to send over Tor, but we are able to send SIP account login and call setup over Tor independently).
Aside from a handful of binary blobs to manage the device firmware and graphics acceleration, the entire system can be assembled (and recompiled) using only FOSS components. However, as an added bonus, we will describe how to handle the Google Play store as well, to mitigate the two infamous Google Play Backdoors.
Introduction
Android is the most popular mobile platform in the world, with a wide variety of applications, including many applications that aid in communications security, censorship circumvention, and activist organization. Moreover, the core of the Android platform is Open Source, auditable, and modifiable by anyone.
Unfortunately though, mobile devices in general and Android devices in particular have not been designed with privacy in mind. In fact, they've seemingly been designed with nearly the opposite goal: to make it easy for third parties, telecommunications companies, sophisticated state-sized adversaries, and even random hackers to extract all manner of personal information from the user. This includes the full content of personal communications with business partners and loved ones. Worse still, by default, the user is given very little in the way of control or even informed consent about what information is being collected and how.
This post aims to address this, but we must first admit we stand on the shoulders of giants. Organizations like Cyanogen, F-Droid, the Guardian Project, and many others have done a great deal of work to try to improve this situation by restoring control of Android devices to the user, and to ensure the integrity of our personal communications. However, all of these projects have shortcomings and often leave gaps in what they provide and protect. Even in cases where proper security and privacy features exist, they typically require extensive configuration to use safely, securely, and correctly.
This blog post enumerates and documents these gaps, describes workarounds for serious shortcomings, and provides suggestions for future work.
It is also meant to serve as a HOWTO to walk interested, technically capable people through the end-to-end installation and configuration of a prototype of a secure and private Android device, where access to the network is restricted to an approved list of applications, and all traffic is routed through the Tor network.
It is our hope that this work can be replicated and eventually fully automated, given a good UI, and rolled into a single ROM or ROM addon package for ease of use. Ultimately, there is no reason why this system could not become a full fledged off the shelf product, given proper hardware support and good UI for the more technical bits.
Click to expand...
Click to collapse
https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy

Pretty much what Guardian ROM is doing. I look forward to all the new builds
Truth. Transparency. Technology

App Ideas : A must have app for developers

Appideas is a storage as well as a support for creative developers with ideas for apps and game. No matter where you are when the inspiration comes along, with this app you will not lose any ideas.
Select a category, where the planned app belongs to, choose a name, describe the basic idea and save the base frame until you find the time to develop the project.
App Ideas also offers you support your running projects. Changed your idea from the theoretical state into practical development, you have the ability to note individual subgoals as well as emerging bugs and work through it step by step and fix it. The development is divided into 2 stages, called Alpha and Beta, so after the first goals have been achieved, you send your app in the second phase and can register new destinations and mistakes. Futhermore you can stay connected with potential partners and mutually transmit tasks.
Has your idea become a finished app, it is stored in the Release-folder.
You can use App Ideas, made in beautiful material design for free up to four ideas. If you need more capicity, you can aquire the Pro-version. This is possible in two ways, which are explained to you in the menu of the free version.
https://play.google.com/store/apps/details?id=com.mt.appideas
Apk