Updating to work with Android Studio under SDK 29 #151
Conversation
…able. Removed mavenCentral() repo where applicable, and kept where necessary.
… all build.gradle files
… to avoid [this](rholder/gradle-one-jar#34) issue
…any reference to minSdkVersion and targetSdKVersion from manifests to android:defaultConfig within build.gradle files. Also updated minSdkVersion to 14 in order to allow the use of AndroidX compat libraries.
…he former appears to be missing all documentation and possibly depreciated. Several stackoverflow questions about troubles importing this exist, so its possible the repo from mavenCentral was removed, or the updated sdk dependencies removed the ability to use this. Regardless, the android.hardware.usb appears to support Android 3.1+ so the number of devices removed from support are likely quite small at this point.
….) Required a formatting change
…the new Notification.builder. This builds fine, but has not been functionally tested to be identical. Requires further testing.
…asswords, storefiles, etc created by ytai. Will uncomment and revert commit after creating my own signing objects, when this becomes necessary. For now, just trying to get the gradle sync to finish without errors, so I can build and debug other areas of the code.
…ure. Not sure if the previous syntax worked on previous versions of gradle, but this commit ensures it meets the requirements for the current gradle syntax. There was a similar syntax issue for modules within the applications subdirectory in the project-level build.gradle file as well. Correct pointers for the subdirectory location are defined in the settings.gradle file via the project().projectDir assignments.
…p task as they appear to be missing from the module-level build.gradle files. Will revert this commit later and uncomment after creating the necessary additions to the module-level build.gradle from which to build the release and debug bundles
… since I do not have access to the various passwords and keys created by ytai. Will revert this commit after creating the necessary maven repo and associated keys to publish this fork.
…ly controversial topic, I am choosing to include it for easier use to those using this library
|
Hello! I'd be interested in the published version of your fork when it's ready as I've been working toward the same goal. Yours seems further along. |
|
I tried to improve your
|
|
Sorry for the noise, it works now |
|
Glad to see others are also interested in bringing this library back from the dead. 🙂 I'm off until Monday, but will pick this back up then, including taking a look at the pull requests to my fork and publishing to a maven repo package. |
|
@y-a-n-n We should agree to one current fork which will become our new origin and create an issue like umano/AndroidSlidingUpPanel#986 in old origin |
|
I'm now maintainer. Please rebase to recent master to merge this pull request with CI check |
|
I tested it before with #157 if CI builds |
|
@hannesa2 thanks for stepping up to maintain! Feel free to remain anonymous, and or tell me to move these discussion type questions somewhere else, but just curious about your involvement on this project in the past? Did you work on the development of the boards with ytai or how did you become the maintainer? Just curious, and if there is any forum to discuss such things elsewhere that you plan to maintain? Edit: |
The 16 commits are fairly detailed and I made each very specific to a given issue. I haven't seen much work being done on the ytai/ioio repo in some years now, so I'm not hopeful this will get picked up, but if so, I'm happy to work as a collaborator rather than maintaining a separate fork. I'll start publishing to a separate Maven or GitHub repo package shortly so I can begin to put these updates into regular use.