Bump minSdkVersion to 16/19

[TacoTheDank]

Regarding this:

• Force-closes on Start in Android 4.0 #659

And seeing how the app on those versions seems to be super unstable, I'm wondering if it's time to pull the plug on support <16 (and perhaps even <19).

There's really only so much we can do at this point for such users, and it seems that their user experience is already subpar (with crashes and such). I'd recommend at the very least bumping the minSdkVersion to 16.

[gzsombor]

Yeah, it's nearly a year has passed, since I said, that the next release wont support Android 4.0 😄 And since that, I just postponing the jump - however, there are more compelling reason to do it, as ExoPlayer after 2.9 requires SDK 16, and with that, I could implement subtitle support relatively easily.

[drogga]

Hell No !!!
Please don't, as I'm truly \ heavily relying on that for \ on couple of devices...
(Especially now, since NewPipe Legacy is basically dead - no one cares to update it, also it works worse than this one, plus it's more resource heavy, also I don't have issues on 4.1.2 & 4.3 JB with 2.974 & 2.975)

BTW - v2.976 crashes for some reason when i'm trying to play the latest XDA upload (no issues with 2.974 and 2.975):
https://www.youtube.com/watch?v=dtPT5GfIOKI
Also tested on Android 8 x86 VM\Emulator = the same, so the issue is definitely not in my devices...

Also please add a option to disable the update check, or just show it once on every new version and to not show up 'till the next.
Thanks.

