search

thekirankumar / carstream-android-auto

A youtube/plex and local video (MP4/MKV) player for Android Auto
http://www.thekirankumar.com/blog/2017/12/29/play-youtube-video-android-auto-app/
Apache License 2.0
330 stars 107 forks source link

Prep work for updates of SDK (v26->v28) and other dependencies #229

Closed chadjoan closed 5 years ago

chadjoan commented 5 years ago

Hi Kiran,

I recently got CarStream to work by building a release APK with relatively recent (freshly installed) Android Studio (3.4). It ended up being a heckuva time (day or two of full-time work), probably due to not having older versions of some packages or other things that I don't quite understand. I got build errors right off the bat and went to task. I ended up updating the project and most of its dependencies to higher versions (target SDK 26->28, min SDK 15->16) and got to the point where I could run that on my car without crashes. I went back to rebase all of my commits and sort everything into a least-invasive-first (instead of chronological) order, and compiled as I went. Now suddenly everything works fine when I checkout master and try to build it. I only get errors when I change versions in build.gradle before applying the other changes. Go figure. So I imagine some caches of 3rd party projects needed to be warmed up, some configuration in Android Studio needed to get hammered out by coding a bunch, or something like that. Or maybe one of Android Studio's nags was the end of me. Either way, positive work was done, and I hope it can help others.

In summary: I ended up updating the codebase and fixing some minor bugs.

Updating things to SDK 28 /might/ help others who are trying to build the project for the first time. At the very least, it's one less red herring that someone could end up going after when trying to build from scratch.

I have broken apart the whole thing into a some separate pull requests.

This pull request doesn't change the SDK or dependency versions in the build.gradle file, but does do all of the prep work that allows things to compile later when those versions are changed. I'm separating the version changes in build.gradle into a different PR so that you can get the delicious code updates without being forced to change things like min SDK version right away (though it might be a good idea, so that other development and PRs don't cause regressions). I'm also going to be making a couple smaller bugfix PRs that also precede the version change PR. Some of the things in this PR might also be bugfixes for bugs that become apparent (as new errors) when compiling with a more recent build SDK version.

Peace.

thekirankumar commented 5 years ago

Merged, thank you @chadjoan :D