Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

what form should the compatlib take, if any? #456

Closed
DanAlbert opened this issue Jul 14, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@DanAlbert
Copy link
Member

commented Jul 14, 2017

Very few people we've spoken to (at I/O or other events, for the most part) have said they were interested in having a compatibility lib that would backport more libc/libm/POSIX APIs into older releases. Our plan for doing this was to add things to libandroid_support, which would increase library/APK size. This is something people have been very vocal about not wanting, so I think we should reconsider doing this.

Given the lack of enthusiasm, I'm tempted to just not do this. Please speak up if I've misinterpreted feedback or just haven't heard from you! There are other things we could try, such as having two support libraries (a minimal libandroid_support for libc++, and a very complete one for people that want new APIs or bug compatibility at the cost of APK size), or possibly individual libraries for the various components that people want.

Please chime in here if a more fleshed out compatibility library is something you want. Also let us know which libc/libm/POSIX APIs in particular that you wish you had on ICS/JB.

@ehem

This comment has been minimized.

Copy link

commented Jul 15, 2017

Taking measures to keep APK growth as limited as possible would be good. The simple task of keeping object files in a static library small is one part.

Making it so that if an application targets android-X and android-X's libc supports the feature Y, but not feature Z; only the wrappers for feature Z should get built in.

Based on the bug reports it seems like LARGEFILE64 support would be good. Many rather olde devices can in fact handle very large files via SD card and even if the libc on those devices doesn't wrap the appropriate system calls, small wrappers would be pretty simple.

As noted elsewhere when looking for iconv support everything I found on search engines was about how to get GNU libiconv to build using the NDK. I suspect many developers have already added GNU libiconv to their APKs, so that price in size is unavoidable. As such including iconv seems like a good idea (until Android's standard libc includes support).

@enh

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2017

https://android-review.googlesource.com/#/c/434181/ documents the _FILE_OFFSET_BITS=64 (and friends) situation. full support (stdio) was surprisingly hard, though you're right that the simple system call wrappers would be the most easily-implemented part of any full compatibility library.

@alexcohn

This comment has been minimized.

Copy link

commented Jul 15, 2017

I would vote for less backward compatibility shims. Native libs' contribution to APK size inflation is significant.

I am not even sure that more libc/posix APIs for future NDK releases are important, because the app developers are stuck with the old versions.

The true relief could come with downloadable components. E.g. common libraries like OpenSSL, libphonenumber, ICU, FFMPEG, and maybe even WebRTC could be wrapped so that any developer be able to rely on them on the device, and even make sure the latest version is available. Same is actually true for libc++_shared. It's a pity that each C++ app must carry with it same libraries again and again, and expect users perform update for each app when a common shared lib needs update.

Actually, Android has partially resolved this problem by packing many important components to Play Services APK. Maybe same or similar solution will make native dev's lives easier, too?

@alexcohn

This comment has been minimized.

Copy link

commented Jul 23, 2017

See also #466. I believe that backport of MediaCodec and other libraries is nice to have.

@ehem

This comment has been minimized.

Copy link

commented Jul 27, 2017

I fear downloadable libraries would require assistance from the Android OS (need to authenticate the libraries!), but this would certainly help with the size issue. There is also a severe problem with library updates sometimes breaking older software due to new bugs.

@borrrden

This comment has been minimized.

Copy link

commented Aug 2, 2017

Downloadable libraries would be pretty neat...users complain when APK size grows, but since Google forbids the use of almost anything useful when using the NDK, we have to bundle things like SQLite, ICU, etc.

One issue would be, would these get deleted when the app is uninstalled (or when all apps using that library are uninstalled)? Or would they be stuck there forever.

@alexcohn

This comment has been minimized.

Copy link

commented Aug 2, 2017

@borrrden: you can use system ICU (it's a huge download otherwise). @DanAlbert once pointed me to the ICU wrapper that makes this task easier. Here's a usage example: https://android-review.googlesource.com/c/153001/

@kneth

This comment has been minimized.

Copy link

commented Aug 2, 2017

@alexcohn Is the ICU wrapper actively been worked on?

@borrrden Restrictions in some countries (like China) might make it downloadable libraries less attractive.

@alexcohn

This comment has been minimized.

Copy link

commented Aug 2, 2017

@kneth: we have an alternative wrapper built in-house. It works well for us, and it is actually very similar to what Tao Bao proposed 2 years ago.

@borrrden

This comment has been minimized.

Copy link

commented Aug 3, 2017

@alexcohn Is this not a restricted thing to do after Android N?

All apps generate a runtime error when they call an API that is neither public nor temporarily accessible. The result is that System.loadLibrary and dlopen(3) both return NULL, and may cause your app to crash.

https://developer.android.com/about/versions/nougat/android-7.0-changes.html#ndk

@enh

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2017

@borrrden we haven't made much noise about it because we don't have anything convenient in the NDK yet (just tbao's CL on gerrit that was linked to earlier), but we deliberately left a hole for icu4c. it's very useful, it's very large, it has good ABI stability (and upstream really cares about that, which most projects don't) ... but it has no data compatibility, so you need to ship a large library and a butt-load of data. so our plan is to get the NDK icu4c wrapper into the NDK and encourage folks to use that.

@DanAlbert DanAlbert added this to the unplanned milestone Aug 10, 2017

miodragdinic pushed a commit to MIPS/ndk that referenced this issue Apr 17, 2018

Update the roadmap.
The lack of interest in the expanded compatibility library has led us
to reconsider (android-ndk/ndk#456).

Test: None, markdown only
Bug: None
Change-Id: I9a0e8e6b880e656f56206edfc4d3300e94da98fd

@DanAlbert DanAlbert closed this Oct 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.