如何看待 Android 9.0 谷歌將限制非 SDK 的介面使用？
國內的這些熱修復、插件框架是否很快就無法使用了？
瀉藥希望能夠借這個機會幹掉反人類的熱更新熱更新是真的吃空間，一次吃90m是真的吃不消
作為Android開發者，我是樂於看到這事情。因為調用非sdk介面讓我個人感覺破壞了程序的封裝美。
感覺通過反射等方法調用私有的方法，違反了對訪問許可權設計的初衷。從程序設計上講，對外的介面是穩定不變的，內部的實現可以由sdk開發者隨意修改，sdk的一些內部實現和內部方法不需要由sdk的使用者知曉，更不應該強行被使用。
謝邀。
不會「很快」就無法使用。這樣去破壞向前兼容性，是系統設計的大忌。Google官方也說了，會有灰名單機制，給開發者一段時間去調整；所以應該不會Android 9.0一出來，齊刷刷的跪一片。
不過從長期看，使用非SDK介面（或者說私有API）需要花費更大的代價是必然的（現在直接反射就OK，以後需要付出穩定性和更多的兼容性方面代價）。說完全無法使用，這個我不太相信。
舉兩個例子，Android N的時候，限制了NDK中私有API的使用；典型的就是dlsym拿不到符號。但是現在還是有辦法去應對，就拿我知道的，至少有兩種：
1。 自己實現dlsym，手動解析ELF文件，通過基址＋偏移 自己計算地址。
2。用彙編代碼進行棧上替換，直接修改寄存器，繞過系統的檢查代碼；然後直接使用系統的dlsym。
還有個例子，Android 系統從某個版本開始隱藏了odex文件的位置，odex文件的目錄不再是 /data/dalvik-cache 或者 /data/app/&
/oat/ 這種，而是中間有個目錄層級的名字是隨機的。然並卵，直接創建個Classloader，那dexPath 直接就放好了那個奇怪的目錄。
正所謂：上有政策，下有對策。
開放是願景，但無規矩不成方圓，圍繞安全和用戶隱私做一些限制性舉措也是很合理而且有必要的。android系統的繁榮不是靠各種開發黑科技，而是上下游生態鏈的開發形成的。這個也是一般生態體系建設的必然路徑，前期無規則或者規則寬鬆，待規模到一定程度，條款和規則越發清晰和仔細。大家都是摸著石頭過河。
限制性會越來越多，下一步應該會強制Target Version了！
國內業界有一種"我比官方更牛逼"的錯覺。黑（hack）系統來實現黑科技。收緊對私有API的調用或許能整一整這種風氣。
詢問過某插件化框架作者，答案是影響很大，所有需要hook的基本GG，不過到什麼程度，是改改還能用還是徹底不能用，要看谷歌推這個的力度以及對於插件化技術的態度如何。
任何繞過public介面調用private function的行為都是慢性自殺。
國內大廠商基本都多多少少有使用熱更新和熱修復，裡邊肯定用到了非SDK的介面。我們項目熱更新、熱修復都有用。如果真的限制使用，對國內各大互聯網公司都有影響，除非國內ROM會修改Android系統，放開這個限制。
不過站在產品的角度來看，他們不會同意自己的產品無法運行在某些手機上的。
以後只能組件化、RN這些能用了。
對於Android程序員的職業發展來說，更不好了，因為天花板更低了。許多黑科技都不能用了。
其實我更希望java（其實是所有語言）取消反射。簡直是個反人類的設計。各種方面來說
索尼大法終於有希望使用指紋支付了。
很快不至於，主要看國內各廠商的支持程度，但這是一個很好的趨勢，表示Android正在走向標準化，有利於整個Android大環境的優化
當然是好事。國內市場特殊，都喜歡用反射搞一堆奇奇怪怪的事情。但Google自己的support庫也有不少反射，不知道官方會怎麼處理。
一些黑科技將消失。
「黑科技」會少很多，並且很多軟體可能得乖乖使用API了。還有就是可能國產ROM及國產軟體領先谷歌的步伐會慢下來。
難道只有我覺得，那些很多未開放的標記為@ hide的方法，都是暫時未公開，然後過幾個版本再對外公開的介面嗎。。。
補充更新
系統裡面Android被限制的方法，還是有很多手段繞過的。而作為開發者應該是不希望出現這樣的情況，又希望這樣的情況出現。
1好處是此舉確實可以讓Android生態變得更加有秩序，這裡指的是Android系統開發生態環境。
2不好的地方是作為開發者，技術深度會降低，開發者的職業生涯可能不那麼好走了
3是對於，此種行為就能限制隱私被侵犯的現況的，這種觀點，我個人持保留意見。
這樣就沒玩頭了。
我覺得挺好的
限制非SDK介面的引用
但是不要限制開發者模式下介面的引用
現在越來越多的人都會編程了……
我其實都希望能專門提供一些開發者介面……
到時候自己寫一個APP
好好治治那些流氓應用……
什麼陰陽師呀什麼的……給我自動去肝！！
安卓用戶表示無所謂，能用上8.0再說吧，再一個就算是不想升也不會像蘋果那樣天天誘導你
推薦閱讀：