To have a support E-Mail address, instead of writing a issue here for absolutely everything will be nice (there's no PMs or anything here, so I hope that you see my point of view) ;)

@gzsombor @TacoTheDank

[thetric]

I'm not an Android expert but shouldn't it be possible to set the targetSdkVersion to 30 and keep the minSdkVersion? See the Android Dev docs:

Configuring your app['s targetSdkVersion] to [..] a recent API level ensures that users can benefit from these improvements, while still allowing it to run on older Android versions.

https://developer.android.com/distribute/best-practices/develop/target-sdk#why-target

@drogga

To have a support E-Mail address, instead of writing a issue here for absolutely everything will be nice (there's no PMs or anything here, so I hope that you see my point of view) ;)

I guess it's easier for the developers to discuss bugs/feature requests in public instead of repeating it in every private mail ;)

[drogga]

@thetric ...Yeah, but not everything is meant for public eyes and I don't feel like starting a chat here, in the issues.
There should definitely be some\a way to PM\DM someone, this is not the way @github !

[gzsombor]

Unfortunately there is no forum in github, so there is no better place to discuss development related questions, other than the issue tracker. But at least, it's fully public. Unfortunately, as there is no such a thing, what we could call as 'Skytube developer team', there hasn't been any need to have a developer-email list, for example.
For the targetSdk/minSdk flags - unfortunately it's not just setting that two values, and everything will work. (Currently this is set as minSdk=14 and targetSdk=28). SkyTube and it's libraries need a bunch of things from Android to function properly:

1. A complete Java 8 environment
2. Several native libraries
3. And a lot of Android APIs
   For example:

• Force-closes on Start in Android 4.0 #659 caused by a missing class from Java on Android - luckily, it was easy to fix in that library - but now SkyTube use a forked version.
• Old Androids have problems with newer TLS versions - For 4.1 - 4.4 it needs a couple line, to explicitly enable TLS 1.2, but for 4.0, it's unfixable (maybe with rooting, and updating native libraries 😉 ).

As I neither have unlimited free time, nor such an old device (and recently my commute time is 0, so I use the app much less), it's not my priority to keep Android 4.0 compatibility alive. If we gain something with raising the minSdk level, I wouldn't oppose it. Currently, I know one advantages of API 16, is to have newer ExoPlayer.

[drogga]

So since I don't have much time in replying in much details, I will try to address as much as possible here, on one place, tho I will\may edit or post (comment) again to add something if there's a need, like if I forgot something.:

As I mentioned - sometimes \ in some situations and for some things the 1 and only way to communicate here being like this is disadvantage (an issue), not everything should\must be public. It won't hurt if we have\had a direct chat of some sort, or even better - being able to private-message someone.
I meant - you to provide an E-Mail address so I can contact you and reply faster, since you do all the work (mostly)...

You didn't mentioned anything regarding my suggestion, nor addressed it - the one to add a option to disable the update check, or refine it !

• I have many more suggestions, in case you are interested in, some I even mentioned in my own "issue" topic, which I hadn't had much time to respond to your reply there, or edit my OP, so - sorry about that.

If you can, please do build \ compile and push the .apk(s) faster, so I can test it and report sooner if something's wrong, since I use old (ancient) garbage devices with OS vers. that vary between 4.0.3-4.3 anyway, so I can test at least on 4.1.2 and 4.3.

I thought (think) that 4.3 JB and lower\older natively supports TLS 1.2 and lower, 4.4 KK has some limited support for 1.3, but in\since 5.0+> is fully supported \ functional...
The YouTube site do still work on 4.0.3-4.3 in the native browser, not with something like Chrome or Firefox that are fully fledged browsers with their own engine (core) and support latest networking protocols, like TLS and SSL and the YT app does too, if you know how to "touch" it to make it work (some 'reverse engineering' \ modding is needed), but the problem is that they are super \ extremely resources dependent and heavy, and my devices can't handle them, because they don't even play the MP4 streams, but WEBM's (dash). I even use some invidio.us instances that don't use TLS 1.3 and they don't seem to have problems with playing and with TLS on 4.3 and older, in a build-in native browser and it's ExoPlayer (that way it only plays in 240 \ 360p, cuz it's en-forced\restricted only to this by the instances), which again - doesn't support 1.3, that's exactly why I think that you are not completely right about this.

I would very much like to hear more about the replacing (updating) the system's native libraries with root access - please...!

I don't see a need or point in\to updating the SDKs (and\or dependencies) and as I mentioned - I am against that.
The build-in ExoPlayer is the one thing I like in this app and because of it I prefer it over the other alternatives, so I don't see why would you want to change or update it, when it will break the compatibility with 4.0 (14).
I think - you can update\bump the TargetSDK to whatever you want, it doesn't\won't matter to me, nor it will make the app any better on latest android vers., after all - taking advantage of new OS features won't magically happen by it's own by bumping the TargerSDKversion, they need to be implemented too, like zooming to fill the screen to hide the black bars on devices with notch\camera hole on devices with non-standart 16:9 aspect ratio (like 18:5:9 or whatever extra tall and pointless ratios).

[gzsombor]

I still don't know what kind of discussion should happen in private? Could you please explain it? I can assure you, that replying to direct mails wont be faster - from my side 😄
If you have ideas for improvements, the best thing would be to use the issue tracker, search for if it's already suggested by anyone else, if not, please open a ticket. Maybe someone will implement it. Hiding suggestions in comments - or private emails - doesn't help anyone.
Sorry, I don't understand totally what you are saying about the TLS problem - I'm not an expert of old Androids (neither of the news, to be totally honest). Last year, when someone reported that an upgrade broke the app on old Androids, I've put a couple of hours in it, and the result was, that newer TLS can be enabled for a couple of Androids, but not for all. Sure, if you have enough time and energy and determination, you can implement TLS 1.3 in the app, and include the protocol in the apk, but that would be big task.
About rooting and tickering the rooted device, you need to search on forum.xda-developers.com - I've never done it, but as Android is a Linux in disguise, theoretically it's possible.
Upgrading ExoPlayer would bring subtitle support, better built-in on-screen controls at least.
As SkyTube opensource, no one would force you to upgrade, or stop using the app. If currently works for you, it will still work on your devices in the future. With the source code, you can even modify to your taste, as usual.
With the TargetSdk version, you are totally right, it doesn't help/change anything.

[gzsombor]

One thing, what I've missed: after every commit, Github builds debug APKs, which you can try it, for example the latest is here: https://github.com/ram-on/SkyTube/actions/runs/474665010
They are debug builds, so the files are bigger, and have the leak canary enabled, which is a bit annoying, I know - and signed by Github, and not with the F-Droid neither with the 'official' builds, but otherwise, they are perfectly usable builds.

[drogga]

So, I don't know if you can completely delete an issue, or just close it, but there might be things that lets say I don't want to post publicly so\that anyone can see; are not "issues" at all to be posted\presented like this, or in situations where someone forked a git and made some changes for himself, but his E-Mail is not shown in his profile\account page and the "issue" tab is not shown, is disabled or not allowed - currently you can't contact this person at all...
I don't even know why are we discussing this matter, because this is regarding GitHub in whole, not you particularly, you can't do anything to change this, unless you are part of the platform\site's dev team...

Let's say I heve like 6 ideas\suggestions, I don't want to create a different issue for each of them, as I already did a mega thread with couple of them on one place, but nobody cares and I even mentioned one here, but you keep ignoring it and pretending that you didn't saw it, no matter how many times I ask you to comment \ give your opinion or act on it (I'm obviously talking about the one to disable the update check).
That's why I don't see a point in hijacking someone else's thread (issue) and keeping the discussion here.

I can't explain the TLS thing better (ENg isn't my native language), but I didn't say that this app has any problem with it currently, I just commented on it, because you mentioned it 2 times - here and at least in other issue.

Since I'm not an expert either, I asked you about the replacement of the system libraries on low-level, enabling the newer network protocols (TLSv1.3) on old android, instead of doing it in a app (on app bases), because you mentioned it, also I don't know what exactly I need to search\look for in XDA or wherever. To be clear - I'm not talking about rooting at all, not asked for that, since you seem to got me wrong I thing, and this is already done, I'm already 'tickering' with the system as you said - for years now.

I never use subtitles in YT, but you can still implement them in a new player that will work as you mentioned on API 16+ and will just be hidden or disabled for 14 and 15 - I've seen that before on other apps, so there's no need to increase the SDK globally for the whole project, but just for the feature you want, in this case - a new 4th player (along the other already existing build-in ones).

You see, if you bump\upgrade the minSDK\API required, some will be stuck with the latest version that is compatible with their devices, but for how long is the question, as it will eventually stop working, because no one will be fixing it anymore with the newer patches and fixes that are constantly needed because Google\YT keeps playing with their code, for no reason in most cases, only to make life harder for some, and in order to keep supporting it yourself by forking it, you need a lot of knowledge, which BTW I don't have - no programming skills, nor I know any computer language, only 2 human's :D

Honestly I barely know how to use GitHub, but I found the deeply buried debug build a couple of hours ago, right after I commented here.

BTW - why don't you add a resolution changing button while you watch\the video is playing (just like NP), so you can bump or drop the rez. depending on the video or situation\case, instead of putting couple of confusing and kind of a bit pointless separate options in the settings for the same thing ?, this will be extremely convenient...
Also the activities for the YT 'share with' and 'open with' links are 2 diff. separate ones, that show in different conditions\situations, like the bookmark one is only shown in the share with list of app's activities, but the play one, which btw isn't described is being shown only in other situation, so why don't you rename the main one, adding "Play" at the end ("SkyTube - Play"), and make them both appear\show up in the different situations, instead being on separate places not in the same list ?

[gzsombor]

I see, fair point, maybe there could be sensitive things in a bug report, I haven't thought about it.
(And no, I don't have right to delete a ticket)

Sorry, I only see that you opened one ticket: https://github.com/ram-on/SkyTube/issues?q=is%3Aissue+author%3Adrogga where I've answered - and asked back for clarification, without response. And I can't find where else have you commented: https://github.com/ram-on/SkyTube/issues?q=commenter%3Adrogga which I've missed. It's certainly a possibility, I don't remember every comment and commenter, especially when there is no name/face/code to attach to it 😞
Please remember, this is not my job, I try to answer in my free time.
I'm happy that you found the debug build, I though that it was unknown to you, as you suggested me to publish APKs faster.

[gzsombor]

@drogga : I have a feeling, that you vastly underestimate the needed energy and time for software development. When you see a 3 liner change (for example my two changes in the last days), it is not a result of 2 minutes of work (sometimes, it was really two minutes of work, when I see something, which is obviously wrong, but it's rare), but more often it's coming from a half-hour - a hour long debugging session, when a developer tries out multiple things, and watch it falling apart. When you - or any user - request a new feature or a new switch, whatever, there will be development effort to actually implement that change, and later a maintenance cost, which will hinders further development, which hurts developers, and in the end, the users too.
Putting two different library into one app is not hard to do, putting two different versions of the same library is much trickier task (for a regular Java app, with some 'shading' and 'repackaging' you could do this, if you were lucky, and no reflection were used - I don't know how picky is Android in this regard), but in this case, it would be still problem with that the library requires SDK=16, but we would want to compile with SDK=14. Similarly, if we would add a third flavor - Legacy - to the app, next to the current OSS and Extra ones. And every time, if there are a library upgrade, we would need to run the same painful circles. If somebody volunteers to do this, I would merge their patches, but I don't think I want to work on that.

[drogga]

I won't underestimate the needed effort anymore.
I'm just throwing some ideas out here in public, don't feel forced, obligated or rushed to implement them.
It turns out that the idea for easy picking or switching the resolutions, while the video still plays (via drop-down menu, like the speed one) is already been suggested before.
The update nag idea\suggestion shouldn't be that hard to do, so if you can at least do that it will be great ;)
Regarding the activities - they prob. just need to be moved over and one of them renamed, so that should be a quick fix, since there isn't much to test, as their behavior won't be\doesn't needs to be changed, so if not you, then somebody else can do it, probably in a matter of minutes, not more than 10 I think. If I could, I would've done it already.
I don't need the "bookmark" one, but I only have that one in the 'share' (with) browser's menu for a YT link, I want\need the un-described "play" one.

Thanks and have a nice day/night, cheers.

Oh, and I decided to wait for the next version, then I will reply to you in my topic, cuz most of the things might've been fixed already anyway. Some are.

[TacoTheDank]

@gzsombor Perhaps you could make a branch (or a separate repo in the SkyTubeTeam organization) for legacy minSdk 14 support and just backport non-API related/influenced bugfixes and features to it (and then someone like @drogga can just install the github builds for that branch in [actions[(https://github.com/ram-on/SkyTube/actions)). If we did it this way, we could move forward with minSdk 16 in the main branch/project and take advantage of newer ExoPlayer and whatever else could be done around the project.

Speaking of which, will you eventually be moving this repo to the SkyTubeTeam organization?

[gzsombor]

I don't own this repository, I'm not admin here, I can push - maybe - 3 more buttons than you 😉
@ram-on is still the owner

But yes, having a separate github repo could solve the issue with the least amount of pain.

[TacoTheDank]

@gzsombor I forgot 😅, I guess we just have to hope that ram-on is still active and would agree to moving the repo.

[Git-Forked]

I disagree with pulling the plug on android 4.x
Not everyone is wealthy enough to afford new fancy phones.
If your programming is so poor you can't fix issues, then I see your reasoning.
Supporting less devices == less issues.
You program already has a huge list of issues that aren't being solved.
Perhaps a better solution would be to get some other programmers on the team who can help support more devices and write cleaner code.

[gzsombor]

I disagree with pulling the plug on android 4.x
Not everyone is wealthy enough to afford new fancy phones.
If your programming is so poor you can't fix issues, then I see your reasoning.
Supporting less devices == less issues.
You program already has a huge list of issues that aren't being solved.
Perhaps a better solution would be to get some other programmers on the team who can help support more devices and write cleaner code.

Sure, please, start sending patches!

[TacoTheDank]

@BugReportering

If your programming is so poor you can't fix issues, then I see your reasoning.

Geez, that's a bit blunt, don't you think? 😄 The onus isn't all on the devs here. Android can be pretty finicky. Android development design itself in its earlier days wasn't the greatest. The development tools have carried quite a lot of rather poor programming/design baggage into the current day due to the load of overhauling it would take to completely rewrite it, although it is being improved little by little.

Basically what I'm saying is that the lower the API that is supported, the more workarounds and other things like that that have to be created to be able to get it to work properly on basically every device (including newer devices, which suffer more technical debt because of the workarounds required to also support older devices).

You program already has a huge list of issues that aren't being solved.

You mean "haven't been fixed yet", right? It's not necessarily that the devs don't want to fix them, it can also be things like lack of time, personal life stuff, etc.

Perhaps a better solution would be to get some other programmers on the team who can help support more devices and write cleaner code.

I agree with @gzsombor :)

[gzsombor]

After doing some experiments with build flavors to have a separate legacyOss and legacyExtra versions, I have to say, it quickly become very complicated and painful:
If I add just a legacyOss and legacyExtra next to the current oss and Extra versions: I need to duplicate a lot of classes, or have to add a couple of gradle magic to trick the build to pull shared classes properly.
If I create a separate flavorDimensions, so to have a modern and legacy flavors, so the build will create automatically oss-modern oss-legacy extra-modern and extra-legacy, then I can't customize the individual builds enough, so their title/applicationId can't be specific to their build.
And finally, this required heavy refactoring moving the various code pieces in separate classes to enable proper overriding,etc ... So I had to abandon it.
Currently, the best way to forward for me, is to create a separate repository - SkyTubeLegacy where we could keep the current minSdkVersion as 14, and bump to 19 in this repo. For the transition, we can add checks for the update process, that SkyTube Extra could check the latest version number from that repo, if it's running on SDK < 19. And similarly, the OSS version coming from F-Droid could notify the user, that they should install a separate application.

[drogga]

You can probably even bump it to 33 (A.13), but that won't change anything other than only a few will be able to install it, because let's face it, the problem here is that there's no interest in this app, it's not popular and basically no one seems interested in contributing with a code to the project/app, even you (not having time for it is a big issue and I understand it completely) and I've seen your test builds in your fork and even wrote what I think about that, but in one of my unrelated forks of other projects, where I created an "issue" and tagged you, but you didn't gave any indication that you even read it and now I don't remember what I wrote here or there, because it was a long time ago.
So go ahead, bump it even higher than 19, this won't make absolutely anything better, it will only become another NewPipe and there's a lot of those, I don't use them because honestly they are a total crap, I use this because of the simplicity and it gets the job done, which is playing videos and that's it, one that wants fancy new features can use other projects and YT itself or the tens of "vanced" projects based on it. A separate repo will become one another NewPipe Legacy, which is dead (archived)...

[gzsombor]

I usually get a lot of github notification, and I do not read everything... Sorry, I will try to find it...
Yeah, I there is not too much interest in the app, even though probably one of the last apps which supports really old Androids - NewPipe needs API 19 since end of 2018, so this feature is clearly not that important for too many people.
I don't know, why the app doesn't attract more regular contributors - apart from translators, and a couple of bigger, one-time code drops. Certainly, the app has a fair share of bugs, and especially when it needed a Youtube API key, that was easily lead to embarrassing startup experience. The code base has issues as well - from the persistence layer (why the need of 5 separate databases, instead of one?... Using JSON too many places, which could cause strange bugs when you want to read a JSON written by X previous version...), or to the various 'GetYouTubeVideos' classes, they feel a bit overcomplicated. Also there are too many features, which makes testing more complicated. Or maybe, the problem is because it is written in Java, instead of Kotlin, which is the new cool thing? - yeah, Java 8 is a bit cumbersome... Or because it uses old versions from everything, which could be a pain... Or because I'm a terrible person.
I can only speak for myself, when I decide to what to do in my free time, my priorities are

• I want to fix a problem, which affects me, and annoys me enough
• I want to learn something new, which worth knowing
• I want to have fun, enjoy the experience of accomplishment, etc...
• I want to improve things, just for make it better...
  And to be honest, Android development is not that fun for me. The constant struggle with the emulators, with their annoying bugs, for which I can never be sure, if there was a bug in my change, or it's just a bug in the given android version, or with the picked image, generally, the older the Android version, which I try to test, the more painful it become. And I also know, that I'm bad at creating UI/UX... I don't think I've ever modified the UI of SkyTube in a substantial way, apart from adding new checkboxes, menupoints, etc...
  My guess, other developer's priority could be the same, so they decide that the app is good enough to not fix anything, or too bad to worth put any effort to improve it. I would be curious the other couple of contributors opinions, of course.

[TacoTheDank]

@gzsombor I agree with what you said. I think it would be true to say that every Android dev has a love-hate relationship with it.

@drogga I'm going to echo what I said in NewPipe for here.

[drogga]

Look, there are many (small, significant or not) things that are broken since long ago, somethings always were, but those won't and can't just magically fix by themselves, someone needs to do the work manually, increasing \ bumping APIs, dependencies and what not, won't fix those, they will still be broken, like the (pull-down-to) refresh.
The sad thing is that most of the things are probably easy and quickly fixable, there's just no one interested in doing the work, too bad that I can't, else I would've by now !

[TacoTheDank]

but those won't and can't just magically fix by themselves

This is just how Android works, unfortunately: the Android SDK is bound to the Android API. Once a device stops receiving updates, the apps installed on the device can only use the API features available on that version of Android. Work for devs becomes increasingly harder when supporting increasingly older devices because they cannot use (or have to find workarounds for/add extra code for) new/improved API features.

Someone needs to do the work manually, increasing \ bumping APIs, dependencies and what not, won't fix those, they will still be broken, like the (pull-down-to) refresh. The sad thing is that most of the things are probably easy and quickly fixable,

Believe me, this isn't the case very often. Workarounds can take quite a lot of time to figure out - time that not all developers have or are willing to spend in that manner (might I add, for such a statistical outlier - see below chart). That's why bumping the minimum SDK is being considered in the first place.

there's just no one interested in doing the work

Yep, and for good reason (see all of the points brought up above). Also see this OS statistics chart.

[drogga]

...I don't believe that you are even using the app, I mean not really, so IDK why are you even care..., I use it every single day, that's my access to YT, please just cut the BS about API improvements, security and so on, everything did go to sh!t with Android, if you haven't, go ahead and read about the Android/data and /obb (even /media) access with third party file managers in A.13, android becomes worse than iOS and those that agree with every stupid decision Google makes are just the worse.
I did go a bit off-topic here, but I'm just so mad regarding the more and more dumb restrictions in every new OS ver. release, that I'm getting sick when I see someone pulling the BS about the new APIs/SDKs, a true talent (I mean Dev.) can work with old revisions or versions of those and still manage to achieve a lot, like MiXplorer, unfortunately that doesn't apply in A.13, at least regarding the restricted folders and files access in of the mentioned paths above), the worse part is that Samsung's "My Files" app never allowed full access to those paths since A.11 and they made sure to cut-off, cripple or straight up remove/not include the usually build-in system "Files" app, which supposedly still has unrestricted access to those 3.

Don't you dare showing me charts or base you personal opinion and believes on those, since considering all the restrictions and only a few if any improvements or benefits, that are really and truly meaningful and useful, there's a reason on why people want to stay on older versions, like 11, 12 and up (12, 12L, 13) are the crappiest ever, there are all kinds of problems with those, especially in/among the modding community, which without, Android is nothing, like iOS, which I suspect in 10 years will be better and superior than Android. I can update to 12 and probably in a few weeks to 13 on my Samsung, but I don't want to, since those are the worse ever.

[drogga]

I apologize in advance if I got anyone offended in any way with my texts and writing style, this is definitely not my intention.

[gzsombor]

It's here: #1115
I hope, I've configured everything properly for SkyTube Legacy 🤞