Open webgeek1234 opened 6 years ago
We should drop Android 2.2/3, RetroArch doesnt even work on that version, it crashes on touch input and there are almost no Android devices that ever used an armv5(the same as a nintendo ds which we dont support), and its not powerful enough to run anything past nes anyway.
Anyone on an Android 2 device can just upgrade to Android 4 with a custom ROM anyway.
Well, since this wasn't closed when my last round of updates went in, I'll go ahead and continue here.
I'm currently working on updating the majority of cores to compile with ndk r20 beta 3 and doing a bit more thorough testing that everything still runs properly. The plan being that when r20 releases officially next month, I can do a quick check, then start pushing the PRs once someone pulls the new ndk and sdk stuff on the buildbot.
Secondly, I finally got back to messing with the gradle build for RA itself. I saw that a debug gradle project got added, but it's missing a few things like assets and signing. Work in progress is at: https://github.com/webgeek1234/RetroArch/commits/gradle Doing more testing on that in tandem with the core ndk updates from above.
@twinaphex There's a few things you probably won't be too thrilled with here. A) Min api level does raise to 14 as discussed above. NDK and certain libraries (like the location one) don't support anything lower any more. Api 14 is Jellybean / 4.4. B) Armeabi (armv5) support is now completely gone. Also discussed above. C) https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html In August '19, all apps shipping native libs must ship 64-bit libs. If I read and understand this correctly, that means the main ra apk will have to ship aarch64. Currently, my gradle patchset has a commit to split the aarch64 build like is currently being shipped. But based on this announcement, I think it may be best to drop that commit and use the gradle conversion to merge aarch64 back into the main builds. Afaik, there's only 2 remaining cores that will have potential dynarec issues from this: picodrive and beetle psx.
For the 64-bit requirement my suggestions is:
Also there is one important question. What happens when a user updates the app. Will the 64-bit upgrade "kick-in" right away? That would be a problem because all cores would be rendered unusable.
If the update forces 64 bit devices to 64 bit maybe the core directory should be backed up and cleaned up on such event.
Hi there @webgeek1234 ,
thanks for contacting us. Much appreciated.
Indeed, I'm aware of these changes that are going to happen on the Android Store and I also agree with the changes proposed by @fr500 . We can leave the 32bit only app for buildbot/f-droid only.
Let's talk about these changes some more in real-time. Can you visit us on Discord or does it have to be IRC necessarily? Our Discord link should be on retroarch.com.
I'll log into discord later tonight.
Yeah, 64-bit support will kick in immediately. So, something will have to be done about the existing 32-bit cores. Either do a magic auto download of 64-bit equivalents or just wipe the directory.
I'm continuing work on updating the buildbot build system for android. There are a few things that could be a concern, however, and I want to have them documented.
https://developer.android.com/ndk/downloads/revision_history.html
NDK r15c dropped support for abi level 9, making the new minimum 14. 9 correlates with Android 2.3/gingerbread. 14 is for Android 4.0/ice cream sandwich. NDK r16b deprecates support for armv5/armeabi. Armeabi can still be built, but it won't with the default APP_ABI=all flag.
So, the question is: are these important enough to leave in the default android builds? I didn't realize the minimum abi level got force bumped when the NDK was updated to r15c. A possibility would be to make a legacy recipe that uses r10e to support abi 1-9 and armeabi. I don't think any arm device since ICS would use an armv5 chip.
I'm putting in work to make the cores less compiler and stl dependent. GCC is deprecated as well, clang is slated to be the only supported compiler by r18. Same with libc++ being the only supported stl. Many of the cores appear to work as is with clang/libc++, but I'll continue working and testing that over the next few days/weeks.
The build system for the retroarch apk needs looking into as well. Ant was removed from the SDK recently, so to build against more recent versions, either an external ant will need to be used or the project converted to gradle. I have not researched this part yet.