[CLOSED] No Longer Required
I support this idea and will bump the thread.
The source for Webtop is available here.
http://sourceforge.net/projects/motorola-webtop.motorola/
I think a better question is, besides not being available what is stopping this from happening?
I have a hard time understanding a changelog. I mean, I obviously know what they are for, but I'm flashing Vanir 4.4.2 Nightly Builds a lot. I see the specific phone names and underneath of the that, what was merged since the previous nightly. I think I'm correct so far... Then sometimes I see several paragraphs of merged improvements with no specific phone attached to it. Does that mean it's merged to all phones? Lastly, a lot of times when I look at a changelog, I don't see my device (Nexus 5). Does this mean that nothing was merged or fixed for my phone? I usually can find most changes by reading through the Rom thread, but I'd like to be able to know for myself. Any help would be greatly appreciated. Thanks.
NEXUS 5
the trees are separate as far as I know, or better yet there are specific things for certain devices, so for simplicity yes, if there are no common stuff pushed and no changes for your device the "nightly" will bring not much, if anything.
Typically changes that are followed by specific devices are exclusive to those alone. Any changes that don't would be for all devices that are supported by the ROM. So if you don't see Nexus 5 or Hammerhead, then the changes that apply would be ones that don't have a specific device attached to it.
So I've noticed that test builds of MX Player Pro become available here however it's much easier to receive updates through the Play Store automatically rather than having to regularly check the website for new test builds. Many app developers use Google+ Communities or Google Groups that use Google's beta-testing and staged rollouts feature to automatically keep people in that group up to date with the testing version of an app so that if somebody is marked as a tester for the app on their Google account and they install the app through the Play Store then they will automatically receive the test version of the app rather than the regular stable version that most people will receive through the Play Store, this encourages more people to become testers and submit bug reports as well as makes the app updating process easier for testers and ensure that they're all up to date so they're not submitting bug reports for an old version of the app. Is there any chance of having something like this for MX Player Pro? I had a look around and couldn't find something like this but please show me if it already exists.
EDIT: If this could happen then it would also be very helpful for the custom codecs too.
TL;DR
Anyways, someone has already asked before, and the developer said he will think about it for MX v2.0. The developer actually explicitly stopped using Play Store beta in the past for some unspecified reason.
CDB-Man said:
TL;DR
Anyways, someone has already asked before, and the developer said he will think about it for MX v2.0. The developer actually explicitly stopped using Play Store beta in the past for some unspecified reason.
Click to expand...
Click to collapse
Charlular said:
So I've noticed that test builds of MX Player Pro become available here however it's much easier to receive updates through the Play Store automatically rather than having to regularly check the website for new test builds. Many app developers use Google+ Communities or Google Groups that use Google's beta-testing and staged rollouts feature to automatically keep people in that group up to date with the testing version of an app so that if somebody is marked as a tester for the app on their Google account and they install the app through the Play Store then they will automatically receive the test version of the app rather than the regular stable version that most people will receive through the Play Store, this encourages more people to become testers and submit bug reports as well as makes the app updating process easier for testers and ensure that they're all up to date so they're not submitting bug reports for an old version of the app. Is there any chance of having something like this for MX Player Pro? I had a look around and couldn't find something like this but please show me if it already exists.
EDIT: If this could happen then it would also be very helpful for the custom codecs too.
Click to expand...
Click to collapse
These are the main concerns in android beta test.
1. For each and every minor update the changelog is to be entered in all supported languages. MX Player supports around 70+ languages & it's very difficult to enter the change log 70+ times for each and every minor updates.
2. As of now the test builds are mostly bug fix versions, not the one for testing new features. So, only recommended for those who has reported/facing the issue. They are getting informed through problem specific thread. Only they can report the particular issue is fixed or not. If it is in the case of beta test community once you opt in for beta & you will continue to get beta builds untill you opts out. So, it can't be used with average users for bug fixing.
3. We have planned to use a closed beta test community for the upcoming major upgrade v2.0 in which new features are to be tested before landing as stable. So, please watch this forum. We may announce the beta test once it's ready to test.
4. Regarding the custom codec, it's very difficult to maintain the custom codec for each and every test version. It will be compiled only from the ffmpeg source for stable version. Anyhow I will consider to compile the custom codec for beta too once beta testing is started.
Thanks you both for the very quick and helpful replies.
ktsamy said:
These are the main concerns in android beta test.
1. For each and every minor update the changelog is to be entered in all supported languages. MX Player supports around 70+ languages & it's very difficult to enter the change log 70+ times for each and every minor updates.
2. As of now the test builds are mostly bug fix versions, not the one for testing new features. So, only recommended for those who has reported/facing the issue. They are getting informed through problem specific thread. Only they can report the particular issue is fixed or not. If it is in the case of beta test community once you opt in for beta & you will continue to get beta builds untill you opts out. So, it can't be used with average users for bug fixing.
3. We have planned to use a closed beta test community for the upcoming major upgrade v2.0 in which new features are to be tested before landing as stable. So, please watch this forum. We may announce the beta test once it's ready to test.
4. Regarding the custom codec, it's very difficult to maintain the custom codec for each and every test version. It will be compiled only from the ffmpeg source for stable version. Anyhow I will consider to compile the custom codec for beta too once beta testing is started.
Click to expand...
Click to collapse
Regarding #1, I did not know they had to be published for betas, would it not be adequate to put something along the lines of "see changelog at https://sites.google.com/site/mxvpen/" (with the actual URL to a changelog) in each language or something? I guess even just the URL alone would be adequate and you wouldn't have to edit it for each language, it would only be for the few beta testers who wouldn't mind anyway.
Regarding #2, just because something is mainly bug fixes and not features does not mean that we'd prefer to test it than be on the stable build. I see your point about the average user, could this perhaps be worked around by changing the title and logo of the app slightly for beta builds like how Google do with Chrome and Chrome Beta? So the beta app could be called MX Player Pro Beta and have a little beta strap on the icon or have something inside the app that makes it obvious that you're still opted in for the beta and a button in a menu to take you directly to the opt-in/opt-out page?
Regarding #3, I will watch out for that, thanks! Do you have an ETA for v2.0?
Regarding #4, I'm a bit confused as to how you publish test builds of custom codecs, I though that because of this post you only have test builds of certain custom codecs at certain times, so you could just put the test builds in the play store for the custom codecs that actually have a test build
CDB-Man said:
TL;DR
Anyways, someone has already asked before, and the developer said he will think about it for MX v2.0. The developer actually explicitly stopped using Play Store beta in the past for some unspecified reason.
Click to expand...
Click to collapse
I didn't see the second part of your post. Do you not have any idea as to why they stopped using it and so do you think it's unlikely they'll use it again?
Charlular said:
I didn't see the second part of your post. Do you not have any idea as to why they stopped using it and so do you think it's unlikely they'll use it again?
Click to expand...
Click to collapse
My first 2 points are the reason.
One more point I have forgot to mention is that beta builds are not immediately rolled out. When we tested last time it took some time to be rolled out completely. Not everyone is getting the update immediately after uploading to the playstore. So, it is not the efficient way to test the bug fixes real time.
Releasing a seperate bata is again going to a head ache and will make confusion. There is no way to switch to stable version untill or unless the user updates the stable build. Otherwise we have to maintain two applications separately.
Be Patience till we call for beta test for v2.0.
ktsamy said:
My first 2 points are the reason.
One more point I have forgot to mention is that beta builds are not immediately rolled out. When we tested last time it took some time to be rolled out completely. Not everyone is getting the update immediately after uploading to the playstore. So, it is not the efficient way to test the bug fixes real time.
Releasing a seperate bata is again going to a head ache and will make confusion. There is no way to switch to stable version untill or unless the user updates the stable build. Otherwise we have to maintain two applications separately.
Be Patience till we call for beta test for v2.0.
Click to expand...
Click to collapse
Ah okay, well then for the moment is there any mailing list that I can easily subscribe/unsubscribe to for updates to the test builds of MX Player Pro or the custom codec for ARMv7 NEON?
This forum is the place to watch regarding updates.
ktsamy's custom codec thread has all the updates regarding his custom codec.
Regarding MX Player bug fix versions, the developer will reference a beta version whenever one is created to address a specific issue highlighted in a forum thread here. The developer always posts test builds on his own website here: https://sites.google.com/site/mxvpen/translation/test-build
I'm sorry if this has been covered already didn't find it by searching. But according to this article:
https://www.xda-developers.com/google-blocks-gapps-uncertified-devices-custom-rom-whitelist/
Custom rom devices with a build date fingerprint of after March 16 are blacklisted from g services unless you add your Android_id to their whitelist? Anyone else aware of this? Few questions come to mind.. like is this a one and done on the whitelist thing or does your Android_id ever change so you have to re-reg every update. I'm sure this will effect a lot of us pixel and other users come the April patches. Just looking for more clarification and your thoughts.
#PE #ROM #OFFICIAL #10
Pixel Experience - OFFICIAL | Android 10
Updated: 24/11/2019
Mod Edit : Links removed.
Device Changes: -
- Enabled volte for Airtel/Vodafone ( Might need a wipe still not 100% if works )
- Nuked custom sf offsets
- Imported some missing radio blobs
- Enabled use_data_netmgrd
Rom changes:
- IMS Changes ( viLTE shoud work fine now )
Isn't this the same build as the other official PE ?
Well, you aren't the official maintainer. Why are you reposting builds of Dyneteve?
Thug dev
Mod Edit
2 Threads on same topic is not allowed and there is already an Official PE is released by maintainer here
May I remind you XDA Forum Rules #12
12. Sharing
XDA-Developers is based on the principle of sharing to transmit knowledge. This is the cornerstone of our site. Our members and developers freely share their experience, knowledge, and finished works with the rest of the community to promote growth within the developer community, and to encourage those still learning to become better. There are those, however, who take advantage of this model and try to make personal gains from the hard work of others.
In order to preserve the delicate balance between sharing for the good of the community and blatant self-promotion, regular members and developers alike must understand (and agree) to the following:
12.1. Give credits where due - Credits and acknowledgements for using and releasing work which is based on someone else's work are an absolute must. Works reported to have no credits will be taken down until proper acknowledgements are added by the member in question;
12.2. Courtesy - While most of the work released on our site falls under the umbrella of open source, that is not the only license model being used by developers on xda-developers. In order to prevent problems, we ask that if you decide to base your work on someone else's that you check the license model being used (as it might not be as permissive as one may think);
12.3. Re-releasing other's works as your own is forbidden. The code that you release into the wild must have something beyond minor aesthetic changes that makes it better than the last. As this can be subjective, kang reports will be reviewed on a case by case basis. If you feel that your code has been kanged, please contact the Dev Relations team (listed below) if you cannot solve the issue amicably via PM. Please understand that you will be asked to provide evidence to substantiate your claim;
12.4. Developers can issue take down requests (by contacting the Dev Relations team) under the following circumstances:
- in-process builds start showing up on forums when the developer is not yet ready to release the work;
- cases in which another developer is too aggressively soliciting donations or misrepresenting the work (kanging);
- unofficial builds where an official build is already available;
Thread Closed.
jackeagle
Forum Moderator